Steps to reproduce: 1) Edit searchTermOverlay.js -- add |treecell.focus()| right after |row.appendChild(treecell);| in |function constructRow(treeCellChildren)| 2) Start 'mozilla -mail' 3) Open the search window (Search > Search Messages) Actual result: crash Expected result: not crash Stack: 0x41259247 in nsXULElement::Focus (this=0x8b46558) at nsXULElement.cpp:4890 4890 PRInt32 count = mDocument->GetNumberOfShells(); #0 0x41259247 in nsXULElement::Focus (this=0x8b46558) at nsXULElement.cpp:4890 #1 0x40205115 in XPTC_InvokeByIndex (that=0x8b4655c, methodIndex=110, paramCount=0, params=0xbfffd274) at xptcinvoke_unixish_x86.cpp:138 #2 0x409af126 in XPCWrappedNative::CallMethod (ccx=@0xbfffd31c, mode=CALL_METHOD) at xpcwrappednative.cpp:1952 #3 0x409b7a57 in XPC_WN_CallMethod (cx=0x836fe90, obj=0x8abd918, argc=0, argv=0x8b3ecdc, vp=0xbfffd440) at xpcwrappednativejsops.cpp:1254 #4 0x40092ab2 in js_Invoke (cx=0x836fe90, argc=0, flags=0) at jsinterp.c:807 #5 0x400a9e57 in js_Interpret (cx=0x836fe90, result=0xbfffdf24) at jsinterp.c:2719 #6 0x40092b2d in js_Invoke (cx=0x836fe90, argc=1, flags=2) at jsinterp.c:824 We should probably null-check mDocument in there....

reassigning to shaver per his request

Want this for 0.9.5.

does anything like this stack show up in talkback reports?

Boris: Did you submit a Talkback report for your crash? If you can, try to use a Talkback enabled build and send in a Talkback report...it will help us find out if others are seeing this crash as well. Thanks.

Um.... The only way I can get this crash with a talkback build is to modify some chrome code and then repackage chrome... I could do that if it would really help, but it would take some time (I would need to look up how to do all the chrome magic). I may not have time to get to it anytime soon.... What does a talkback have that the stack I provided does not?

It's not about what Talkback has that your stack doesn't, but about having a stack signature (nsXULElement::Focus in this case from looking at your stack) to use as a reference when digging through the Talkback database for other crashes that might be related to the one you have seen.

OK. Incident ID TB36144319Q

