Steps to reproduce the issue: 1. Navigate to https://event-delay-tester.glitch.me 2. Click, tap, keypress on the page and notice the reported event delays 3. Wait for a few minutes...or an hour 4. Repeat step 2 and notice that event delays are now negative. 5. Close and re-open the browser and notice event delays are back to normal The code on that page compares `performance.now()` to `event.timeStamp` in the event listeners, so it appears that (as the page stays open longer) there's some sort of clock drift happening that affects one of those two APIs but not the other.
Without actually checking the specs, this sounds like expected behavior - performance.now would be monotonically increasing time unaffected by NTP adjustments, and timestamps would be actual device clock, comparable to Date.now. Does this work differently in other browsers?
Both `performance.now()` and `event.timeStamp` return `DOMHighResTimeStamp`, so I'd expect both APIs to be consistently comparable throughout the lifespan on the browser app being open. > Does this work differently in other browsers? Yes, I'm not seeing any drift in Firefox or Chrome (also tested on Mac, within the same time window).
I was going to agree with you, but then I saw this in the DOM living standard: "In macOS the time of the occurrence for input actions is available via the timestamp property of NSEvent objects." So I'll leave this to DOM lawyers to decide upon.
<rdar://problem/70011970>