#3843 closed enhancement (fixed)
the timeStamp property is sometimes not consistent in Firefox
| Reported by: | julienw | Owned by: | flesler |
|---|---|---|---|
| Priority: | major | Milestone: | 1.3.1 |
| Component: | event | Version: | 1.3 |
| Keywords: | timestamp | Cc: | julienw, davidserduke |
| Blocked by: | Blocking: |
Description
In the attached testcase, the timeStamp we get is not the same when you click on the button or when you press enter, running with Firefox (I checked that with IE6, they're the same).
I believe that's because sometimes it is provided by the browser and sometimes not.
Maybe jQuery should generate its own timeStamp no matter what.
Attachments (1)
Change History (13)
Changed 13 years ago by
| Attachment: | testTimestamp.html added |
|---|
comment:1 Changed 13 years ago by
From IE7 the first two are from enter, the second two are from clicks. Looks good to me so far.
timestamp is 1231947965046
timestamp is 1231947965156
timestamp is 1231947967390
timestamp is 1231947968437
comment:2 Changed 13 years ago by
Same thing done in FF3:
timestamp is 1231948125988
timestamp is 1231948126368
timestamp is 30950500
timestamp is 30951062
comment:3 Changed 13 years ago by
| Summary: | the timeStamp property is sometimes not consistent → the timeStamp property is sometimes not consistent in Firefox |
|---|
Tested IE6, IE7, Opera 9.26, Safari Win 3, FF2 and FF3. Only the FireFox 2 and 3 browsers have this issue.
comment:4 Changed 13 years ago by
| Type: | bug → enhancement |
|---|
I don't believe jQuery is creating any timestamps for events so this would be an enhancement to the event system.
comment:5 Changed 13 years ago by
| Milestone: | 1.3 → 1.3.1 |
|---|---|
| Owner: | changed from brandon to flesler |
| Version: | 1.2.6 → 1.3 |
comment:6 Changed 13 years ago by
| Cc: | julienw davidserduke added |
|---|---|
| Status: | new → assigned |
We do, we add our own timeStamp when none is available. That's probably just for triggered events.
I'll look into this, maybe the solution is just using ours always, but I'm not sure that'd be 100%... correct, so to speak.
comment:7 Changed 13 years ago by
Ok, being playing a little with this. Indeed only FF has this problem. Some events do work like dblclick, submit. The also compared the native timestamp to a new Date and it was always equal. So we could just override timeStamp for all browsers... any thoughts ?
comment:8 Changed 13 years ago by
Forgot to say... I tried saving the page start timestamp and then deducting it from each timestamp. The thing is FF was returning stuff like: -1232195847437
So it's not just a few ms different, it's awfully wrong.
comment:9 Changed 13 years ago by
Yeah, I tried looking at the timestamp in hex, in case it was truncated to a fewer number of bits perhaps, and it doesn't make more sense that way either.
Maybe having jQuery always set the timeStamp might be the right solution.
This also seems like a Firefox bug to me, but I didn't find any tickets on Bugzilla.
comment:10 Changed 13 years ago by
I agree with Dave that the right solution should probably be to always override the result (it doesn't seem like there's much harm in it, either).
comment:12 Changed 10 years ago by
During some recent performance checks, I found that creating the timestamp is a very expensive operation in new jQuery.Event. The test case appears to work in Firefox 3.6, 4 and 5 now, and Firefox was the only browser to have the problem, so I may return to the previous behavior of only creating a Date if there is no .timeStamp already present.
testcase of different timeStamps for the same event