125425 - Closing tab crashes browser

Status: VERIFIED DUPLICATE of bug 116287

(SeaMonkey :: Tabbed Browser, defect)

Description

[Kenneth Herron]

Host is Red Hat 7.2, using KDE. Problem was first observed with build
20020208xx; reproduced after upgrading to 2002021308. Produced problem four
times and submitted talkback each time; sorry, don't know what the talkback
numbers would be.

Basically, it appears that opening a sports-illustrated article in a browser
tab, then closing that tab, crashes the browser.

To reproduce:

1) Go to www.cnn.com.

2) Look for a sports illustrated link.  These are generally on the right half of
the page and may be labelled "CNN/SI:". (Such articles aren't always present;
hopefully this won't be a problem during the olympics.  Problem doesn't happen
with CNN articles, only Sports Illustrated articles.)

3) Right-click on this link and open it in a new tab (I have mozilla set to open
tabs in the background).

4) Give the tab time to finish loading.  Switch to it.  Close it.

5) Browser area grays out, then mozilla crashes.

Opening a sportsillustrated page in a separate browser window, then closing that
window, works fine. Crash only occurs using tabs.

I haven't yet tested loading a sports-illustrated page other than by starting at
the CNN page. It may be possible to reproduce the crash without having to go
through cnn.com.

Sports-illustrated articles sometimes trigger a popup window (containing an ad)
when you leave the page. I'll speculate rampantly that this may be related?

Comment 1

[Kenneth Herron]

Check-tested reproduceability:

1) Loaded this bug report.
2) Right-clicked on "URL" link above (i.e. the sample URL) and opened it in a
new window.
3) Closed that window. Browser didn't crash.
4) Right-clicked on "URL" and opened it in a tab.
5) Browser crashed. Submitted another talkback.

Going through CNN should not be necessary to reproduce should not be necessary,
unless the original URL becomes invalid and you have to find a new one.

Comment 2

[Kenneth Herron]

Attachment: Partially reduced testcase

Copied the sample page to a file and reduced it quite a bit. It could probably
be reduced further; I'm just out of time at the moment.

Comment 3

[Kenneth Herron]

Verified the original crash behavior can be reproduced on the solaris 2002013122
nightly. (Solaris nightlies aren't being produced at the moment, so I can't try
something more current.)

Forget the testcase. When I saved the page, mozilla apparently fetched all the
additional files needed to render the page (GIFs, javascript, stylesheets, etc.)
and saved them locally.  The bug doesn't trigger if these files aren't present.

Comment 4

[sairuh (rarely reading bugmail)]

yeah i can repro this as well; here are my steps:

1. load this bug report page, http://bugzilla.mozilla.org/show_bug.cgi?id=125425
2. bring up context menu for the test URL,
http://sportsillustrated.cnn.com/olympics/2002/figure_skating/news/2002/02/13/isu_decision/
3. select "open in new tab"
4. after that new tab loads [btw, it's now the active tab], close it --i just
used ctrl+W.

result: crash.

will check to see when this started w/previous builds. in the meantime here's
the talkback trace:

0x53e58955
libgdk-1.2.so.0 + 0x29f09 (0x40371f09)
nsDeviceContextGTK::GetRect()
nsDeviceContextGTK::GetClientRect()
ScreenImpl::GetAvailWidth()
nsWindowWatcher::SizeOpenedDocShellItem()
nsWindowWatcher::OpenWindowJS()
nsWindowWatcher::OpenWindow()
GlobalWindowImpl::OpenInternal()
GlobalWindowImpl::Open()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
GlobalWindowImpl::HandleDOMEvent()
DocumentViewerImpl::Unload()
nsDocShell::FireUnloadNotification()
nsDocShell::Destroy()
nsWebShell::Destroy()
nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame()
nsFrame::Destroy()
nsFrameList::DestroyFrames()
nsContainerFrame::Destroy()
nsFrameList::DestroyFrame()
nsBoxFrame::RemoveFrame()
FrameManager::RemoveFrame()
nsCSSFrameConstructor::ContentRemoved()
StyleSetImpl::ContentRemoved()
PresShell::ContentRemoved()
nsXULDocument::ContentRemoved()
nsXULElement::RemoveChildAt()
nsXULElement::RemoveChild()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsXBLPrototypeHandler::ExecuteHandler()
nsXBLWindowHandler::WalkHandlersInternal()
nsXBLWindowKeyHandler::WalkHandlers()
nsXBLWindowKeyHandler::KeyPress()
nsEventListenerManager::HandleEvent()
nsXULDocument::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleChromeEvent()
GlobalWindowImpl::HandleDOMEvent()
nsDocument::HandleDOMEvent()
nsGenericElement::HandleDOMEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsViewManager::HandleEvent()
nsView::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::OnInput()
handle_key_press_event()
dispatch_superwin_event()
handle_gdk_event()
libgdk-1.2.so.0 + 0x17d7f (0x4035fd7f)
libglib-1.2.so.0 + 0x11773 (0x40392773)
libglib-1.2.so.0 + 0x11d39 (0x40392d39)
libglib-1.2.so.0 + 0x11eec (0x40392eec)
libgtk-1.2.so.0 + 0x94333 (0x402ae333)
nsAppShell::Run()
nsAppShellService::Run()
netscape-bin + 0x7e49 (0x0804fe49)
netscape-bin + 0x8697 (0x08050697)
libc.so.6 + 0x1c507 (0x404d9507) 

Comment 5

[sairuh (rarely reading bugmail)]

stack looks the same as the one in bug 116287. dup?

it's also linux-only for me.

Comment 6

[Blake Ross]

*** This bug has been marked as a duplicate of 116287 ***

Comment 7

[sairuh (rarely reading bugmail)]

okay then...