[1] Meta: point out event's timeStamp is likely to change · whatwg/dom@0f08850
( 版)
https://github.com/whatwg/dom/commit/0f08850f92b538dec94e986536c917ffa3b300f2
[3] Add Notification.timestamp and NotificationOptions.timestamp · whatwg/notifications@f72a041
( 版)
https://github.com/whatwg/notifications/commit/f72a0417b9cacc3e29194bc7e0e602d97224e5a5
[2] chrome.webNavigation - Google Chrome
( ())
https://developer.chrome.com/extensions/webNavigation
It's important to note that some technical oddities in the OS's handling of distinct Chrome processes can cause the clock to be skewed between the browser itself and extension processes. That means that WebNavigation's events' timeStamp property is only guaranteed to be internally consistent. Comparing one event to another event will give you the correct offset between them, but comparing them to the current time inside the extension (via (new Date()).getTime(), for instance) might give unexpected results.
[8] 1231619 – CSS Animation not properly timed when using AngularJS animate on Firefox Developer edition and nightly
( ())
https://bugzilla.mozilla.org/show_bug.cgi?id=1231619
[9] event.timeStamp now returns DOMHighResTimeStamp on Nightly/Aurora for Linux (Affected) | Firefox Site Compatibility
( ())
https://www.fxsitecompat.com/en-CA/docs/2015/event-timestamp-now-returns-domhighrestimestamp-on-nightly-aurora-for-linux/
[10] 77992 – Make Event.timeStamp return a DOMHighResTimeStamp on Windows (was Event.timeStamp should be relative to 1st January 1970 rather than the system start)
( ())
https://bugzilla.mozilla.org/show_bug.cgi?id=77992
[11] 1026804 – Make Event.timeStamp return a DOMHighResTimeStamp by default (switch on pref)
( ())
https://bugzilla.mozilla.org/show_bug.cgi?id=1026804
[12] 1026806 – Use the timeStamp member of events when performing time calculations
( ())
https://bugzilla.mozilla.org/show_bug.cgi?id=1026806
[13] 1026809 – Remove old Event.time value
( ())
https://bugzilla.mozilla.org/show_bug.cgi?id=1026809
This is change is not observable from content (or chrome).
[14] receivedTime and upcoming DOM update · Issue #145 · WebAudio/web-midi-api
( ())
https://github.com/WebAudio/web-midi-api/issues/145
[15] Add high resolution monotonic timestamps to SensorReadings · Issue #43 · w3c/sensors
( ())
https://github.com/w3c/sensors/issues/43
[16] Issue 599335 - chromium - Web MIDI: drop MIDIMessageEvent::receivedTime - Monorail
( ())
https://bugs.chromium.org/p/chromium/issues/detail?id=599335
[17] #17046 (Event.timeStamp reveals startup time) – Tor Bug Tracker & Wiki
( ())
https://trac.torproject.org/projects/tor/ticket/17046
[19] Issue 574514 - chromium - MSE conformance test failure related to event.timeStamp - Monorail
( ())
https://bugs.chromium.org/p/chromium/issues/detail?id=574514
[20] 238041 – nsDOMEvent::AllocateEvent assigns a PR_Now() into a PRUint32
( ())
https://bugzilla.mozilla.org/show_bug.cgi?id=238041
[21] High Resolution Timestamps for Events | Web Updates - Google Developers
( ())
https://developers.google.com/web/updates/2016/01/high-res-timestamps