Skip to main content

Bug Tracker

Side navigation

#10755 closed bug (cantfix)

Opened November 11, 2011 09:34AM UTC

Closed March 03, 2012 10:18PM UTC

Last modified October 24, 2012 12:43PM UTC

e.timeStamp (JQ 1.7) wrong value in Firefox, Opera

Reported by: anonymous Owned by: dmethvin
Priority: low Milestone:
Component: event Version: 1.7
Keywords: Cc:
Blocked by: Blocking:

Wrong timestamp value in FF.

Was correct in 1.6.4

Attachments (0)
Change History (26)

Changed November 11, 2011 01:11PM UTC by dmethvin comment:1

owner: → anonymous
status: newpending

This seems to work fine for me on Firefox 8, in that the timestamp is present and increases on each click. Which version are you using, and what values do you expect?

Changed November 12, 2011 09:35AM UTC by anonymous comment:2

status: pendingnew

I also use FF8.

Timestamp jq 1.6.4: 1321090259864

Timestamp jq 1.7 (FF): 96653321

Timestamp jq 1.7 (Chrome): 1321090329822

Not enough digits in FF.

Changed November 12, 2011 02:38PM UTC by dmethvin comment:3

component: unfiledevent
owner: anonymousdmethvin
priority: undecidedlow
status: newassigned

Changed November 12, 2011 02:52PM UTC by dmethvin comment:4

I have filed a bug with Firefox on this, let's see if they can fix it quickly.

In the meantime, you can simply say "new Date()" in your event handler. That was taken out in 1.7 because it turned out to be an expensive operation to do by default when so few people need the value.

Changed November 14, 2011 09:16PM UTC by dmethvin comment:5


OK, well if you follow that link above it turns out my ticket is a dup of this circa-2004 bug:

The timestamp is being truncated. However, I am hesitant to simply go back to what we were doing before (assigning our own new Date in our handler) because it is wrong. The event.timestamp is supposed to be the time the event was created *in the browser*:

Many milliseconds (or even seconds in the worst case) can go by before the event makes it to jQuery where we would timestamp it with our fake stamp. If someone just needs to know what time it is at the point their own code is running, they can do their own new Date(). If, however, they need to know when the event was created, then we're just papering over the problem, adding time to event setup, and lying about when the event was created.

Since anonymous reported this, I can't ask them about their particular application. Other feedback welcome, but at this point I'm not pegging it to a release until we know more about how that fix should look.

Changed December 04, 2011 04:25PM UTC by Cokegod comment:6

You are correct that it is better to follow the W3C specs, but jQuery already puts in event.timeStamp when the event doesn't have a value for timeStamp, which is against the W3C specs. Therefore I do not think this is a proper reason for not setting the event.timeStamp to the value of new Date() in case of wrong data.

Changed December 09, 2011 11:07PM UTC by kb comment:7

This bug is even worse in Opera 11.60. gives a negative value:


Changed December 21, 2011 12:20AM UTC by dmethvin comment:8

#11080 is a duplicate of this ticket.

Changed December 21, 2011 12:24AM UTC by dmethvin comment:9

@Cokegod, that was so triggered synthetic events would get a timestamp.

@kb, please report that bug to Opera.

I still believe the 1.6.4 behavior is incorrect; there is no reason to always stick new Date() into that field after the fact since you can easily get that time in your own event handler.

Does anyone have a resolution that will still make timeStamp useful for the purpose the W3C intended?

Changed December 21, 2011 01:05AM UTC by bjmw comment:10

I posted #11080. Sorry for the duplicate. Two points:

1. It doesn't work at all in IE8 now (not sure about IE9), "undefined" being returned.

2. If one cannot make it work as per the W3C specs, for the reasons given above, then why not leave it as it was and not break backwards compatibility too?

Changed December 21, 2011 01:08AM UTC by dmethvin comment:11

What are you using this value for? If it is to get the *current* time then use new Date. If it is for some other purpose, please give us some more information.

Changed February 01, 2012 01:25PM UTC by bjmw comment:12

