High resolution timing for events

[annevk]

https://lists.w3.org/Archives/Public/public-web-perf/2014Jun/0013.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1026804

[annevk]

@birtles, what is the timeline for this?

[birtles]

I expect to finish converting our Linux UI event timestamps over on non-release channels this quarter. Still need to find someone to do the Mac work so we can switch this on for release channels.

[RByers]

We (@majido) are working on this in blink too. There are two completely different things coupled together here:

1. Use logical event time instead of strict "event creation time".
2. Use a monotonic/high-precision time (DOMHighRestTimestamp) instead of an epoch time.

It's 1 that's most important IMHO, giving us two key properties:

• Ability to accurately compute pointer velocity
• A basic way to measure input latency (very important for tracking improvements to some class of perf problems IMHO).
  But it's also potentially hardest to spec. Eg. does the spec currently require that events are delivered in increasing timestamp order? If we rely on OS/device timestamps then it's possible, for example, that a touchmove may be dispatched after a mousemove with a later timestamp.

WebKit has done 1 without 2 for a couple years now, but it's a kludge. Given the lack of use cases for an epoch-based event timestamp and the existing lack of interoperability here, I agree we should also try to change the semantics of timestamp.

[annevk]

This might not be web-compatible: https://bugzilla.mozilla.org/show_bug.cgi?id=1231619#c3. But perhaps browsers are willing to push it through anyway...

[RByers]

Yep, @majido says the compat impact seems manageable, so we're still pushing ahead with shipping in Chrome 49 (currently in beta, set to go stable in early March). If we have non-trivial compat issues we'll revert and revisit adding a new property instead.

[foolip]

Some fallout of the change: https://code.google.com/p/chromium/issues/detail?id=574514

[wycats]

I find it quite surprising that this is considered an acceptable web-compatible change, for the reasons that @chancancode discussed on the Bugzilla thread.

The jQuery API docs and MDN both define event.timeStamp as "The difference in milliseconds between the time the browser created the event and January 1, 1970". Incorrect or not, the practical effect of this is that lots and lots of code exists in the wild that assumes that new Date() and event.timeStamp can be compared to produce a relative amount of milliseconds.

Of course, new Date() and the old event.timeStamp are not very reliable as they are not monotonic (I'm very familar with these problems as the author of the RFCs that added Duration and timestamp functionality to Rust)

That said, I am shocked that decoupling the meaning of event.timeStamp from new Date() is considered even remotely web compatible. Immediate fallout included a demo @chancancode and I happened to be working on for the Ember rendering engine, Angular animation code, and the MSE test suite reported by @foolip.

A more conservative solution to the problem would be to introduce a new attribute (event.time as a nice shorter name? event.performance.timeStamp for symmetry with window.performance.*?).

Given the kinds of things that have blocked shipping recently for web-compat reasons, and the number of affected properties, I just don't understand how we're full steam ahead here. (In the linked case, the problematic feature had already shipped in IE11 and Edge years earlier, which made the number of affected properties quite small.)

To quote @chancancode:

By the way, if you are thinking that code that compares against wall-clock time is fundamentally "incorrect", I totally agree with you, and I am personally looking forward to using this feature. However, correctness is irrelevant here because event timestamps have always been tied to wall-clock time, and there are no better way to do this today. The fact is it basically work "good enough" for the majority cases that people have been able to build useful things on top of it today, and we should be careful not to break them. (For example, popular libraries like underscore uses Date.now for debouncing/throttling – while "incorrect", it obviously works "good enough" to be useful in the wild.)

I would quote him in full, but I'd recommend just reading the linked Bugzilla thread.

[RByers]

"Lots and lots of sites" has not been our experience. But as with anything compat, data trumps anecdote here. @majido, can you share your analysis from httparchive data? Anyone else have more examples of specific sites impacted? If we find a pattern that, say, we find used on >0.01% of the top sites in httparchive then we should definitely reconsider.

FWIW I argued ages ago for a new Event systemTime property, and we went around-and-around for years and couldn't get it spec'd anywhere due to constant debate about whether it was better to add a new property (if so which spec) or fix the old one. Firefox never implemented the UNIX-epoch version, so felt changing the timebase was already largely web compatible and understandably didn't want to regress to using wall-times in a property that was already (rightly) monotonic for them.

So attempting to ship a breaking change in Chrome was our compromise. So far it's hit Chrome beta with millions of users and very little fallout, so we have no reason to pull the plug yet. We're still willing for new data to change our mind, but the time for arguing-absent-hard-data (after more than 3 years of such arguing blocking solving the use cases here) is done IMHO.

[wycats]

So attempting to ship a breaking change in Chrome was our compromise. So far it's hit Chrome beta with millions of users and very little fallout, so we have no reason to pull the plug yet.

The problem with timing bugs is that they don't necessarily manifest as hard errors, by definition. Given how flaky some websites can be already, it may take some time before people report the bug, even to the original author, and before that bug gets reported upstream.

In this case, we rapidly discovered a (rather subtle) bug in a very popular animation library (Angular) that is easy to reproduce. How is that not sufficient?

(the fact that Angular has addressed the issue in 1.5 doesn't really do much -- some existing content will upgrade, but plenty won't)

[wycats]

If we find a pattern that, say, we find used on >0.01% of the top sites in httparchive then we should definitely reconsider.

Is there a way we can test uses of:

• e.timeStamp - anyDate
• anyDate - e.timeStamp
• var d = e.timeStamp, later: anyDate - d or d - anyDate

I'd be very very surprised if those patterns did not impact a non-trivial number of the top sites.

[RByers]

The problem with timing bugs is that they don't necessarily manifest as hard errors, by definition. Given how flaky some websites can be already, it may take some time before people report the bug, even to the original author, and before that bug gets reported upstream.

Yeah I agree that's cause for extra concern here. Also there may be non-visual cases where the breakage is hidden from us, eg. where the client sends the timestamp to the server for some analytics.

In this case, we rapidly discovered a (rather subtle) bug in a very popular animation library (Angular) that is easy to reproduce. How is that not sufficient?

We believe the impact in practice is small (due to low usage of the particular affected feature from our httparchive digging and as a result of being cosmetic). @majido can provide the concrete data from his analysis.

Is there a way we can test uses of: ...

Yes, the first two are, I believe, the analysis @majido has done on httparchive data for the top 470k websites. I'll let him provide details. Such code has always been broken on Firefox (except for the specific event that Angular was using, due to a bug in Firefox where it's timestamp was always 0), so it does make sense that developers haven't been relying on this.

I should add that unfortunately I'm out on vacation without internet for the next 1.5 weeks. Please continue discussing the tradeoff with Majid - he owns this feature on blink. If you like you're welcome to follow-up on the Intent to ship thread, it's possible other blink API owners with disagree with our judgement here and request the change be un-shipped.