Bug Tracker

Opened 11 years ago

Closed 11 years ago

Last modified 8 years ago

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

testTimestamp.html (709 bytes) - added by julienw 11 years ago.
testcase of different timeStamps for the same event

Download all attachments as: .zip

Change History (13)

Changed 11 years ago by julienw

Attachment: testTimestamp.html added

testcase of different timeStamps for the same event

comment:1 Changed 11 years ago by 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

comment:2 Changed 11 years ago by davidserduke

Same thing done in FF3:

timestamp is 1231948125988

timestamp is 1231948126368

timestamp is 30950500

timestamp is 30951062

comment:3 Changed 11 years ago by davidserduke

Summary: the timeStamp property is sometimes not consistentthe 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 11 years ago by davidserduke

Type: bugenhancement

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

comment:5 Changed 11 years ago by john

Milestone: 1.31.3.1
Owner: changed from brandon to flesler
Version: 1.2.61.3

comment:6 Changed 11 years ago by flesler

Cc: julienw davidserduke added
Status: newassigned

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 11 years ago by 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 ?

comment:8 Changed 11 years ago by 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.

comment:9 Changed 11 years ago by 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.

comment:10 Changed 11 years ago by 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).

comment:11 Changed 11 years ago by flesler

Resolution: fixed
Status: assignedclosed

Fixed at [6132].

comment:12 Changed 8 years ago by 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.

Note: See TracTickets for help on using tickets.