It is to find the time that an event occured. For the reasons explained in comment 5, this is unlikely to be accurate so it is essentially returning the current time; so. for sure, I can alter my code to new Date and get the same thing.

However, the two points remain:

1. It is introducing unnecessary regressions. Some of these are fatal (e.g. on IE8).

2. The documentation is now not correct and developers will waste time trying to work out why their code doesn't work they way it is supposed to.

Changed February 01, 2012 01:43PM UTC by dmethvin comment:13

Can you clarify how this is fatal in IE8? As you say, the purpose of that field is to determine when the event occurred. On browsers that get it wrong, we cannot provide the information. All we can do is lie about it, which was what we did before 1.7. If we do that, you will never know whether the data in that field is correct or not.

Changed February 21, 2012 12:11PM UTC by addyosmani comment:14

#11362 is a duplicate of this ticket.

Changed February 21, 2012 12:18PM UTC by addyosmani comment:15

summary: e.timeStamp (JQ 1.7) wrong value in Firefoxe.timeStamp (JQ 1.7) wrong value in Firefox, Opera

Changed February 21, 2012 01:20PM UTC by dmethvin comment:16

cc: → miketaylr

Now Opera and Firefox can have a contest to see who can fix this first. My money is on Opera.

Changed February 21, 2012 03:08PM UTC by miketaylr comment:17

Already fixed in Opera Next (Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; Edition Next; en) Presto/2.10.255 Version/12.00).

What do I win? :P

Changed February 21, 2012 06:19PM UTC by dmethvin comment:18

You win a happy tweet! Thanks again.

Changed March 03, 2012 10:18PM UTC by dmethvin comment:19

resolution: → cantfix
status: assignedclosed

Lacking any compelling use cases for a fake timestamp, I'll close this and we can hope that Firefox will fix their bug at some point. I'm using cantfix since the only "fix" we could apply is to put the wrong value into timeStamp.

Changed March 14, 2012 04:40AM UTC by anonymous comment:20

This doesn't seem to work in IE8, but works in IE9. Is there a need to put in a fix for IE8?

Changed March 26, 2012 10:37AM UTC by anonymous comment:21

timestamp is not working in opera it return 0

Changed March 26, 2012 03:18PM UTC by miketaylr comment:22

Hi anonymouse,

Can you verify what version of Opera you're testing in? Versions < 12 have this bug, but it's been fixed for the next release.

Changed October 22, 2012 06:07AM UTC by anonymous comment:23

Hi dmethvin,

Why did you close this bug?

also returns incorrect value in IE7 and IE8 (not test IE9), not only in FF.

Changed October 22, 2012 02:09PM UTC by dmethvin comment:24

It's closed cantfix because we can't fix it. We do not know when the browser queued the event for eventual delivery to JavaScript. If you have ideas on how to fix it please let us know.

Changed October 24, 2012 03:34AM UTC by anonymous comment:25

Replying to [comment:25 dmethvin]:

It's closed cantfix because we can't fix it. We do not know when the browser queued the event for eventual delivery to JavaScript. If you have ideas on how to fix it please let us know.

I don't have any idea of why

returns incorrect value in FF, possibly it's a FF bug. But if
(IE7,8), it should be assigned to the time when jQuery Event object is created. Actually, you already do it in jQuery.Event constructor:

// Create a timestamp if incoming event doesn't have one
this.timeStamp = src && src.timeStamp ||;

However, it is overwritten by jQuery.event.fix:

event = jQuery.Event( originalEvent );

for ( i = copy.length; i; ) {
	prop = copy[ --i ];
	event[ prop ] = originalEvent[ prop ];

Is it intended? if not so, please fix it. Thanks!

Changed October 24, 2012 12:43PM UTC by dmethvin comment:26

cc: miketaylr

We add the time for synthetic events. They should be present for native events. Setting the current time in the jQuery event handler would not tell you when the event was queued. If that difference (queued time vs clock time) doesn't matter in your application, your event handler should just use new Date().getTime()