the timeStamp property is sometimes not consistent in Firefox

[julienw]

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.

[julienw]

testcase of different timeStamps for the same event

[davidserduke]

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

[davidserduke]

Same thing done in FF3:

timestamp is 1231948125988

timestamp is 1231948126368

timestamp is 30950500

timestamp is 30951062

[davidserduke]

Tested IE6, IE7, Opera 9.26, Safari Win 3, FF2 and FF3. Only the FireFox 2 and 3 browsers have this issue.

[davidserduke]

I don't believe jQuery is creating any timestamps for events so this would be an enhancement to the event system.

[flesler]

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.

[flesler]

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 ?

[flesler]

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.

[dmethvin]

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.

[john]

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).

[flesler]

Fixed at [6132].

[dmethvin]

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.