Bug 85665 – HTML DOM Events timestamps are defined when dispatched and not when triggered

• Status: UNCONFIRMED
• Component: DOM

[Pablo Garaizar]

According to the HTML DOM Events specification, the timeStamp attribute should be set when the events are created, not when they are dispatched. 

Here is a proof of concept of this behaviour: http://jsfiddle.net/P59s6/ (pressing any key during the "sleep" loop will create an event that should differ on its timeStamp attribute from the timestamp taken when is dispatched).

[Pablo Garaizar]

Is there any comment from Webkit developers about this bug report?

[Mark Amery]

Pablo,

I just encountered the same issue, although I am not certain every detail of how you have reported it is accurate.

You imply that the dispatch property reflects event dispatch time rather than event creation time. However, if we manually create an Event object using JavaScript (e.g. if we run 

    e = document.createEvent("UIEvents");

) then the resulting event's timeStamp property is set to the time the event is created, and is not modified by dispatching the event with e.dispatchEvent().

Indeed, I'm not sure that Chrome's behaviour IS a violation of spec. The relevant section of spec (at https://dom.spec.whatwg.org/#dom-event-timestamp ) dictates that the timeStamp property must:

    > return the value it was initialized to. When an event is
    > created the attribute must be initialized to the number 
    > of milliseconds that have passed since 00:00:00 UTC on 1
    > January 1970, ignoring leap seconds.

but that alone isn't sufficient to support the argument that the behaviour you've observed is a spec violation. To support that argument, you *additionally* need to show that the spec demands that UI events get initialized as soon as the user takes the UI action that triggers their creation (like a click or keypress), and that the browser is not permitted to delay the creation of the event until queued JavaScript has finished executing. In the absence of any such demand from the spec, it seems to me that it would be reasonable to interpret the spec as permitting the timeStamp property of such an event to contain any time from when the user first performs the action to when the first JavaScript listener for the event starts to run.

The spec around this stuff is quite complicated, and I am not very experienced in reading it; I confess that I have no idea whether or not the spec dictates the precise moment at which an event must be created, nor how to find out. If you know more than me, and can point to the section of spec that makes such demand, perhaps doing so would be helpful in encouraging somebody to act on this?

Arguments from spec aside, there are two good reasons to regard the current behaviour as a bug and to change it even if it is not a spec violation:

1. Firefox behaves differently

2. Chrome's implementation makes it impossible to determine the time between two events (for example, to measure the duration of a click or touch) if other JavaScript is executing when the user action that triggers the event occurs. For instance, consider this jsfiddle: http://jsfiddle.net/gagLxrsc/1/

   In Firefox, the "Time between events" listed is always accurate. In Chrome, it is always wrong.

This is not a hypothetical use case; a Stack Overflow question about this precise scenario has 10000 views: http://stackoverflow.com/questions/1360818/javascript-how-to-measure-the-milliseconds-between-mousedown-and-mouseup

[Mark Amery]

In the latest version of Chrome, the JSFiddle I linked before (http://jsfiddle.net/gagLxrsc/1/) reports the click duration correctly. I therefore think this issue has now been fixed and can be closed.

[Lucas Forschler]

Mass move bugs into the DOM component.