Side navigation
#3843 closed enhancement (fixed)
Opened January 14, 2009 10:52AM UTC
Closed January 19, 2009 10:20PM UTC
Last modified March 14, 2012 11:00PM UTC
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 (12)
Changed January 14, 2009 03:47PM UTC by comment:1
Changed January 14, 2009 03:49PM UTC by comment:2
Same thing done in FF3:
timestamp is 1231948125988
timestamp is 1231948126368
timestamp is 30950500
timestamp is 30951062
Changed January 14, 2009 04:00PM UTC by comment:3
| 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.
Changed January 14, 2009 04:31PM UTC by comment:4
| type: | bug → enhancement |
|---|
I don't believe jQuery is creating any timestamps for events so this would be an enhancement to the event system.
Changed January 15, 2009 02:17PM UTC by comment:5
| milestone: | 1.3 → 1.3.1 |
|---|---|
| owner: | brandon → flesler |
| version: | 1.2.6 → 1.3 |
Changed January 18, 2009 06:37PM UTC by comment:6
| cc: | → julienw, davidserduke |
|---|---|
| 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.
Changed January 18, 2009 06:57PM UTC by comment:7
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 ?
Changed January 18, 2009 07:00PM UTC by comment:8
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.
Changed January 18, 2009 08:21PM UTC by comment:9
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.
Changed January 19, 2009 08:57PM UTC by comment:10
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).
Changed January 19, 2009 10:20PM UTC by comment:11
| resolution: | → fixed |
|---|---|
| status: | assigned → closed |
Fixed at [6132].
Changed July 28, 2011 07:14PM UTC by comment:12
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.
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