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

The change has been on Chrome Canary since Dec 3rd, and in Beta channel for more than two weeks now. Here are the reported issues that I am aware of so far:

1. [BugSnag](https://github.com/bugsnag/bugsnag-js/issues/130), a fairly popular error reporting tool
Issue: Incorrect "millisecondsAgo" is reported to the backend server for last event that occurred before error.
Firefox workaround: None, already broken on Firefox.
Status: Developer is looking into a fix. The data may be cleaned up in the backend.

2. [Angular CSS animation module](https://bugzilla.mozilla.org/show_bug.cgi?id=1231619)
Issue: If Angular CSS animation is used that has a 'start-delay', it may end later that expected.
Firefox workaround: They were using timeStamp = e.timeStamp || Date.now() pattern that depends on animation event timeStamp being 0 in Firefox.
Status: Fixed on trunk. Other simple workarounds [exist](https://bugzilla.mozilla.org/show_bug.cgi?id=1231619#c14).

3. [Youtube HTML5 player](https://code.google.com/p/chromium/issues/detail?id=574514)
Issue: Event timeStamp is used to measure event processing latency. The event is ignored similar to their behaviour on Firefox.
Firefox workaround: If timeStamp is not within expected range it is ignored.
Status: Fix in progress. High-res timeStamp will more accurately reflect the actual processing latency.

4. [Plus-for-Trello Chrome Extension](https://code.google.com/p/chromium/issues/detail?id=578243#c14)
Issue: ????
Firefox workaround: N/A, extension was chrome only
Status: Fixed.

5. [Glimmer demo code](https://github.com/tildeio/glimmer/pull/66)
Issue: ???

Is there are other issue that Firefox folks (@birtles is that you?) are aware of.
Also more importantly I like to know their opinion and insight on the scope and impact of web-compat issues so far.

IMO @domenic is right to categorize these as survivable 
(i.e., small in scope with little or no impact on user-facing functionality) and that it is worth paying small cost of breaking web-compat here to avoid having two timestamps attributes with different semantics for foreseeable future specially given all the issues that currently plague event.timeStamp (A few are listed [here](https://github.com/whatwg/dom/issues/23#issuecomment-181579384)).

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