Last Comment Bug 750111 - mozMovementX is transient and becomes zero later
: mozMovementX is transient and becomes zero later
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla15
Assigned To: David Humphrey (:humph)
: Andrew Overholt [:overholt]
Depends on:
Blocks: gecko-games 633602
  Show dependency treegraph
Reported: 2012-04-29 12:47 PDT by Alon Zakai (:azakai)
Modified: 2012-06-16 14:12 PDT (History)
7 users (show)
ryanvm: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (86.77 KB, text/html)
2012-04-29 12:47 PDT, Alon Zakai (:azakai)
no flags Details
Patch v1 (3.19 KB, patch)
2012-05-02 06:45 PDT, David Humphrey (:humph)
bugs: review+
Details | Diff | Splinter Review
Patch v2 (r=smaug) (3.32 KB, patch)
2012-05-08 17:51 PDT, David Humphrey (:humph)
david.humphrey: review+
akeybl: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description User image Alon Zakai (:azakai) 2012-04-29 12:47:59 PDT
Created attachment 619436 [details]

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.
Comment 1 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2012-04-29 13:13:01 PDT
nsDOMUIEvent::DuplicatePrivateData() should handle also movementX/Y
Comment 2 User image Alex Keybl [:akeybl] 2012-04-30 16:31:52 PDT
This is a bug in the newly implemented Mouse Lock API. Tracking for FF14.
Comment 3 User image David Humphrey (:humph) 2012-05-02 06:41:19 PDT
As an aside, this test case is triggering bug 731350 for me when I go fullscreen.
Comment 4 User image David Humphrey (:humph) 2012-05-02 06:45:41 PDT
Created attachment 620296 [details] [diff] [review]
Patch v1
Comment 5 User image Lukas Blakk [:lsblakk] use ?needinfo 2012-05-03 12:07:56 PDT
seems like there's a rash of tracking flags being reset going around.  fixing. we're tracking this for 14.
Comment 6 User image David Humphrey (:humph) 2012-05-08 17:51:01 PDT
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.
Comment 7 User image Ryan VanderMeulen [:RyanVM] 2012-05-09 16:03:24 PDT

Should this have an automated test?
Comment 8 User image Ed Morley [:emorley] 2012-05-10 08:01:19 PDT
Comment 9 User image Lukas Blakk [:lsblakk] use ?needinfo 2012-05-23 16:37:19 PDT
Please nominate for Aurora approval so we can uplift.
Comment 10 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2012-06-14 10:20:02 PDT
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
Comment 11 User image Alex Keybl [:akeybl] 2012-06-15 15:24:11 PDT
Comment on attachment 622237 [details] [diff] [review]
Patch v2 (r=smaug)

[Triage Comment]
Low risk fix for new feature. Approved for Beta 14.
Comment 12 User image Olli Pettay [:smaug] (pto-ish for couple of days) 2012-06-16 14:12:58 PDT

Note You need to log in before you can comment on or make changes to this bug.