Tentative fix for performance.timeOrigin
Currently, we use a static unified clock to be able to compute the 'time at which the global monotonic clock is zero'. This means that this values survives even if a page is reloaded after going to sleep for a while. This is a problem because the time relies on a delta between the unix time and the monotonic time, which may change after going to sleep. Hence this means that values after reload cannot be compared with the value returned by performance.timeOrigin. This CL fixes this by removing the class and computing this value separately upon instantiating each Performance object. In particular this ensures that performance.timeOrigin and performance.timing.navigationStart don't become extremely different after going to sleep and then reloading a page. Bug: 955532 Change-Id: Iaed7e127cd1224a4d3f053225635f2947e074bb7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2182670Reviewed-by:Yoav Weiss <yoavweiss@chromium.org> Commit-Queue: Nicolás Peña Moreno <npm@chromium.org> Cr-Commit-Position: refs/heads/master@{#768857}
Showing
Please register or sign in to comment