562197 - checkbox click event from a click on a related label has a timeStamp set to 0

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Marc Bonnier]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

When a checkbox click event is generated from a click on a related label then, the checkbox Event has a timeStamp set to 0.

Reproducible: Always

Steps to Reproduce:
1.click on a label linked to a checkbox
2.
3.
Actual Results:  
The checkbox's event.timeStamp is zero.

Expected Results:  
The timeStamp should have a significant value.

Comment 1

[Marc Bonnier]

Attachment: Test case #1

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Note, DOM Events specification allows event.timeStamp to be zero.

Comment 3

[Marc Bonnier]

Indeed, from specification:

"Used to specify the time (in milliseconds relative to the epoch) at which the
event was created. Due to the fact that some systems may not provide this
information the value of timeStamp may be not available for all events. When not
available, a value of 0 will be returned. Examples of epoch time are the time of
the system start or 0:0:0 UTC 1st January 1970."

But if the timeStamp is available when the user clicks on the checkbox I assume
it is provided by "the system". Therefore if the event is indirectly triggered
from the user clicking on the associated label it should be set in the checkbox's event.
From the JavaScript application's perspective, it does not make sense to have
it set to zero when a user clicked on the label instead of the checkbox.

Also the timeStamp value does not follow the spec as it is not the "time (in milliseconds relative to the epoch)" but rather seems to be the time relative to the last browser restart.

WebKit provide both the correct timeStamp for label-triggered event as well as the value from the epoch. It should be desirable to have both fixed and have consistent behavior across browsers.

Thanks.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Actually in Webkit the behavior of .timeStamp depends on the browser.
Chrome does something, Safari something else.

But yes , I agree would be good to have some reasonable value for .timeStamp.
I need to update a patch for that.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

And IIRC in Opera .timeStamp is always o

Comment 6

[Marc Bonnier]

I know. Because of all the quirks and bugs I had to work around in Opera
I would not call this browser a "reference" implementation...

Comment 7

[Marc Bonnier]

Attachment: Test case #2

"change" and "input" events on input and select elements also has timeStamp set to zero.

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The issue (zero returning value) is no longer reproducible on Firefox 49.

Comment 9

[Marc Bonnier]

Never too late to be good, thanks!