Thanks Boris. I looked up your crash and found a few others like it, but there weren't too many. Currently, there are 4 crashes reported for Netscape 6.10 and the only recent crash on the MozillaTrunk is the one Boris just submitted: Incident ID 36144319 Stack Signature nsXULElement::Focus() 7fc63d3a Bug ID Trigger Time 2001-10-01 19:23:05 Email Address bz@mit.edu User Comments Added a focus() call to an XUL element that was not in the document. Build ID 2001100108 Product ID MozillaTrunk Platform ID LinuxIntel Trigger Reason SIGSEGV: Segmentation Fault: (signal 11) Stack Trace nsXULElement::Focus() 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() GlobalWindowImpl::HandleDOMEvent() DocumentViewerImpl::LoadComplete() nsDocShell::EndPageLoad() nsWebShell::EndPageLoad() nsDocShell::OnStateChange() nsDocLoaderImpl::FireOnStateChange() nsDocLoaderImpl::doStopDocumentLoad() nsDocLoaderImpl::DocLoaderIsEmpty() nsDocLoaderImpl::OnStopRequest() nsLoadGroup::RemoveRequest() imgRequestProxy::OnStopRequest() imgRequest::OnStopRequest() ProxyListener::OnStopRequest() nsJARChannel::OnStopRequest() nsOnStopRequestEvent::HandleEvent() nsARequestObserverEvent::HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xeaca (0x40347aca) libglib-1.2.so.0 + 0x10186 (0x40349186) libglib-1.2.so.0 + 0x10751 (0x40349751) libglib-1.2.so.0 + 0x108f1 (0x403498f1) libgtk-1.2.so.0 + 0x8ac69 (0x4026dc69) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x189cb (0x404739cb) Here are a couple of the crashes reported with Netscape 6.10: Incident ID 36116308 Stack Signature nsXULElement::Focus 5dde83de Bug ID Trigger Time 2001-10-01 08:19:46 Email Address User Comments I had just finished an e-mail to a friend and sent it. The window popped up saying that sending was in progress. It crashed at that moment. This version of netscape also seems to require much more resources than 4.5... so much that my hard drive Build ID 2001072700 Product ID Netscape6.10 Platform ID Win32 (Windows 98 4.10 build 67766446) Trigger Reason Access violation Stack Trace nsXULElement::Focus [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 4397] XPTC_InvokeByIndex [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, line 139] XPCWrappedNative::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 1883] XPC_WN_CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, line 1253] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 809] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2703] js_Execute [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 988] JS_EvaluateUCScriptForPrincipals [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3275] nsJSContext::EvaluateString [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 609] GlobalWindowImpl::RunTimeout [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 3426] nsGlobalWindow_RunTimeout [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 3712] nsTimer::Fire [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimer.cpp, line 196] nsTimerManager::FireNextReadyTimer [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimerManager.cpp, line 117] nsAppShell::Run [d:\builds\seamonkey\mozilla\widget\src\windows\nsAppShell.cpp, line 118] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 426] NETSCP6.EXE + 0x16f0 (0x004016f0) NETSCP6.EXE + 0x11b8 (0x004011b8) NETSCP6.EXE + 0x3397 (0x00403397) KERNEL32.DLL + 0x1b560 (0xbff8b560) KERNEL32.DLL + 0x1b412 (0xbff8b412) KERNEL32.DLL + 0x19dd5 (0xbff89dd5) Incident ID 36116308 Stack Signature nsXULElement::Focus 5dde83de Bug ID Trigger Time 2001-10-01 08:19:46 Email Address User Comments I had just finished an e-mail to a friend and sent it. The window popped up saying that sending was in progress. It crashed at that moment. This version of netscape also seems to require much more resources than 4.5... so much that my hard drive Build ID 2001072700 Product ID Netscape6.10 Platform ID Win32 (Windows 98 4.10 build 67766446) Trigger Reason Access violation Stack Trace nsXULElement::Focus [d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 4397] XPTC_InvokeByIndex [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, line 139] XPCWrappedNative::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 1883] XPC_WN_CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, line 1253] js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 809] js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2703] js_Execute [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 988] JS_EvaluateUCScriptForPrincipals [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3275] nsJSContext::EvaluateString [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 609] GlobalWindowImpl::RunTimeout [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 3426] nsGlobalWindow_RunTimeout [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 3712] nsTimer::Fire [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimer.cpp, line 196] nsTimerManager::FireNextReadyTimer [d:\builds\seamonkey\mozilla\widget\timer\src\windows\nsTimerManager.cpp, line 117] nsAppShell::Run [d:\builds\seamonkey\mozilla\widget\src\windows\nsAppShell.cpp, line 118] nsAppShellService::Run [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 426] NETSCP6.EXE + 0x16f0 (0x004016f0) NETSCP6.EXE + 0x11b8 (0x004011b8) NETSCP6.EXE + 0x3397 (0x00403397) KERNEL32.DLL + 0x1b560 (0xbff8b560) KERNEL32.DLL + 0x1b412 (0xbff8b412) KERNEL32.DLL + 0x19dd5 (0xbff89dd5) This is definitely not a topcrasher, since there are only a few incidents for Netscape 6.10...but adding [@ nsXULElement::Focus] for tracking anyway.

I'm pretty sure we're going to want to go back and figure out why mDocument is ever null, since .ownerDocument is _always_ supposed to return a valid document according to the DOM specification, but in the meantime this will keep those 4 or 5 people from crashing. Review me!

Nice shade for that paint! rs=blizzard

Comment on attachment 51812 [details] [diff] [review] Here, have some wallpaper! How embarrassing.

Sicking is my saviour. I am not worthy. Blizzard: can you stamp again? =)

Comment on attachment 51813 [details] [diff] [review] Check _before_ using mDocument in ::Focus. rs=blizzard

When emacs puts a "*" in your modeline, you should save before diffing.

Comment on attachment 51814 [details] [diff] [review] ... and in ::Blur(). r=sicking

I wash my hands of this bug.

Shaver, mDocument is null in mozillas elements whenever the element is not in the tree, or after the document has been told that it's not displayed any more (i.e. after nsIDocument::SetScriptGlobalObject(nsnull) was called). Element.ownerDocument is independent of mDocument in non-XUL elements, but XUL elements are still buggy wrt .ownerDocument.