367123 - [1.8 branch] Testcase from bug 337716 is still crashing [@ nsGlobalWindow::HandleDOMEvent] with slightly different steps to reproduce

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Martijn Wargers (dead)]

Bug 337716 is fixed, but when clicking on the 'back' button, when trying to escape the alert boxes that the testcase generates, Firefox can crash on the latest 1.8. branch build.
I wasn't able to reproduce this on trunk, nor on the the 1.8.0.x branch. Alice mentioned that se got a hang on the 1.8.0.x branch.

From bug 337716, comment 12:
"
Reproduced the crash on mac for 2.0.0.2pre.  It was triggered after alternating
clicking on the 'okay' button on the alert and the 'back' arrow on the browser
- it was the combination of these two actions that caused the crash.
"

Talkback ID from the 1.8.1 branch build: TB28292905Y
0x00000000
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1714]
DocumentViewerImpl::PermitUnload  [mozilla/layout/base/nsDocumentViewer.cpp, line 1111]
DocumentViewerImpl::PermitUnload  [mozilla/layout/base/nsDocumentViewer.cpp, line 1169]
nsDocShell::InternalLoad  [mozilla/docshell/base/nsDocShell.cpp, line 6596]
nsDocShell::LoadHistoryEntry  [mozilla/docshell/base/nsDocShell.cpp, line 7756]
nsDocShell::LoadURI  [mozilla/docshell/base/nsDocShell.cpp, line 773]
nsSHistory::InitiateLoad  [mozilla/xpfe/components/shistory/src/nsSHistory.cpp, line 1216]
nsSHistory::LoadEntry  [mozilla/xpfe/components/shistory/src/nsSHistory.cpp, line 1132]
nsSHistory::GoBack  [mozilla/xpfe/components/shistory/src/nsSHistory.cpp, line 703]
nsDocShell::GoBack  [mozilla/docshell/base/nsDocShell.cpp, line 2804]
XPTC_InvokeByIndex  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1396]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3961]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1415]
js_InternalInvoke  [mozilla/js/src/jsinterp.c, line 1490]
JS_CallFunctionValue  [mozilla/js/src/jsapi.c, line 4356]
nsJSContext::CallEventHandler  [mozilla/dom/src/base/nsJSEnvironment.cpp, line 1493]
nsJSEventListener::HandleEvent  [mozilla/dom/src/events/nsJSEventListener.cpp, line 195]
nsEventListenerManager::HandleEventSubType  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2230]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2251]
PresShell::HandleDOMEventWithTarget  [mozilla/layout/base/nsPresShell.cpp, line 6524]
nsButtonBoxFrame::DoMouseClick  [mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp, line 182]
nsButtonBoxFrame::MouseClicked  [mozilla/layout/xul/base/src/nsButtonBoxFrame.h, line 61]
PresShell::HandleEventInternal  [mozilla/layout/base/nsPresShell.cpp, line 6466]
PresShell::HandleEventWithTarget  [mozilla/layout/base/nsPresShell.cpp, line 6323]
nsEventStateManager::CheckForAndDispatchClick  [mozilla/content/events/src/nsEventStateManager.cpp, line 3207]
nsEventStateManager::PostHandleEvent  [mozilla/content/events/src/nsEventStateManager.cpp, line 2170]
PresShell::HandleEventInternal  [mozilla/layout/base/nsPresShell.cpp, line 6497]
PresShell::HandleEvent  [mozilla/layout/base/nsPresShell.cpp, line 6261]
nsViewManager::HandleEvent  [mozilla/view/src/nsViewManager.cpp, line 2559]
nsViewManager::DispatchEvent  [mozilla/view/src/nsViewManager.cpp, line 2246]
HandleEvent  [mozilla/view/src/nsView.cpp, line 174]
nsWindow::DispatchEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 1389]
nsWindow::DispatchMouseEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 6435]
ChildWindow::DispatchMouseEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 6682]
nsWindow::WindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1577]
USER32.dll + 0x8709 (0x77d18709)
USER32.dll + 0x87eb (0x77d187eb)
USER32.dll + 0x89a5 (0x77d189a5)
USER32.dll + 0x89e8 (0x77d189e8)
nsAppShell::DispatchNativeEvent  [mozilla/widget/src/windows/nsAppShell.cpp, line 221]
nsContentTreeOwner::ShowAsModal  [mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp, line 478]
nsWindowWatcher::OpenWindow  [mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 479]
nsPromptService::DoDialog  [mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp, line 661]
nsPromptService::Alert  [mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp, line 134]
nsPrompt::Alert  [mozilla/embedding/components/windowwatcher/src/nsPrompt.cpp, line 230]
nsGlobalWindow::Alert  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 3386]
XPTC_InvokeByIndex  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1396]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3961]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1415]
nsXPCWrappedJSClass::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1415]
nsXPCWrappedJS::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1686]

Comment 1

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

Can't reproduce on 1.8/trunk/Linux. 

Comment 2

[Daniel Veditz [:dveditz]]

It was hard to reproduce, but finally got it on a debug windows 2.0.0.4pre build more-or-less following the instructions in the initial comment (alternately clicking back/forward buttons and hitting Enter to OK the alert).

Triggered a DEP exception, same stack as comment #0 except the top address is 0xe9000366 instead of 0x0. The DocumentViewerImpl looks mostly OK at a glance except mParentWidget is pointing at a deleted object and mDocument is null. But since it got the (bogus) global window from mDocument why didn't it crash with a null deref on the call to GetScriptGlobalObject before getting this far?

Could web content actually exploit this? It's not likely you'd get a potential victim to go clicking around as long as I had to, but could there be a similar sequence of synthetic events?

Comment 3

[Martijn Wargers (dead)]

Marking resolved worksforme, as this is only a problem in the 1.8 branch and not in later builds and the 1.8 branch is not maintained anymore by Mozilla.