receivedTime and upcoming DOM update

[annevk]

We're planning on upgrading the default event timestamp to be high resolution. See

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

I don't think we should introduce a feature on an event that duplicates that.

[annevk]

Tracked for DOM in whatwg/dom#23

[cwilso]

I'm not sure what to do with this feedback. Yes, I'd wildly prefer not to introduce something different - but as it stands, event.timeStamp is defined as an unsigned long long, and we need a >ms resolution timestamp in MIDI events. What's the timeframe here?

[annevk]

Whenever Chrome or Firefox succeeds in shipping the upgrade of that type or decide to add a new property just for this.

[domenic]

Is it possible MIDIMessageEvent could have a double timeStamp property that shadows the one from Event? It could be removed if Event's timeStamp gets upgraded, but in the meantime allows us to have our cake and eat it too.

[cwilso]

If that's permitted and implementable, I'd rather do it that way (can even comment on it explicitly in the spec).

[domenic]

The only worry I have is if Web IDL has something against that. In JS it's straightforward.

[cwilso]

Actually, I also note that DOM4's timeStamp has a different zero reference (DOMTimeStamp is the number of milliseconds that has passed since 00:00:00 UTC on 1 January 1970). Gah.

[cwilso]

AKA: I presume @annevk @domenic , that the timestamp in event isn't going to change to navigation start; it's going to continue to be Unix time. That would force us to reset all the zero-time-reference to unix time, rather than nav start time.

[annevk]

I think it would not continue to be Unix time. That would end up being a rather large number, no?

[cwilso]

Really? You're going to redefine the "timestamp" parameter's origin, not just its type? Hmm. I guess that's okay, I just wasn't expecting it to take that big a compat leap. OK.

[domenic]

Wait, no, it needs to continue to be Unix time, as otherwise it's hell to interop with the Date constructor.

The numbers don't get any larger, they just get decimal points, right?

[agoode]

DOM2 allows for arbitrary epochs: http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html#Events-Event-timeStamp

DOM3 fixes this to the unix epoch: http://www.w3.org/TR/2012/WD-DOM-Level-3-Events-20120906/#events-event-type-timeStamp

It would be best if the epoch were system-defined, but it looks like that ship has sailed (in DOM3 and likely in implementations).

You can't express more than about 3 months of nanoseconds in 53 bits.

You can have 34 years at 100ns resolution (Windows resolution), and about 272 years at microsecond resolution.

So it's probably fine to make timestamp hi-resolution and keep the unix epoch, if you only care about microseconds. If we have 64-bit integers, we'd be better off. I think we still need a separate timestamp property with a recent epoch (page start is probably the best) to express nanoseconds at full precision.

[domenic]

Right. The plan that makes most sense to me is to continue using milliseconds-since-Unix-epoch. However, those milliseconds can be fractional as well. So instead of 1433878427031 we'd get maybe 1433878427031.1235.

Experimenting with my JS console (instead of working things out from first principles) it seems like we can get between 3 and 4 digits of resolution there. So basically between microseconds and 100 ns resolution.

So I guess this bug comes down to whether microseconds is good enough or not. If it is, we can repurpose event.timeStamp. If it isn't, we need a new thing.

[birtles]

We've been reporting Event.timestamp as a DOMHighResTimeStamp measured from navigationStart in Firefox on Windows Nightly/Aurora for about a year now. There haven't been any compatibility issues I'm aware of in that time but it's not a large user population.

(That said, for the platforms/channels where this change is not enabled, we report Event.timeStamps so inconsistently in Firefox I'd be surprised if anyone was able to make much use of them.)

Turning it on for other platforms and in release channels is basically just blocked on me doing the work to convert other platforms' native event times over.

[birtles]

I already proposed adding a new thing and got told to repurpose timeStamp:
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0046.html

I don't think you can have interop with Date if you want these values to be monotonically increasing. I also think making them monotonically increasing is more important and we can add conversion utilities for working with Date. Firefox already returns a bunch of Event.timeStamps as being relative to system start so anyone plugging them into the Date constructor is going to have a bad time.

(Also, making these times relative to navigationStart is useful for interop with rAF, performance.now(), document.timeline.currentTime, Web Animations etc.)

[agoode]

If compatibility is not an issue, then I agree having navigationStart as the epoch is a good solution.

[domenic]

Thanks @birtles,

Firefox already returns a bunch of Event.timeStamps as being relative to system start so anyone plugging them into the Date constructor is going to have a bad time.

is new information that I think gives us a lot more options.

How does this sound then?

• Web IDL redefines DOMTimeStamp to be a double
• DOM redefines the epoch for DOMTimeStamp to be navigation start. (Layering concerns? I guess HTML and DOM are already intertwingled. Or you could use a term like "time of document creation.")
• Web IDL encourages everyone that uses DOMTimeStamps to use the same epoch DOM uses (optional).

[annevk]

I think we should leave DOMTimeStamp alone. It might be used elsewhere. We should just use DOMHighResTimeStamp.

[agoode]

See also this discussion, related to input times more generally:
https://groups.google.com/a/chromium.org/forum/#!topic/input-dev/BnFdx9kD3Hg

[cwilso]

In short, we're just waiting for high-res event timestamps to become de rigueur and then we can remove our timestamp altogether. Really, could probably remove it now.

[cwilso]

This has happened, BTW.

[toyoshim]

I'm ready to drop receivedTime from Chrome Web MIDI implementation.
It should be pretty easy fix.
https://bugs.chromium.org/p/chromium/issues/detail?id=599335

[qdot]

Oh, wow, handy! I'll update this in the Firefox Implementation too (which I swear I'm still working on when I can)

[toyoshim]

Update from Chromium.

I'm making a change to show deprecation messages from m54, and will remove the receivedTime attribute at m56 if everything are fine.