[FIXr]timeStamp is zero for script generated events

RESOLVED FIXED in mozilla1.7beta

Status

()

defect
P3
normal
RESOLVED FIXED
18 years ago
11 years ago

People

(Reporter: vladimire, Assigned: bzbarsky)

Tracking

(Blocks 1 bug)

Trunk
mozilla1.7beta
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Reporter

Description

18 years ago
If an event is generated from script the timeStamp attribute of the event is zero.
Reporter

Comment 1

18 years ago
Posted file Testcase

Updated

18 years ago
Target Milestone: --- → mozilla1.1
Reporter

Updated

17 years ago
Priority: -- → P4

Comment 2

16 years ago
retargeting
Target Milestone: mozilla1.1alpha → Future
Comment on attachment 141289 [details] [diff] [review]
Possible patch

This implements the exact "time at which the event was created." language in
the spec.  It may be more useful to use the dispatchEvent time?  Or the
initEvent time?  Or just wontfix this, since "0" is perfectly valid per the
spec?
Attachment #141289 - Flags: superreview?(jst)
Attachment #141289 - Flags: review?(jst)
Comment on attachment 141289 [details] [diff] [review]
Possible patch

This'll only initialize an event when it's created from script, right? In other
cases, we kinda don't care about the time stamp (except in the cases where it's
already initialized).
Attachment #141289 - Flags: superreview?(jst)
Attachment #141289 - Flags: superreview+
Attachment #141289 - Flags: review?(jst)
Attachment #141289 - Flags: review+
As far as I can tell, this is indeed only for cases when it's created from
script -- all other times have an nsEvent already.
Assignee: joki → bzbarsky
OS: Windows 98 → All
Priority: P4 → P3
Hardware: PC → All
Summary: timeStamp is zero for script generated events → [FIXr]timeStamp is zero for script generated events
Target Milestone: Future → mozilla1.7beta
Fix checked in for 1.7b
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

15 years ago
Blocks: 238041
document.createEvent("Events").timeStamp seems to give me random numbers that aren't comparable to a real event's timeStamp or Date.now().
Blocks: 450138
I'm pretty sure we have bugs on file on that, actually (some of the timestamps are in one unit system, while others are in another; not all of them follow the spec).
You need to log in before you can comment on or make changes to this bug.