Bug 258572
| Summary: | performance.timeOrigin drifts slowly during the lifetime of a page | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Nic Jansma <nic> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Major | CC: | achristensen, beidson, noam, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 16 | ||
| Hardware: | Mac (Apple Silicon) | ||
| OS: | macOS 12 | ||
Nic Jansma
Accessing performance.timeOrigin repeatedly during the lifetime of a page shows that it drifts slowly.
For example, when I first load a page and query performance.timeOrigin I get:
> [new Date, performance.timeOrigin]
< [Tue Jun 27 2023 07:34:57 GMT-0700 (Pacific Daylight Time), 1687876483498.0002]
Then, a few minutes later when I'm querying the same API, I get:
> [new Date, performance.timeOrigin]
< [Tue Jun 27 2023 07:35:37 GMT-0700 (Pacific Daylight Time), 1687876483497]
In this case, it went "backwards" by 1.0002 ms.
Then again a minute later:
> [new Date, performance.timeOrigin]
< [Tue Jun 27 2023 07:36:56 GMT-0700 (Pacific Daylight Time), 1687876483494]
In this case, it went "backwards" by 3ms.
In other instances, I've seen the time drift "forward" slowly over time[1].
timeOrigin should not be changing during the lifetime of the page.
[1] https://docs.google.com/presentation/d/1RW_fLZwUevn7IBXE3hFvKMnaEBs83Dxp3_yLflEfAXk/edit#slide=id.g22706244ab9_0_111
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Noam Rosenthal
I double-checked the spec, and indeed it should be stable throughout the lifetime of the document.
In https://w3c.github.io/hr-time/#dfn-estimated-monotonic-time-of-the-unix-epoch, the "estimated monotonic time of the Unix epoch" is initialized once, while in https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Performance.cpp#L86 it's effectively computed every time timeOrigin() is called.
Radar WebKit Bug Importer
<rdar://problem/111742735>