NEW217099
Timestamp clock drift when computing event delay 
https://bugs.webkit.org/show_bug.cgi?id=217099
Summary Timestamp clock drift when computing event delay
Philip Walton
Reported 2020-09-29 12:39:24 PDT
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.
Attachments
Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2020-09-29 15:57:51 PDT
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?
Philip Walton
Comment 2 2020-09-29 16:33:17 PDT
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).
Alexey Proskuryakov
Comment 3 2020-09-29 17:38:58 PDT
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.
Radar WebKit Bug Importer
Comment 4 2020-10-06 12:40:32 PDT
<rdar://problem/70011970>
Note You need to log in before you can comment on or make changes to this bug.