Midas crashes [@ GetNearestCapturingView] when iframe style is changed during editing

RESOLVED FIXED

Status

()

Core
Event Handling
--
critical
RESOLVED FIXED
10 years ago
6 years ago

People

(Reporter: tgirmann, Assigned: smaug)

Tracking

({crash, testcase, verified1.8.1.13})

1.8 Branch
crash, testcase, verified1.8.1.13
Points:
---
Bug Flags:
blocking1.8.1.13 +
wanted1.8.1.x +
blocking1.8.0.next +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical?] 1.8 branch, crash signature)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10

An iframe's document has an event handler attached that changes the iframe's position style to "relative" when the user tries to select some text with the mouse. When Midas (designMode="on") is enabled on that iframe the browser crashes.

Reproducible: Always

Steps to Reproduce:
Select some text.
Actual Results:  
Firefox crashes.

Expected Results:  
Firefox shouldn't crash.

On bug 373344 I was told the following after posting the test case (because I thought it belongs there due to its similarity):

"Doesn't seem to crash on trunk and on branch the stack trace looks quite
different to this bug.
But the trace does look familiar. Could you perhaps file a new (security
sensitive) bug and attach the testcase there."
(Reporter)

Comment 1

10 years ago
Created attachment 290525 [details]
Test case
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
I get this stacktrace in a debug build:
#0  0x05a73b37 in GetNearestCapturingView (aFrame=0x1037295c)
    at c:/mozilla181/mozilla/layout/generic/nsFrame.cpp:1713
#1  0x05a73e9d in nsFrame::HandleDrag (this=0x1037295c,
    aPresContext=0x1010ed70, aEvent=0x22f504, aEventStatus=0x22f24c)
    at c:/mozilla181/mozilla/layout/generic/nsFrame.cpp:1769
#2  0x05a71d0b in nsFrame::HandleEvent (this=0x1037295c,
    aPresContext=0x1010ed70, aEvent=0x22f504, aEventStatus=0x22f24c)
    at c:/mozilla181/mozilla/layout/generic/nsFrame.cpp:985
#3  0x05a42596 in PresShell::HandleEventInternal (this=0x4da2a48,
    aEvent=0x22f504, aView=0x101773c0, aFlags=1, aStatus=0x22f24c)
    at c:/mozilla181/mozilla/layout/base/nsPresShell.cpp:6472
#4  0x05a41d3c in PresShell::HandleEvent (this=0x4da2a48, aView=0x101773c0,
    aEvent=0x22f504, aEventStatus=0x22f24c, aForceHandle=1,
    aHandled=@0x22f1dc)
    at c:/mozilla181/mozilla/layout/base/nsPresShell.cpp:6267
#5  0x05d96ec8 in nsViewManager::HandleEvent (this=0x1fe9048,
    aView=0x101773c0, aEvent=0x22f504, aCaptured=1)
    at c:/mozilla181/mozilla/view/src/nsViewManager.cpp:2564
#6  0x05d9630c in nsViewManager::DispatchEvent (this=0x1fe9048,
    aEvent=0x22f504, aStatus=0x22f358)
    at c:/mozilla181/mozilla/view/src/nsViewManager.cpp:2253
#7  0x05d8babf in HandleEvent (aEvent=0x22f504)
    at c:/mozilla181/mozilla/view/src/nsView.cpp:171
#8  0x6434403b in nsWindow::DispatchEvent (this=0x101fb818, event=0x22f504,
---Type <return> to continue, or q <return> to quit---
    aStatus=@0x22f458)
    at c:/mozilla181/mozilla/widget/src/windows/nsWindow.cpp:1319
#9  0x643440f5 in nsWindow::DispatchWindowEvent (this=0x101fb818,
    event=0x22f504)
    at c:/mozilla181/mozilla/widget/src/windows/nsWindow.cpp:1339
#10 0x6434e883 in nsWindow::DispatchMouseEvent (this=0x101fb818,
    aEventType=300, wParam=1, aPoint=0x0)
    at c:/mozilla181/mozilla/widget/src/windows/nsWindow.cpp:6323
#11 0x6434ef01 in ChildWindow::DispatchMouseEvent (this=0x101fb818,
    aEventType=300, wParam=1, aPoint=0x0)
    at c:/mozilla181/mozilla/widget/src/windows/nsWindow.cpp:6572
#12 0x6434bb0c in nsWindow::ProcessMessage (this=0x101fb818, msg=512,
    wParam=1, lParam=983054, aRetValue=0x22f95c)
    at c:/mozilla181/mozilla/widget/src/windows/nsWindow.cpp:4829
#13 0x643446a1 in nsWindow::WindowProc (hWnd=0x230800, msg=512, wParam=1,
    lParam=983054)
    at c:/mozilla181/mozilla/widget/src/windows/nsWindow.cpp:1507
#14 0x7e398734 in USER32!GetDC ()
#15 0x00230800 in ?? ()
(gdb)
Status: UNCONFIRMED → NEW
Component: Editor → Error Console
Ever confirmed: true
Keywords: crash, testcase
QA Contact: editor → error-console
Summary: Midas crashes when iframe style is changed during editing → Midas crashes [@ GetNearestCapturingView] when iframe style is changed during editing

Updated

