[Webkit-unassigned] [Bug 85665] HTML DOM Events timestamps are defined when dispatched and not when triggered

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=85665

Mark Amery <markamery at btinternet.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markamery at btinternet.com

--- Comment #2 from Mark Amery <markamery at btinternet.com> ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141216/94897b6d/attachment-0002.html>