The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in Firefox 16

Status

()

Core
Event Handling
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: smaug, Assigned: wesj)

Tracking

({csectype-wildptr, regression, sec-moderate})

unspecified
mozilla17
x86
Linux
csectype-wildptr, regression, sec-moderate
Points:
---

Firefox Tracking Flags

(firefox15 unaffected, firefox16+ fixed, firefox17 fixed, firefox-esr10 unaffected)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
This is a recent regression from the bug where we started to call ::HandleRelease with
non-nsMouseEvents
(Reporter)

Updated

5 years ago
Blocks: 732052
(Assignee)

Comment 1

5 years ago
Created attachment 647586 [details] [diff] [review]
Patch

::HandlePress just bails for touch events. I guess handleRelease should as well?
Attachment #647586 - Flags: review?(bugs)
(Reporter)

Comment 2

5 years ago
Comment on attachment 647586 [details] [diff] [review]
Patch

Perhaps
if (aEvent->eventStructType != NS_MOUSE_EVENT) {
  return NS_OK;
}
Attachment #647586 - Flags: review?(bugs) → review+
(Assignee)

Comment 3

5 years ago
Updated patch and pushed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/be1b9c66071a
(Assignee)

Comment 4

5 years ago
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.
Attachment #647586 - Flags: approval-mozilla-aurora?
(Assignee)

Comment 5

5 years ago
http://hg.mozilla.org/mozilla-central/rev/be1b9c66071a
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Updated

5 years ago
status-firefox15: --- → unaffected
status-firefox16: --- → affected
status-firefox17: --- → fixed
tracking-firefox16: --- → ?
Comment on attachment 647586 [details] [diff] [review]
Patch

Low risk, approving for Aurora.
Attachment #647586 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
tracking-firefox16: ? → +
(Assignee)

Comment 7

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/747b9e6ee86a
status-firefox-esr10: --- → unaffected
status-firefox16: affected → fixed
Keywords: regression
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.
Group: core-security
Keywords: csec-wildptr, sec-moderate
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.