Intent to Implement and Ship: High Resolution Time for Event.timeStamp

[Majid Valipour]

Contact emails
maj...@chromium.org, rbyers@chromium.org

Spec
https://github.com/whatwg/dom/issues/23

Additional discussion: https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0046.html

Summary
Change Event.timeStamp to be a DOMHighResTimeStamp which is a high resolution monotonic time with microseconds resolution instead of DOMTimeStamp which is an epoch time with millisecond resolution. For input events, the timestamp value will represent the underlying OS timestamp for the event, for any other event the value will continue to be the event creation time.

Motivation
Currently exposed event timestamp represents the dispatch epoch time, has only milliseconds resolution, and is subject to unexpected system time adjustment skews which makes it unsuitable for accurate measurement relative time between input events. Exposing platform monotonic timestamp as DOMHighResTimeStamp addresses all these issues. This change enables implementation of functionalities which are not possible today such as accurate measurement of pointer velocity, input latency measurement tools, and etc.
     
Compatibility Risk
Firefox: In development (Shipping by default in their Aurora channel)
Edge: No public signals
Safari: No public signals but they use platform monotonic timestamp but convert it to epoch time before exposing it.
Web developers: Positive

Mozilla is actively working to make the switch and there is consensus in DOM WG to change DOM specification to reflect this change once it is shown that potential compat issues are addressable by vendor implementations (more on this below). We believe the risk is small enough that we should try and ship it.

The compatibility risk of this change is mostly due to change in time origin from epoch time to navigation start time. There are few factors that reduce this risk:

• All known use cases rely on relative time which only gets more accurate for input events and fixes time skew bugs.

• Event.timeStamp has been incompatible between browsers already. Firefox uses monotonic timestamp. Safari transforms event’s monotonic platform timestamp to epoch time. Chrome return an epoch timestamp that is essentially the time of the dispatch.

• Mozilla have had it in Aurora/Nightly for Windows for over a year, and for Linux for a month. So far not report of compatibility issues yet. This is small sample set but still useful.

• It is easy to polyfil the old behaviour if needed.

Ongoing technical constraints
None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)? Yes or no.
Yes.

OWP launch tracking bug
https://code.google.com/p/chromium/issues/detail?id=538600


Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/5523910145605632

Requesting approval to ship?
Yes

[Ilya Grigorik]

\o/ ... this will go a long way towards helping developers accurately measure the R(esponse) component of RAIL. +1.

[Chris Harrelson]

LGTM1

On Fri, Oct 2, 2015 at 9:33 AM, 'Ilya Grigorik' via blink-dev <blin...@chromium.org> wrote:

\o/ ... this will go a long way towards helping developers accurately measure the R(esponse) component of RAIL. +1.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

+Anne and Brian who are working on this from the spec and Mozilla sides respectively.

I just want to reinforce what Ilya said about the critical use cases.  This is even more important for the A(nimation) component of RAIL.  Eg. imagine you have a site that responds to touchmove and mousemove to drag something around (like Google maps).  It's critical that you minimize latency from hardware event to paint (and maximize latency consistency).  But today the biggest source of jank here (main thread contention) is notoriously difficult to measure.  The frame timing API will help, but it won't be enough to correlate directly with input.

Simply plumbing through a useful input timestamp will be hugely valuable here (today the event timestamp is basically useless - equivalent to Date.now() for all intents and purposes).  There's been lots of debate on how best to do this over the years (IIRC we had a first WebKit patch up for review ~4 years ago), but it all hinges on speculation on what's web compatible and what's not.

Now we have a consensus in the DOM spec community on what the ideal API is, and we lack any concrete examples where it poses a compatibility problem.  So I feel we should just try to ship this, and if we hit issues in practice we can take what we learned back to the WhatWG and try something else (eg. introduce a new platformTimestamp field on Event if absolutely necessary).

Rick

[Jochen Eisinger]

lgtm2

[Elliott Sprehn]

Just make sure this is clamped in the same way that performance.now() is, we really need to get that moved into a shared helper that all systems use. :)

[Rick Byers]

On Sat, Oct 3, 2015 at 1:00 AM, Elliott Sprehn <esp...@chromium.org> wrote:

Just make sure this is clamped in the same way that performance.now() is, we really need to get that moved into a shared helper that all systems use. :)

Yep, Majid has already landed that with a test (specific to this use case).  I agree that any other use cases should use the same logic.

[Philip Jägenstedt]

LGTM3

[godfr...@gmail.com]

We have identified some compatibility issues with this feature that, imo, could have wide-reaching impact and cannot be easily detected (both in terms of usage and breakage). As requested by rbyers, I'm the discussions cross-posting here.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1231619#c15 and https://github.com/whatwg/dom/issues/23#issuecomment-180664406 for details.

On Friday, October 2, 2015 at 9:24:20 AM UTC-7, Majid Valipour wrote:

Contact emails
maj...@chromium.org, rby...@chromium.org

[Majid Valipour]

On Mon, Feb 8, 2016 at 5:04 PM <godfr...@gmail.com> wrote:

We have identified some compatibility issues with this feature that, imo, could have wide-reaching impact and cannot be easily detected (both in terms of usage and breakage). As requested by rbyers, I'm the discussions cross-posting here.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1231619#c15 and https://github.com/whatwg/dom/issues/23#issuecomment-180664406 for details.

We have been anticipating and are closely monitoring potential we-compat issues with this change. The spec change and our shipping of this feature depends on our evaluation of these web-compat issues which as you pointed out are not really measurable in advance. rbyers@ has summarized this pretty well earlier in this thread: 

> There's been lots of debate on how best to do this over the years (IIRC we had a first WebKit patch up for review ~4 years ago), but it all hinges on speculation on what's web compatible and what's not.

> Now we have a consensus in the DOM spec community on what the ideal API is, and we lack any concrete examples where it poses a compatibility problem.  So I feel we should just try to ship this, and if we hit issues in practice we can take what we learned back to the WhatWG and try something else (e.g., introduce a new platformTimestamp field on Event if absolutely necessary).

Both Rick and I are engaged on the whatwg spec issue and mozilla bug and have provided our findings so far. At the moment, the plan is still to continue with shipping this in M49 but I will update this thread if the spec editors consensus changes (e.g., to introduce a new field for high-res timestamp instead).

Majid

[Philip Jägenstedt]

For everyone who isn't subscribed to the issue, note that Majid just wrote an excellent summary of the reported breakage:

https://github.com/whatwg/dom/issues/23#issuecomment-184702178

Philip