What Firefox version are you testing? Event.timeStamp returns a DOMHighResTimeStamp on Firefox Nightly and Developer Edition. See https://developer.mozilla.org/en-US/Firefox/Releases/33/Site_Compatibility#event.timeStamp_now_returns_DOMHighResTimeStamp_on_Nightly.2FAurora_for_Windows and Bug 1026804.
Component: Untriaged → DOM: Events
Product: Firefox → Core
This doesn't return a DOMHighResTimeStamp on Firefox Nightly for OS X: > window.addEventListener('click', event => console.log(event.timeStamp)); So only specific events, probably video/audio-related, are returning a DOMHighResTimeStamp?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 39 Branch → Trunk
As specified in the task this was on Firefox 39. Note that I was using a video related event in the fiddle. event.timeStamp.constructor.name returned "Number" (just as Date.now()). Even if a DOMHighResTimeStamp was returned, from my understanding the pre-fraction digits should be the same, the millisecond fractions should be reflected by digits after the decimal point (which is not the case here if you inspect the console output of the fiddle more closely).
Our current Event.timeStamp implementation is a mess. We use different time scales for different events. Currently we're trying to switch everything over to DOMHighResTimeStamp but it's taking time to convert the native timestamps over correctly (bug 1026803). I'm going to get that moving again this quarter. I think we only have the DOMHighResTimeStamp path switched on for Windows on Nightly/Aurora (aka Developer Edition).
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 3 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.