Open Bug 1048096 Opened 10 years ago Updated 2 years ago

DOM wheel/keydown event.timeStamp changes to seconds resolution after 25 days system uptime

Categories

(Core :: Widget: Win32, defect)

31 Branch
x86_64
Windows 8.1
defect

Tracking

()

People

(Reporter: avih, Unassigned)

References

Details

(Keywords: regression, Whiteboard: tpi:-)

Posted at bug 77992 and filed here as a new bug, noticed with wheel event.timeStamp:

(In reply to Avi Halachmi (:avih) from comment #121)
> Not sure if it's relevant to this bug, but with Firefox 31 I see these
> e.timeStamp values on 3 events about 1 second apart:
> 
> - 18446744071575587000
> - 18446744071575587000
> - 18446744071575589000
> 
> The system has an uptime of just more than 25 days, and something started
> acting weird simetime during the past 24h window, I think. It seems the
> resolution dropped to 1s and the first two events happened within the same
> "bucket".
> 
> Maybe some overflow due to the system uptime? Maybe in combination with some
> of the patches which landed on 31?
> 
> FWIW, Date.time() returns "expected" values still, like 1407057517056.


(In reply to Emanuel Hoogeveen [:ehoogeveen] from comment #124)
> Given the 25 day uptime and the millisecond frequency it sounds like this is
> being stored as an int32_t at some point, then being converted to an
> uint64_t: an int32_t would take (2^31 - 1) / (1000*60*60*24) = 24.86 days to
> overflow.
Also, this was noticed on windows 8.1 with Firefox 31. Nightly doesn't seem affected by this, possibly due to bug 77992 being fixed.

On Nightly I've seen event.timeStamp values such as 1395756.732704084 .
Same behavior also noticed on DOM keydown event.
Summary: DOM wheel event.timeStamp changes to seconds resolution after 25 days system uptime → DOM wheel/keydown event.timeStamp changes to seconds resolution after 25 days system uptime
(In reply to Emanuel Hoogeveen [:ehoogeveen] from bug 77992 comment #124)
> Given the 25 day uptime and the millisecond frequency it sounds like this is
> being stored as an int32_t at some point, then being converted to an
> uint64_t: an int32_t would take (2^31 - 1) / (1000*60*60*24) = 24.86 days to
> overflow.

Yes, thanks.  windows/widget uses GetMessageTime [1], which returns the awkward type LONG.  That wraps to a -ve number after reaching LONG_MAX milliseconds.

Before http://hg.mozilla.org/mozilla-central/rev/bf2386d0cc1b, this was cast to PRUint32, giving sane overflow behavior.  Now, casting to uint64_t produces the leap towards the end of time.

That however, doesn't explain the drop in resolution to seconds.
I wondered about a cast somewhere to lower precision double, but I would have expected that produce increments of 2048, and I don't see any casts.
So I wonder about a bug in GetMessageTime().

Interestingly, GetMessageTime() docs say "To calculate time delays between messages, subtract the time of the first message from the time of the second message (ignoring overflow) and compare the result of the subtraction against the desired delay amount."
So it seems that Microsoft has its own variant of C++ whether signed overflow is defined.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms644939%28v=vs.85%29.aspx
Blocks: 569520
Depends on: 77992
Keywords: regression
Version: Trunk → 31 Branch
Depends on: 1026804
Component: DOM: Events → Widget: Win32
Whiteboard: tpi:-
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.