Bug Tracker

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#10755 closed bug (cantfix)

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

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

Description

Wrong timestamp value in FF. Was correct in 1.6.4 http://jsfiddle.net/YNAc6/

Change History (26)

comment:1 Changed 8 years ago by dmethvin

Owner: set to 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?

comment:2 Changed 8 years ago by anonymous

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.

comment:3 Changed 8 years ago by dmethvin

Component: unfiledevent
Owner: changed from anonymous to dmethvin
Priority: undecidedlow
Status: newassigned

comment:4 Changed 8 years ago by dmethvin

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

https://bugzilla.mozilla.org/show_bug.cgi?id=702015

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.

comment:5 Changed 8 years ago by dmethvin

Milestone: None1.next

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

https://bugzilla.mozilla.org/show_bug.cgi?id=238041

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*:

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-event-type-timeStamp

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.

comment:6 Changed 8 years ago by Cokegod

You are correct that it is better to follow the W3C specs, but jQuery already puts jQuery.now() 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.

comment:7 Changed 8 years ago by kb

This bug is even worse in Opera 11.60. http://jsfiddle.net/YNAc6/ gives a negative value: -2147483648

comment:8 Changed 8 years ago by dmethvin

#11080 is a duplicate of this ticket.

comment:9 Changed 8 years ago by dmethvin

@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?

comment:10 Changed 8 years ago by bjmw

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.
  1. 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?

comment:11 Changed 8 years ago by dmethvin

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.

comment:12 Changed 8 years ago by bjmw

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

comment:13 Changed 8 years ago by dmethvin

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.

comment:14 Changed 8 years ago by addyosmani

#11362 is a duplicate of this ticket.

comment:15 Changed 8 years ago by addyosmani

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

comment:16 Changed 8 years ago by dmethvin

Cc: miketaylr added

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

comment:17 Changed 8 years ago by miketaylr

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

comment:18 Changed 8 years ago by dmethvin

You win a happy tweet! Thanks again.

comment:19 Changed 8 years ago by dmethvin

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.

comment:21 Changed 8 years ago by anonymous

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

comment:22 Changed 8 years ago by anonymous

timestamp is not working in opera it return 0

comment:23 Changed 8 years ago by miketaylr

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.

comment:24 Changed 7 years ago by anonymous

Hi dmethvin, Why did you close this bug? event.timeStamp also returns incorrect value in IE7 and IE8 (not test IE9), not only in FF.

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

comment:26 in reply to:  25 Changed 7 years ago by anonymous

Replying to 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 event.timeStamp returns incorrect value in FF, possibly it's a FF bug. But if event.timeStamp is undefined (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 || jQuery.now();

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!

comment:27 Changed 7 years ago by dmethvin

Cc: miketaylr removed

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

Note: See TracTickets for help on using tickets.