158629 - crash removing java <applet> using dom 2

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Jesse Ruderman]

Removing a java <applet> tag using applet.parentNode.removeChild(applet) crashes
Mozilla.  Java doesn't seem to notice the crash and continues drawing/animating
until I dismiss Microsoft's crash-report dialog.  Works fine with Flash, which
uses the <object> tag.  I don't know whether it's the tag or plug-in that matters.

2002 071914, WinXP, Java Plug-in 1.4.0_01, TB8544870H.

Comment 1

[Jesse Ruderman]

I ran into this bug while writing the "zap embeds" bookmarklet for
http://www.squarefree.com/bookmarklets/zap.html.

Testcase:
http://www.cs.hmc.edu/~jruderma/spampede/bug158629.html

Comment 2

[Peter Lubczynski]

stack from TB:
js_GetProperty [c:/builds/seamonkey/mozilla/js/src/jsobj.c, line 2520]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2576]
js_Execute [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 970]
JS_EvaluateUCScriptForPrincipals [c:/builds/seamonkey/mozilla/js/src/jsapi.c,
line 3381]
nsJSContext::EvaluateString
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 703]
nsJSThunk::EvaluateScript
[c:/builds/seamonkey/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp, line 285]
nsJSChannel::AsyncOpen
[c:/builds/seamonkey/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp, line 622]
nsDocumentOpenInfo::Open
[c:/builds/seamonkey/mozilla/uriloader/base/nsURILoader.cpp, line 175]
nsURILoader::OpenURIVia
[c:/builds/seamonkey/mozilla/uriloader/base/nsURILoader.cpp, line 539]
nsURILoader::OpenURI
[c:/builds/seamonkey/mozilla/uriloader/base/nsURILoader.cpp, line 500]
nsDocShell::DoChannelLoad
[c:/builds/seamonkey/mozilla/docshell/base/nsDocShell.cpp, line 5355]
nsDocShell::DoURILoad [c:/builds/seamonkey/mozilla/docshell/base/nsDocShell.cpp,
line 5134]
nsDocShell::InternalLoad
[c:/builds/seamonkey/mozilla/docshell/base/nsDocShell.cpp, line 4923]
nsDocShell::LoadURI [c:/builds/seamonkey/mozilla/docshell/base/nsDocShell.cpp,
line 681]
nsDocShell::LoadURI [c:/builds/seamonkey/mozilla/docshell/base/nsDocShell.cpp,
line 2381]
XPTC_InvokeByIndex
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 1996]
XPC_WN_CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1267]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 790]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2744]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 806]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2744]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 806]
fun_apply [c:/builds/seamonkey/mozilla/js/src/jsfun.c, line 1555]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 790]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2744]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 806]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 881]
JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3430]
nsJSContext::CallEventHandler
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1045]
nsJSEventListener::HandleEvent
[c:/builds/seamonkey/mozilla/dom/src/events/nsJSEventListener.cpp, line 184]
nsXBLPrototypeHandler::ExecuteHandler
[c:/builds/seamonkey/mozilla/content/xbl/src/nsXBLPrototypeHandler.cpp, line 457]
DoKey [c:/builds/seamonkey/mozilla/content/xbl/src/nsXBLKeyHandler.cpp, line 108]
nsXBLKeyHandler::KeyPress
[c:/builds/seamonkey/mozilla/content/xbl/src/nsXBLKeyHandler.cpp, line 124]
nsEventListenerManager::HandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line
1665]
nsXULElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3454]
nsXULElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3435]
nsXULElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp, line 3435]
nsGenericElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 1798]
nsHTMLInputElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1407]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6192]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6115]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2059]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 306]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 1916]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 83]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1038]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1055]
nsWindow::DispatchKeyEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 2876]
nsWindow::OnChar [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp,
line 3046]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 3692]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1304]
USER32.dll + 0x3a5f (0x77d43a5f)
USER32.dll + 0x3b2e (0x77d43b2e)
USER32.dll + 0x3d6a (0x77d43d6a)
USER32.dll + 0x41fd (0x77d441fd)
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 452]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1527]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1874]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1892]
WinMainCRTStartup()

Comment 3

[rubydoo123]

I meant to put this into peterl's queue. Peter: why would removing the applet
ref cause the crash?

Comment 4

[Peter Lubczynski]

This may be caused because of the fact plugins are tied to frames rather than
content but I meed to take a look at when nsObjectFrame::Destory happens in the
stack below.

Comment 5

[Peter Lubczynski]

--->reassing to anthonyd
This is likley either a dup or another incarnation of the FSCommand bug 169951
or the reframe bug 90268.

btw, *nice* testcase!

Comment 6

[anthonyd]

just re-tested this and it is no longer crashing.  WFM.

Comment 7

[shrirang khanzode]

yep,verified with tony.

Comment 8

[Peter Weilbacher]

I have only now found this bug and tried the testcase from #1 with Mozilla
1.2beta and the current Java Plug-in 1.4.1_01-b01 on Linux. And here, it does
not crash the browser but hangs it so that I had to kill it from the shell. Are
you sure this is fixed??