crash when using mozilla after destroying alert dialog

RESOLVED WORKSFORME

Status

()

Core
XUL
--
critical
RESOLVED WORKSFORME
17 years ago
13 years ago

People

(Reporter: eli_v, Assigned: jag (Peter Annema))

Tracking

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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

17 years ago
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

17 years ago
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 eli_v@pandora.be
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) 
Assignee: asa → hyatt
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Toolkit/Widgets
Ever confirmed: true
QA Contact: doronr → jrgm

Comment 3

17 years ago
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.
Summary: crash when using mozilla after destroying error window → crash when using mozilla after destroying alert dialog

Comment 4

17 years ago
Created attachment 51392 [details]
testcase; right click on 'X', then right click in content area (on Linux)

Comment 5

17 years ago
--> jag
Assignee: hyatt → jaggernaut
(Assignee)

Comment 6

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

Comment 7

17 years ago
Yes I still crash with the testcase in today's trunk linux build.
(Assignee)

Comment 8

17 years ago
danm, do you have an idea of what might be going on here?
(Assignee)

Comment 9

17 years ago
-> future
Target Milestone: --- → Future
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.
WFM, 2005-08-31-02 SeaMonkey Linux

-> WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.