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

>> 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.

>But I'm not aware of Firefox necessarily using a monotonic clock for event timestamps. I think we did in some (very few) cases, sometimes along with having the timestamp be in microseconds instead of milliseconds, mostly used wall-clock UNIX-epoch, and sometimes used 0...

Firefox Event.timeStamp is a mixed bag. Here is what I have gathered based on my tests on Firefox which is also close to what is claimed [here](https://bugzilla.mozilla.org/show_bug.cgi?id=77992#c60):
1- zero: animation, transition, load events, scroll, resize, focus, blur, drag/drop
2- monotonic (?) since system startup in milliseconds: mouse, wheel, key, touch, click events
3- epoch in milliseconds: composition events,  'input' event, change
4- epoch in microseconds: custom events, hashchange, popstate

> But I'm not aware of Firefox necessarily using a monotonic clock for event timestamps. I think we did in some (very few) cases

All mouse, wheel, key, touch, click events seem to use a monotonic clock timestamp. I wouldn't call this very few.

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