Re: [dom] High resolution timing for events (#23)

> 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](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/hfkkQiuMgkQ), it's possible other blink API owners with disagree with our judgement here and request the change be un-shipped.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/23#issuecomment-180686548