The default bug view has changed. See this FAQ.

mozMovementX is transient and becomes zero later

RESOLVED FIXED in Firefox 14

Status

()

Core
DOM: Events
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: azakai, Assigned: humph)

Tracking

(Blocks: 1 bug)

Trunk
mozilla15
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox14+ fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 619436 [details]
testcase

mousemove events have valid mozMovementX and Y values, but if that event object is saved somewhere and processed later, the value of mozMovementX is 0. This is quite surprising and a problem for web pages that want to process the event info later.

For example, if you receive such an event and do a setTimeout whose closure captures the event, the timeout will print 0 for mozMovementX.

The attached testcase shows this, search for 'zz' to see the relevant lines. Looking in the web console it is clear mozMovementX is valid when received, but zero'd out later.
(Reporter)

Updated

5 years ago
Blocks: 710398, 633602
nsDOMUIEvent::DuplicatePrivateData() should handle also movementX/Y
tracking-firefox14: --- → ?

Comment 2

5 years ago
This is a bug in the newly implemented Mouse Lock API. Tracking for FF14.
tracking-firefox14: ? → +
(Assignee)

Comment 3

5 years ago
As an aside, this test case is triggering bug 731350 for me when I go fullscreen.
Assignee: nobody → david.humphrey
Status: NEW → ASSIGNED
tracking-firefox14: + → ?
(Assignee)

Comment 4

5 years ago
Created attachment 620296 [details] [diff] [review]
Patch v1
Attachment #620296 - Flags: review?(bugs)
Attachment #620296 - Flags: review?(bugs) → review+
seems like there's a rash of tracking flags being reset going around.  fixing. we're tracking this for 14.
tracking-firefox14: ? → +
(Assignee)

Comment 6

5 years ago
Created attachment 622237 [details] [diff] [review]
Patch v2 (r=smaug)

I wanted to run this through try server before updating, but now that I've done that, this looks good.

https://tbpl.mozilla.org/?tree=Try&rev=6d128e6de11b
Attachment #620296 - Attachment is obsolete: true
Attachment #622237 - Flags: review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
Version: unspecified → Trunk
https://hg.mozilla.org/integration/mozilla-inbound/rev/4d1a47d43ce5

Should this have an automated test?
Flags: in-testsuite?
Keywords: checkin-needed
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/4d1a47d43ce5
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
status-firefox14: --- → affected
Please nominate for Aurora approval so we can uplift.
Comment on attachment 622237 [details] [diff] [review]
Patch v2 (r=smaug)

[Approval Request Comment]
Bug caused by (feature/regressing bug #): NA
User impact if declined: buggy behavior in certain cases
Testing completed (on m-c, etc.): in m-c about a month
Risk to taking this patch (and alternatives if risky): very low risk 
String or UUID changes made by this patch: NA
Attachment #622237 - Flags: approval-mozilla-beta?
Comment on attachment 622237 [details] [diff] [review]
Patch v2 (r=smaug)

[Triage Comment]
Low risk fix for new feature. Approved for Beta 14.
Attachment #622237 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
https://hg.mozilla.org/releases/mozilla-beta/rev/d54548c3b081
status-firefox14: affected → fixed
You need to log in before you can comment on or make changes to this bug.