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.

nsDOMUIEvent::DuplicatePrivateData() should handle also movementX/Y

This is a bug in the newly implemented Mouse Lock API. Tracking for FF14.

As an aside, this test case is triggering bug 731350 for me when I go fullscreen.

seems like there's a rash of tracking flags being reset going around. fixing. we're tracking this for 14.

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/4d1a47d43ce5 Should this have an automated test?

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

Comment on attachment 622237 [details] [diff] [review] Patch v2 (r=smaug) [Triage Comment] Low risk fix for new feature. Approved for Beta 14.