98495 - crash when using mozilla after destroying alert dialog

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[eli_v]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
BuildID:    2001080104

See also bug #98493

when I destroy an error window about a layer error, mozilla crashes.

Reproducible: Always
Steps to Reproduce:
1. open http://www.eureco.be/
2. click on '@Home'
3. an error window pops up
4. destroy the error window (in enlightenment: right click the close icon, other
window managers: ??)
5. continue using mozilla until it crashes

TalkBack ID : TB35015575E

See also bug #98493

Comment 1

[Grégoire Colbert]

I tried to reproduce this bug with 20010906 build in Linux.
I had several error windows on the page, but no crash afterwards.
Could you try again with a recent build?

Comment 2

[Asa Dotzler [:asa]]

Incident ID 35015575
Stack Signature libgtk-1.2.so.0 + 0xe805d (0x402db05d) 29b59200
Bug ID
Trigger Time 2001-09-06 04:12:57
Email Address [e-mail]
User Comments * open the url * click '@Home' * destroy error window * continu
using mozilla until crash
Build ID 2001080104
Product ID MozillaTrunk
Platform ID LinuxIntel
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
Stack Trace
libgtk-1.2.so.0 + 0xe805d (0x402db05d)
nsWindow::GetTopLevelWindow()
ModalWidgetList::Suppress()
nsWidget::SuppressModality()
nsWindow::CaptureRollupEvents()
nsMenuDismissalListener::SetCurrentMenuParent()
nsMenuFrame::UpdateDismissalListener()
nsMenuFrame::OpenMenuInternal()
nsMenuFrame::AttributeChanged()
nsCSSFrameConstructor::AttributeChanged()
StyleSetImpl::AttributeChanged()
PresShell::AttributeChanged()
nsXULDocument::AttributeChanged()
nsXULElement::SetAttribute()
nsXULElement::SetAttribute()
nsMenuFrame::OpenMenu()
nsMenuFrame::ToggleMenuState()
nsMenuFrame::HandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsView::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::DispatchMouseEvent()
nsWidget::OnButtonPressSignal()
nsWindow::HandleGDKEvent()
dispatch_superwin_event()
handle_gdk_event()
libgdk-1.2.so.0 + 0x16d32 (0x40320d32)
libglib-1.2.so.0 + 0xf7b6 (0x4034d7b6)
libglib-1.2.so.0 + 0xfd71 (0x4034dd71)
libglib-1.2.so.0 + 0xfe13 (0x4034de13)
nsAppShell::DispatchNativeEvent()
nsXULWindow::ShowModal()
nsWebShellWindow::ShowModal()
nsContentTreeOwner::ShowAsModal()
nsWindowWatcher::OpenWindowJS()
nsWindowWatcher::OpenWindow()
nsPromptService::DoDialog()
nsPromptService::Alert()
nsPrompt::Alert()
GlobalWindowImpl::Alert()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_Interpret()
js_Invoke()
js_Interpret()
js_Execute()
JS_EvaluateUCScriptForPrincipals()
nsJSContext::EvaluateString()
nsScriptLoader::EvaluateScript()
nsScriptLoader::ProcessRequest()
nsScriptLoader::OnStreamComplete()
nsStreamLoader::OnStopRequest()
nsHttpChannel::OnStopRequest()
nsOnStopRequestEvent::HandleEvent()
nsARequestObserverEvent::HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xe27a (0x4034c27a)
libglib-1.2.so.0 + 0xf7b6 (0x4034d7b6)
libglib-1.2.so.0 + 0xfd71 (0x4034dd71)
libglib-1.2.so.0 + 0xfee9 (0x4034dee9)
libgtk-1.2.so.0 + 0x87cea (0x4027acea)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1c4b7 (0x404854b7) 

Comment 3

[John Morrison]

Ignoring the reported URL (since all those error messages are just simple JS 
alerts anyways), this boils down to a simple test case:

<script>
window.onload = function () { alert('foo'); };
</script>

and when the alert comes up, right click on the X control (or select anhillate
from the context menu for the dialog window). Then right click in the browser 
content area. Boom.

It doesn't seem like a particularly mainstream user action, but perhaps we're 
just not properly cleaning up when the dialog is annhilated, as opposed to 
closed normally.

Comment 4

[John Morrison]

Attachment: testcase; right click on 'X', then right click in content area (on Linux)

Comment 5

[David Hyatt]

--> jag

Comment 6

[jag (Peter Annema)]

John, do you still go boom with this testcase? I can't reproduce it here.

Comment 7

[John Morrison]

Yes I still crash with the testcase in today's trunk linux build.

Comment 8

[jag (Peter Annema)]

danm, do you have an idea of what might be going on here?

Comment 9

[jag (Peter Annema)]

-> future

Comment 10

[Henrik Lynggaard Hansen]

This bug has not been touched for nearly 2 years. In most cases, that 
means it has "slipped through the net".
Could someone please take a moment to add a comment to the bug with current
status, and/or close it.

btw: I cannot reproduce this bug using mozilla 1.6.

Comment 11

[Mats Palmgren (inactive)]

WFM, 2005-08-31-02 SeaMonkey Linux

-> WORKSFORME