Closed Bug 1026804 Opened 10 years ago Closed 7 years ago

Make Event.timeStamp return a DOMHighResTimeStamp by default (switch on pref)

Categories

(Core :: DOM: Events, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox54 --- fixed

People

(Reporter: birtles, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: dev-doc-complete, site-compat)

Attachments

(1 file)

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.
Blocks: 1048096
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.
Flags: needinfo?(bbirtles)
(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.
Flags: needinfo?(bbirtles)
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?
Flags: needinfo?(bbirtles)
(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.
Flags: needinfo?(bbirtles)
Depends on: 1207412
Depends on: 1231619
We have a web compat issue reported in bug 1231619.  See bug 1231619 comment 3.
Depends on: 1261894
(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.
Comment on attachment 8839718 [details]
Bug 1026804 - Turn on dom.event.highrestimestamp.enabled by default;

https://reviewboard.mozilla.org/r/114300/#review115884
Attachment #8839718 - Flags: review?(bugs) → review+
Pushed by bbirtles@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5d1d3f47d4f7
Turn on dom.event.highrestimestamp.enabled by default; r=smaug
https://hg.mozilla.org/mozilla-central/rev/5d1d3f47d4f7
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
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!
You need to log in before you can comment on or make changes to this bug.