118059 - clicking in empty listbox of file picker [from bug 118058] crashes app

Status: VERIFIED DUPLICATE of bug 117172

(SeaMonkey :: UI Design, defect)

Description

[sairuh (rarely reading bugmail)]

spun off from bug 117275 and bug 118058 --tested with 2002.01.02.08 comm linux
bits on rh7.2.

1. start browser, eg './netscape -P [profilename]'
2. open a blank editor window, eg, via ctrl+shift+N
3. click on the Open button in the editor's Composition Toolbar.
4. in the resulting file picker --where the dir/file listing will be blank [bug
118058]-- click within the listbox area.

results: crash.

the talkback server is currently being stubborn --will attach trace info as soon
as it becomes available. or when my debug build finishes. whichever comes first.

Comment 1

[sairuh (rarely reading bugmail)]

well drat, i cannot get the blank file picker to appear with a fresh mozilla
debug. will try w/tomorrow's verif bits.

Comment 2

[sairuh (rarely reading bugmail)]

still occurs with today's verif bits [2002.01.04.08 comm linux].

talkback incident #1238195 --looks the same as the one in bug 117275.

nsFileView::GetSelectedFile()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
nsXULElement::HandleDOMEvent()
nsEventStateManager::SendFocusBlur()
nsEventStateManager::SetContentState()
nsXULElement::SetFocus()
nsEventStateManager::ChangeFocus()
nsEventStateManager::PostHandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsView::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 + 0x17d7f (0x40360d7f)
libglib-1.2.so.0 + 0x11773 (0x40394773)
libglib-1.2.so.0 + 0x11d39 (0x40394d39)
libglib-1.2.so.0 + 0x11e1e (0x40394e1e)
nsAppShell::DispatchNativeEvent()
nsXULWindow::ShowModal()
nsWebShellWindow::ShowModal()
nsContentTreeOwner::ShowAsModal()
nsWindowWatcher::OpenWindowJS()
GlobalWindowImpl::OpenInternal()
GlobalWindowImpl::OpenDialog()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
nsXPCWrappedJSClass::CallMethod()
nsXPCWrappedJS::CallMethod()
PrepareAndDispatch()
nsXPTCStubBase::Stub14()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
nsXPCWrappedJSClass::CallMethod()
nsXPCWrappedJS::CallMethod()
PrepareAndDispatch()
nsXPTCStubBase::Stub4()
nsControllerCommandManager::DoCommand()
nsComposerController::DoCommand()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
nsXULElement::HandleDOMEvent()
PresShell::HandleDOMEventWithTarget()
nsButtonBoxFrame::MouseClicked()
nsButtonBoxFrame::HandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEventWithTarget()
nsEventStateManager::CheckForAndDispatchClick()
nsEventStateManager::PostHandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsView::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::DispatchMouseEvent()
nsWidget::OnButtonReleaseSignal()
nsWindow::HandleGDKEvent()
dispatch_superwin_event()
handle_gdk_event()
libgdk-1.2.so.0 + 0x17d7f (0x40360d7f)
libglib-1.2.so.0 + 0x11773 (0x40394773)
libglib-1.2.so.0 + 0x11d39 (0x40394d39) 

Comment 3

[Akkana Peck]

I filed a bunch of talkback reports on this yesterday using builds from
yesterday and the day before.

I just discovered that this only happens if you run the browser and then click
on editor; it doesn't happen if you run mozilla -edit in the first place.

Here's a stack trace with line numbers:
#0  0x427fbaed in nsFileView::GetSelectedFile (this=0x88cc780, 
    aFile=0xbfff8dc0) at nsFileView.cpp:347
#1  0x40237994 in XPTC_InvokeByIndex (that=0x88cc780, methodIndex=12, 
    paramCount=1, params=0xbfff8dc0) at xptcinvoke_unixish_x86.cpp:153
#2  0x40a8556c in XPCWrappedNative::CallMethod (ccx=@0xbfff8e90, 
    mode=CALL_METHOD) at xpcwrappednative.cpp:2009
(stuff before that probably isn't relevant)

Comment 4

[sairuh (rarely reading bugmail)]

yeah, i think the trace is the same as in attachment 62978 [details] in bug 117275.

i filed this separately since i had a reproducible recipe [feel free to dup
either one].

Comment 5

[sairuh (rarely reading bugmail)]

looks like this regressed btwn 12/18 [where this isn't a problem] and 12/20.

another observation: i've got several profiles, and oddly this bug doesn't occur
with all of 'em. the one where it did occur [happens reliably], it's just a
regular [non-migrated] profile --but it is the one i use most of the time, like
for mail and editing.

Comment 6

[Olav Vitters]

Same stacktrace as bug 117172 (topcrash)

Comment 7

[Brian Ryner (not reading)]

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

Comment 8

[sairuh (rarely reading bugmail)]

zap