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




Event Handling
8 years ago
2 years ago


(Reporter: Marc Bonnier, Unassigned)


Firefox Tracking Flags

(Not tracked)



(2 attachments)



8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: 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: on a label linked to a checkbox
Actual Results:  
The checkbox's event.timeStamp is zero.

Expected Results:  
The timeStamp should have a significant value.

Comment 1

8 years ago
Created attachment 441964 [details]
Test case #1
Note, DOM Events specification allows event.timeStamp to be zero.

Comment 3

8 years ago
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.

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.
And IIRC in Opera .timeStamp is always o

Comment 6

8 years ago
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

8 years ago
Created attachment 445301 [details]
Test case #2

"change" and "input" events on input and select elements also has timeStamp set to zero.
The issue (zero returning value) is no longer reproducible on Firefox 49.
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME

Comment 9

2 years ago
Never too late to be good, thanks!
You need to log in before you can comment on or make changes to this bug.