136388 - moz crashes on close when the location bar dropdown is down [@ nsPopupSetFrame::ActivatePopup]

Status: RESOLVED WORKSFORME

(SeaMonkey :: Autocomplete, defect)

Description

[Hogarth]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020407
BuildID:    2002040706

When the location bar drop down is down and I close Mozilla via the keyboard
(alt-w in my case) Mozilla crashes and burns.

Reproducible: Always
Steps to Reproduce:
1.Change accel binding to alt
2.Start moz
3.type text into the location bar so that the dropdown drops down
4.hit alt-w

Actual Results:  Mozilla window shuts down but the dropdown remains for a while
all by itself, then talkback kicks in.

Expected Results:  Mozilla to shutdown all nice and sweet with no crashes or
anything.

I'd give you an incident report number but for some reason I can't seem to send
it. :/

Comment 1

[Hogarth]

The dropdown is the autocomplete one. If I click on the arrow then the alt-w
doesn't make it through at all while the dropdown is active.

Comment 2

[Hogarth]

Woo. Ok. Managed to send back my talkback reports. The two incident id's are:

TB5028009Y
TB5027540K

Hope they help. :)

Comment 3

[Adam Hauner]

Stephen, should I ask you for TB5028009Y or TB5027540K?

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

nsPopupSetFrame::ActivatePopup()
nsPopupSetFrame::HidePopup()
nsMenuPopupFrame::HideChain()
nsMenuDismissalListener::Rollup()
nsWidget::Destroy()
nsWindow::Destroy()
nsView::~nsView()
nsView::Destroy()
nsFrame::Destroy()
nsContainerFrame::Destroy()
nsBoxFrame::Destroy()
nsMenuPopupFrame::Destroy()
nsPopupSetFrame::Destroy()
nsFrameList::DestroyFrames()
nsContainerFrame::Destroy()
nsBoxFrame::Destroy()
nsFrameList::DestroyFrames()
nsContainerFrame::Destroy()
nsBoxFrame::Destroy()
nsFrameList::DestroyFrames()
nsContainerFrame::Destroy()
ViewportFrame::Destroy()
FrameManager::Destroy()
PresShell::Destroy()
DocumentViewerImpl::Destroy()
nsDocShell::Destroy()
nsWebShell::Destroy()
nsXULWindow::Destroy()
nsWebShellWindow::Destroy()
nsChromeTreeOwner::Destroy()
GlobalWindowImpl::ReallyCloseWindow()
GlobalWindowImpl::CloseWindow()
nsJSContext::ScriptEvaluated()
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::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsGenericElement::HandleDOMEvent()
nsHTMLInputElement::HandleDOMEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsViewManager::HandleEvent()
nsView::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::OnKey()
handle_key_press_event()
libgtk-1.2.so.0 + 0x8ee3f (0x40295e3f)
libgtk-1.2.so.0 + 0xbeb6c (0x402c5b6c)
libgtk-1.2.so.0 + 0xbdfd5 (0x402c4fd5)
libgtk-1.2.so.0 + 0xbc0b3 (0x402c30b3)
libgtk-1.2.so.0 + 0xf2acb (0x402f9acb)
libgtk-1.2.so.0 + 0x8ec89 (0x40295c89)
libgtk-1.2.so.0 + 0x8deee (0x40294eee)
handle_gdk_event()
libgdk-1.2.so.0 + 0x17457 (0x40344457)
libglib-1.2.so.0 + 0x104d8 (0x403744d8)
libglib-1.2.so.0 + 0x10ae3 (0x40374ae3)
libglib-1.2.so.0 + 0x10c7c (0x40374c7c)
libgtk-1.2.so.0 + 0x8d7e7 (0x402947e7)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1917f (0x404b217f) 

Comment 5

[Adam Hauner]

Same stack signature as bug 124969 - Joe, should be this crash for same reason?

Comment 6

[Matthias Versen [:Matti]]

-> default owner

Comment 7

[André Dahlqvist]

*** Bug 146749 has been marked as a duplicate of this bug. ***

Comment 8

[Kai Lahmann (is there, where MNG is)]

WFM with trunk 2002073022, linux. reporter (Hogarth): can you reproduce this bug
with a recent build of mozilla (for example, 1.1beta)? if so, please comment
again with details. if not, please resolve this bug as WORKSFORME. thanks.

Comment 9

[Hogarth]

No can do. Crash still happens. New incident id is:

TB8955855Q

Build ID: 2002080304 (Linux)

Comment 10

[Kai Lahmann (is there, where MNG is)]

so marking it new.

Comment 11

[Andrew Schultz]

*** Bug 184109 has been marked as a duplicate of this bug. ***

Comment 12

[Matthias Versen [:Matti]]

*** Bug 202541 has been marked as a duplicate of this bug. ***

Comment 13

[Marc Bejarano]

this bug needs to be OS -> All.  see bug 202541.

Comment 14

[Ashley Bischoff (blog at handcoding.com)]

OS -> All

Comment 15

[Andrew Schultz]

this WORKSFORME since 1.6 on linux
can anybody else still reproduce the crash?

Comment 16

[Wayne Mery (:wsmwk)]

WFM also
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051228 SeaMonkey/1.5a