Skip to main content

Bug Tracker

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)
  • testTimestamp.html (0.7 KB) - added by julienw January 14, 2009 10:53AM UTC.

    testcase of different timeStamps for the same event

Change History (12)

Changed January 14, 2009 03:47PM UTC by davidserduke comment:1

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

Changed January 14, 2009 03:49PM UTC by davidserduke 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 davidserduke comment:3

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.

Changed January 14, 2009 04:31PM UTC by davidserduke comment:4

type: bugenhancement

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 john comment:5

milestone: 1.31.3.1
owner: brandonflesler
version: 1.2.61.3

Changed January 18, 2009 06:37PM UTC by flesler comment:6

cc: → julienw, davidserduke
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.

Changed January 18, 2009 06:57PM UTC by flesler 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 flesler 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 dmethvin 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 john 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 flesler comment:11

resolution: → fixed
status: assignedclosed

Fixed at [6132].

Changed July 28, 2011 07:14PM UTC by dmethvin 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.