779078 - nsFrame::HandleRelease may cast aEvent to nsMouseEvent even if aEvent is a TouchEvent

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

This is a recent regression from the bug where we started to call ::HandleRelease with
non-nsMouseEvents

Comment 1

[Wesley Johnston (:wesj)]

Attachment: Patch

::HandlePress just bails for touch events. I guess handleRelease should as well?

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 647586 [details] [diff] [review]
Patch

Perhaps
if (aEvent->eventStructType != NS_MOUSE_EVENT) {
  return NS_OK;
}

Comment 3

[Wesley Johnston (:wesj)]

Updated patch and pushed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/be1b9c66071a

Comment 4

[Wesley Johnston (:wesj)]

Comment on attachment 647586 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 732052
User impact if declined: bad behavior with setCapture and touch events. bug 774190.
Testing completed (on m-c, etc.): landed on inbound today 7/31/13
Risk to taking this patch (and alternatives if risky): low risk. This is reverting us back to old behavior.
String or UUID changes made by this patch: none.

Comment 5

[Wesley Johnston (:wesj)]

http://hg.mozilla.org/mozilla-central/rev/be1b9c66071a

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 647586 [details] [diff] [review]
Patch

Low risk, approving for Aurora.

Comment 7

[Wesley Johnston (:wesj)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/747b9e6ee86a

Comment 8

[Daniel Veditz [:dveditz]]

Possibly exploitable because there are virtual methods and data members all in different locations in the two kinds of events, although there's not a lot of precision you could elicit out of a victim on a touch event.