Once we have converted native event times to TimeStamp values we should switch on dom.event.highrestimestamp.enabled by default.

It looks like updating the spec is currently blocked on this (http://lists.w3.org/Archives/Public/public-web-perf/2014Jun/0013.html). In Chromium we're also hoping to expose high resolution event timestamps, but we're planning to wait until the spec is updated. Do you have a rough timeline of when this work will be complete?

(In reply to Tim Dresser from comment #1) > It looks like updating the spec is currently blocked on this > (http://lists.w3.org/Archives/Public/public-web-perf/2014Jun/0013.html). In > Chromium we're also hoping to expose high resolution event timestamps, but > we're planning to wait until the spec is updated. > > Do you have a rough timeline of when this work will be complete? It's currently blocked on bug 1026803 which has stalled because I'm busy with other work. I expect it will be early October before that bug is tied up unless someone else is available to help. Once we turn this pref on we won't really know what the compatibility risk is though until it hits the release channel a few months later. If Chromium wants to go first, I think that would be fine.

Sounds good, thanks for the update.

Brian, is this still happening? See https://github.com/WebAudio/web-midi-api/issues/145 and https://github.com/whatwg/dom/issues/23 for context.

(In reply to Anne (:annevk) from comment #4) > Brian, is this still happening? See > https://github.com/WebAudio/web-midi-api/issues/145 and > https://github.com/whatwg/dom/issues/23 for context. Yes, I've just been having trouble getting through the reviews for the changes to Linux native event handling (just 2 patches left to go I think). It dropped down my priority list after we no longer needed it to ship MSE. I'll need help with the OSX code too. We already have this turned on for Nightly/Aurora on Windows and haven't hit any compatibility issues I'm aware of.

Any update on the compat impact here (i.e. is this shipping in stable on any platform?). I'm getting anxious to fix this in blink too :-)

Still only on Windows in non-release channels. Per https://github.com/whatwg/dom/issues/23#issuecomment-127873286 Brian hopes to finish Linux this quarter. But then we still need someone to do it for Mac. Feel free to make the change in Blink first. :-) I'll happily update the specification once either ships.

Thanks Anne. We're still debating the urgency of this (we've mostly been happy to wait for compat results, but now reconsidering). I'll ping this bug if/when we decide to make the change in blink.

(In reply to Anne (:annevk) from comment #7) > Still only on Windows in non-release channels. Per > https://github.com/whatwg/dom/issues/23#issuecomment-127873286 Brian hopes > to finish Linux this quarter. But then we still need someone to do it for > Mac. Feel free to make the change in Blink first. :-) I'll happily update > the specification once either ships. I've put the patches for Linux up for review yesterday (bug 1026803).

Hi, in the current Firefox 41 beta (Windows) version the timeStamp values are broken (they are too inaccurate)! I'm using the timeStamp values in mouse events to calculate the speed of the mouse movement and an movement inertia when dragging and releasing an object. Before Firefox 41 beta it was working correctly, but now the timeStamp values are changing too slowly - that means the timeStamp difference between two events is almost always zero (normally it's ~16ms when rendering with 60hz). Enabling the setting 'dom.event.highrestimestamp.enabled' solves the problem, but that's not an option for common users! Please make sure that the current state of the timeStamp code will never become a public Firefox version because this will break many sites! Thanks and best regards, Klaus

Klaus, would you be willing to file a bug with steps to reproduce your timeStamp issue, please? The change in behavior with dom.event.highrestimestamp.enabled indicates that the proposal here would fix your issue, but we are not ready to make that change before releasing 41. It sounds like you have detected a regression in behavior. If we can identify what caused that, then it may be possible to undo much sooner than this bug will be fixed.

Hi Karl, Thanks! I've filled a new bug report here now: https://bugzilla.mozilla.org/show_bug.cgi?id=1202119 and here a simple online test case: http://krpano.com/firefox/bugs/event_timestamp/ Please let me know if the report is understandable and if reproducing is possible or if you would need any additional information. Klaus

(In reply to Brian Birtles (:birtles) from comment #0) > Once we have converted native event times to TimeStamp values we should > switch on dom.event.highrestimestamp.enabled by default. For Tor Browser we are considering setting dom.event.highrestimestamp.enabled pref to true by default, because the existing Event.timeStamp implementation exposes the system uptime, which is a problem for privacy, whereas the DOMHighResTimeStamp only reveals the navigation start (or web worker start) time: (see https://trac.torproject.org/projects/tor/ticket/17046 for details). Is there any reason why setting dom.event.highrestimestamp.enabled to true might be dangerous? Are you proposing converting TimeStamp values to native event times mainly because the latter are more accurate, or is there another reason?

(In reply to Arthur Edelstein from comment #13) > (In reply to Brian Birtles (:birtles) from comment #0) > > Once we have converted native event times to TimeStamp values we should > > switch on dom.event.highrestimestamp.enabled by default. > > For Tor Browser we are considering setting > dom.event.highrestimestamp.enabled pref to true by default, because the > existing Event.timeStamp implementation exposes the system uptime, which is > a problem for privacy, whereas the DOMHighResTimeStamp only reveals the > navigation start (or web worker start) time: (see > https://trac.torproject.org/projects/tor/ticket/17046 for details). > > Is there any reason why setting dom.event.highrestimestamp.enabled to true > might be dangerous? Are you proposing converting TimeStamp values to native > event times mainly because the latter are more accurate, or is there another > reason? Hi Arthur, As you say, switching on dom.event.highrestimestamp.enabled means reported event times are measured from navigationStart. The plan is to use this everywhere. Currently, with dom.event.highrestimestamp.enabled set to true, we have the current arrangement: a) Windows / Linux: UI events which have an OS-provided time (measured, e.g. from system start) have these times converted to an equivalent time that we can later expose as an offset from navigationStart. All other events (e.g. synthetic mouse events) are given an event time based on when the event was created inside Gecko and which is then exposed as an offset from navigationStart. b) Other (Mac etc.): All events are given an event time based on when the event was created inside Gecko. That time is then reported as an offset from navigationStart. That means that for (b) we ignore the event time values provided by the OS which means losing precision. The plan is to move all platforms currently in (b) to (a) and then turn on this pref. (So we are not "converting TimeStamp values to native event times" but actually the other way around.) So one danger of turning this on is you may lose event time precision on platforms other than Windows / Linux. The other issue regarding turning on this preference is that it has yet to be proven to be Web-compatible. We have had it turned on in Aurora/Nightly for Windows for over a year, and for Linux for a few weeks and I haven't heard of compatibility issues yet. Also, Chrome intends to make the same change. So, hopefully, it is ok.

We have a web compat issue reported in bug 1231619. See bug 1231619 comment 3.

Intent to ship: https://groups.google.com/forum/#!topic/mozilla.dev.platform/o1LT02foznI

Site compatibility doc: https://www.fxsitecompat.com/en-CA/docs/2017/event-timestamp-now-returns-domhighrestimestamp-by-default/

(In reply to Kohei Yoshino [:kohei] from comment #18) > Site compatibility doc: > https://www.fxsitecompat.com/en-CA/docs/2017/event-timestamp-now-returns- > domhighrestimestamp-by-default/ Wow, that was fast! However, I think the article says DOMHighResTimeStamp uses microseconds when it should say milliseconds.

Thanks! This explains better, hopefully: https://github.com/fxsitecompat/www.fxsitecompat.com/commit/78d9661

Comment on attachment 8839718 [details] Bug 1026804 - Turn on dom.event.highrestimestamp.enabled by default; https://reviewboard.mozilla.org/r/114300/#review115884

Pushed by bbirtles@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5d1d3f47d4f7 Turn on dom.event.highrestimestamp.enabled by default; r=smaug

I've updated the ref doc to account for this change: https://developer.mozilla.org/en-US/docs/Web/API/Event/timeStamp And added a note to the Fx54 release notes: https://developer.mozilla.org/en-US/Firefox/Releases/54#DOM_HTML_DOM Let me know if that's OK. Thanks!