10 years ago
Component: Error Console → Event Handling
QA Contact: error-console → events
I get a fix range on trunk between 2006-09-16 and 2006-09-20:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-09-16+04&maxdate=2006-09-20+09&cvsroot=%2Fcvsroot
Maybe fixed by bug 349931?

Comment 4

10 years ago
Using a branch debug build on Mac, I get:

* ###!!! ASSERTION: Must have view manager: '!isSafeToFlush || mViewManager', file /Users/jruderman/branch/mozilla/layout/base/nsPresShell.cpp, line 5432

* ###!!! ASSERTION: index out of range: '0 <= aIndex && aIndex < Count()', file ../../dist/include/xpcom/nsVoidArray.h, line 71

* Crash [@ GetNearestCapturingView] dereferencing 0x000000fc.

Line 71 is in nsVoidArray::FastElementAt (in contrast to ElementAt/SafeElementAt) so this could easily be bad.
Flags: blocking1.8.1.12?
OS: Windows XP → All
Hardware: PC → All
Whiteboard: 1.8 branch
-> Smaug since he wrote the likely trunk-fixing patch (bug 349931). Given other 1.8.1.12 blockers this isn't likely to be done in time for the release.
Assignee: nobody → Olli.Pettay
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.13?
Flags: blocking1.8.1.12?
Whiteboard: 1.8 branch → 1.8 branch.
Version: unspecified → 1.8 Branch
Whiteboard: 1.8 branch. → [sg:?][needs patch] 1.8 branch
On a windows debug branch build I get shut down with a DEP exception (thus likely exploitable since DEP is not supported in branch release builds) with the following stack:

> 	fdfdfdfd	
	nsDocument::QueryInterface() Line 984	C++
 	nsHTMLDocument::QueryInterface() Line 313	C++
 	nsWeakReference::QueryReferent() Line 115	C++
 	nsQueryReferent::operator()() Line 52	C++
 	nsCOMPtr<nsIDOMDocument>::assign_from_helper() Line 1292	C++
 	nsCOMPtr<nsIDOMDocument>::nsCOMPtr<nsIDOMDocument>() Line 695	C++
 	nsEditor::GetDocument() Line 612	C++
 	mozInlineSpellWordUtil::Init() Line 97	C++
 	mozInlineSpellChecker::ResumeCheck() Line 1457	C++
 	HandleSpellCheckResumePLEvent() Line 496	C++
 	PL_HandleEvent() Line 688	C
 	PL_ProcessPendingEvents() Line 623	C
Whiteboard: [sg:?][needs patch] 1.8 branch → [sg:critical?][needs patch] 1.8 branch
Flags: blocking1.8.1.13? → blocking1.8.1.13+
(Assignee)

Comment 7

10 years ago
Created attachment 306512 [details] [diff] [review]
possible patch

Can't reproduce this on linux. The patch is basically the same as for bug 349931.
Someone should test whether the patch fixes this. (It should, I think, at least if the stack trace on this bug is right.)
This patch seems to fix the problem on branch. Immediately after loading the first attempt to select something fails (The console says "GetPrimaryFrameFor() called while nsFrameManager is being destroyed!" twice), but doesn't crash and selecting works fine after that.
(Assignee)

Updated

10 years ago
Attachment #306512 - Flags: superreview?(roc)
Attachment #306512 - Flags: review?(roc)
Attachment #306512 - Flags: approval1.8.1.13?
(Assignee)

Comment 9

10 years ago
Comment on attachment 306512 [details] [diff] [review]
possible patch

>   frameselection->StopAutoScrollTimer();
>+  // If we have capturing view, it must be ensured that |this| doesn't 
>+  // get deleted during HandleDrag.
>+  nsWeakFrame weakFrame = GetNearestCapturingView(this) ? this : nsnull;

and for reviewer, frameselection is a strong ref here.
Attachment #306512 - Flags: superreview?(roc)
Attachment #306512 - Flags: superreview+
Attachment #306512 - Flags: review?(roc)
Attachment #306512 - Flags: review+
Whiteboard: [sg:critical?][needs patch] 1.8 branch → [sg:critical?] 1.8 branch
Comment on attachment 306512 [details] [diff] [review]
possible patch

approved for 1.8.1.13, a=dveditz for release-drivers
Attachment #306512 - Flags: approval1.8.1.13? → approval1.8.1.13+
(Assignee)

Updated

10 years ago
Keywords: fixed1.8.1.13
I can reproduce the crash in Firefox 2.0.0.12 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/2008020121 Firefox/2.0.0.12), using the testcase in comment 1 but NOT in:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/2008031114 Firefox/2.0.0.13

Replacing fixed1.8.1.13 keyword with verified1.8.1.13
Keywords: fixed1.8.1.13 → verified1.8.1.13

Updated

10 years ago
Flags: blocking1.8.0.15+

Comment 12

10 years ago
Comment on attachment 306512 [details] [diff] [review]
possible patch

applies cleanly on 1.8.0
Attachment #306512 - Flags: approval1.8.0.15?
Group: security
Flags: in-testsuite?
-> FIXED in 1.8.1.13, branch-only bug.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Crash Signature: [@ GetNearestCapturingView]
You need to log in before you can comment on or make changes to this bug.