Closed
Bug 336587
Opened 20 years ago
Closed 20 years ago
Crash when window gets destroyed during DOMMouseScroll event
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: martijn.martijn, Assigned: smaug)
Details
(4 keywords)
Attachments
(4 files)
|
787 bytes,
text/html
|
Details | |
|
1.37 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
bzbarsky
:
approval-branch-1.8.1+
dveditz
:
approval1.8.0.5-
|
Details | Diff | Splinter Review |
|
1.42 KB,
patch
|
dveditz
:
approval1.8.0.5+
|
Details | Diff | Splinter Review |
|
1.42 KB,
patch
|
Details | Diff | Splinter Review |
See upcoming testcase, which crashes Mozilla builds when using the mousewheel over the iframe.
The crash also happens in Mozilla1.7, so no recent regression.
Talkback ID: TB18285705H
nsEventStateManager::DoScrollText nsEventStateManager::PostHandleEvent g_TOKEN_Directories
0x8b57f685
| Reporter | ||
Comment 1•20 years ago
|
||
| Assignee | ||
Comment 2•20 years ago
|
||
Assignee: events → Olli.Pettay
Status: NEW → ASSIGNED
Attachment #220773 -
Flags: superreview?(bzbarsky)
Attachment #220773 -
Flags: review?(bzbarsky)
Updated•20 years ago
|
Attachment #220773 -
Flags: superreview?(bzbarsky)
Attachment #220773 -
Flags: superreview+
Attachment #220773 -
Flags: review?(bzbarsky)
Attachment #220773 -
Flags: review+
| Assignee | ||
Comment 3•20 years ago
|
||
Checking in nsEventStateManager.cpp;
/cvsroot/mozilla/content/events/src/nsEventStateManager.cpp,v <-- nsEventStateManager.cpp
new revision: 1.646; previous revision: 1.645
done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 4•20 years ago
|
||
Verified FIXED using build 2006-05-04-16 of SeaMonkey trunk on Windows XP with the testcase: https://bugzilla.mozilla.org/attachment.cgi?id=220770&action=view.
No crash when using the mouse's scrollwheel.
Status: RESOLVED → VERIFIED
| Assignee | ||
Updated•20 years ago
|
Flags: blocking1.8.1?
Flags: blocking1.8.0.5?
| Assignee | ||
Comment 5•20 years ago
|
||
Comment on attachment 220773 [details] [diff] [review]
proposed patch
Safe fix, just adding a null check.
Attachment #220773 -
Flags: approval1.8.0.5?
Attachment #220773 -
Flags: approval-branch-1.8.1?(bzbarsky)
Comment 6•20 years ago
|
||
Comment on attachment 220773 [details] [diff] [review]
proposed patch
Looks ok, but what's making sure aPresContext is alive here? Do we need to hold a local strong ref to it?
Attachment #220773 -
Flags: approval-branch-1.8.1?(bzbarsky) → approval-branch-1.8.1+
| Assignee | ||
Comment 7•20 years ago
|
||
the event object has a strong reference to the prescontext.
| Assignee | ||
Comment 8•20 years ago
|
||
| Assignee | ||
Updated•20 years ago
|
Flags: blocking1.8.1?
Keywords: fixed1.8.1
Updated•20 years ago
|
Flags: blocking1.8.0.5? → blocking1.8.0.5+
Comment 9•20 years ago
|
||
Comment on attachment 220773 [details] [diff] [review]
proposed patch
wrong patch for branch
Attachment #220773 -
Flags: approval1.8.0.5? → approval1.8.0.5-
Comment 10•20 years ago
|
||
Comment on attachment 222160 [details] [diff] [review]
1.8 version of the patch
approved for 1.8.0 branch, a=dveditz for drivers
Attachment #222160 -
Flags: approval1.8.0.5+
| Assignee | ||
Comment 11•20 years ago
|
||
| Assignee | ||
Updated•20 years ago
|
Keywords: fixed1.8.0.5
Updated•20 years ago
|
Keywords: fixed1.8.0.5 → verified1.8.0.5
Updated•7 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•