| Summary: | Timestamp clock drift when computing event delay | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Philip Walton <philip> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | achristensen, ap, cdumez, dino, graouts, msaboff, rniwa, saam, webkit-bug-importer, ysuzuki |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari Technology Preview | ||
| Hardware: | Mac | ||
| OS: | macOS 10.14 | ||
|
Description
Philip Walton
2020-09-29 12:39:24 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? 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. |