Select "Search" -> "Find on this Pages". Now keep the search dialog open and select "Search" -> "Find on this Pages" again and you crashes!

Thank you very much for you bug report. For future bugs, please read the bug writing guidelines http://www.mozilla.org/quality/bug-writing-guidelines.html In paticular we need more information such as Build number and the Operating systems that you've tested this on. This crashes on me with WinNT build 2000010408. However, sometimes it doesn't crash until the 3rd try.

XPapps

ACTUAL RESULTS: Mozilla dies ungracefully with a segfault. EXPECTED RESULTS: The "Find on this page" menu option should not even be selectable if the dialog is already open. ADDITIONAL BUILDS AND PLATFORMS TESTED ON: This is also present in my Solaris 2.6 build of the M12 src, and M12 (Build ID: 1999122023) on WinNT4 sp5 ADDITIONAL INFORMATION: The following is dumped on console when this bug is reproduced on Solaris: JavaScript Error: ReferenceError: onUnload is not defined nsWidget::~nsWidget() of toplevel: 24 widgets still exist. ###!!! ASSERTION: no rendering context: 'nsnull != aRenderingContext', file nsHTMLReflowState.cpp, line 73 Program received signal SIGSEGV, Segmentation fault. 0xeccbd818 in nsFormControlHelper::GetTextSize (aPresContext=0x58db00, aFrame=0x5f0650, aString=@0xefff9960, aSize=@0xefff9cc8, aRendContext=0x0) at nsFormControlHelper.cpp:339 I can provide a gdb stack trace if it'll help.

Bill, is this yours?

I'll investigate. Could be a bug in xptoolkit or editor stuff.

Here's a stack trace. If any sees anything they recognize, chime in. I have no idea what's going on so I'll have to dig deeper. XPTC_InvokeByIndex(nsISupports * 0x0295b4d0, unsigned int 0x00000003, unsigned int 0x00000001, nsXPTCVariant * 0x0012d8ac) line 137 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x02a22ad0, nsXPCWrappedNative * 0x0295cb40, const XPCNativeMemberDescriptor * 0x0295b124, nsXPCWrappedNativeClass::CallMode CALL_GETTER, unsigned int 0x00000000, long * 0x00000000, long * 0x0012e068) line 904 + 43 bytes nsXPCWrappedNativeClass::GetAttributeAsJSVal(JSContext * 0x02a22ad0, nsXPCWrappedNative * 0x0295cb40, const XPCNativeMemberDescriptor * 0x0295b124, long * 0x0012e068) line 852 WrappedNative_GetProperty(JSContext * 0x02a22ad0, JSObject * 0x01fc8630, long 0x0295b070, long * 0x0012e068) line 235 + 24 bytes js_Interpret(JSContext * 0x02a22ad0, long * 0x0012e1f8) line 2182 + 1055 bytes js_Invoke(JSContext * 0x02a22ad0, unsigned int 0x00000000, unsigned int 0x00000000) line 681 + 13 bytes js_Interpret(JSContext * 0x02a22ad0, long * 0x0012ea24) line 2226 + 15 bytes js_Invoke(JSContext * 0x02a22ad0, unsigned int 0x00000000, unsigned int 0x00000000) line 681 + 13 bytes js_Interpret(JSContext * 0x02a22ad0, long * 0x0012f250) line 2226 + 15 bytes js_Invoke(JSContext * 0x02a22ad0, unsigned int 0x00000001, unsigned int 0x00000002) line 681 + 13 bytes js_InternalCall(JSContext * 0x02a22ad0, JSObject * 0x00d9a760, long 0x01fb18e8, unsigned int 0x00000001, long * 0x0012f3d4, long * 0x0012f380) line 758 + 15 bytes JS_CallFunctionValue(JSContext * 0x02a22ad0, JSObject * 0x00d9a760, long 0x01fb18e8, unsigned int 0x00000001, long * 0x0012f3d4, long * 0x0012f380) line 2758 + 29 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x02a22c60, void * 0x00d9a760, void * 0x01fb18e8, unsigned int 0x00000001, void * 0x0012f3d4, int * 0x0012f3d0) line 564 + 33 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x02b426c4) line 128 + 57 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x02957e30, nsIDOMEvent * 0x02b426c4, unsigned int 0x00000001) line 640 + 19 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x02b1f780, nsEvent * 0x0012fc6c, nsIDOMEvent * * 0x0012f7d0, unsigned int 0x00000007, nsEventStatus * 0x0012fcac) line 1191 + 31 bytes GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x02a22cc4, nsIPresContext * 0x02b1f780, nsEvent * 0x0012fc6c, nsIDOMEvent * * 0x0012f7d0, unsigned int 0x00000001, nsEventStatus * 0x0012fcac) line 3088 nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x02a21ed0, nsIDocumentLoader * 0x02a20c40, nsIChannel * 0x02b1eb80, unsigned int 0x00000000) line 3069 + 34 bytes nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x02a20c40, nsIChannel * 0x02b1eb80, unsigned int 0x00000000) line 813 nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0x00000000) line 704 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x02a20c44, nsIChannel * 0x02b1eb80, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned short * 0x00000000) line 648 nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x02a21db0, nsIChannel * 0x02b1eb80, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned short * 0x00000000) line 532 + 42 bytes nsCachedChromeChannel::Notify(nsITimer * 0x029cb200) line 313 TimerImpl::Fire(unsigned long 0x00b8e8e5) line 317 TimerImpl::ProcessTimeouts(unsigned long 0x00b8e8e5) line 191 FireTimeout(HWND__ * 0x00000000, unsigned int 0x00000113, unsigned int 0x0000786f, unsigned long 0x00b8e8e5) line 105 + 9 bytes USER32! 77e71373() nsAppShellService::Run(nsAppShellService * const 0x00cadb30) line 445 main1(int 0x00000001, char * * 0x00c332a0) line 622 + 32 bytes main(int 0x00000001, char * * 0x00c332a0) line 710 + 13 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1b304()

Updating QA Contact.

was able to repro on winNT (comm, 2000-011811) and linux (comm, 2000-011909). not able to repro on mac (mozilla, 2000-011910). updated the summary to reflect this... the talkback reports don't seem useful (tho' tell me if i'm not looking in the right places). for linux, incident 4143765: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=9&cp=2&ck1= SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=4143765 for winNT, incident 4143779: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=9&cp=1&ck1= SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=4143779

It turns out that it is futile to try to support two simultaneous searches on the same browser window (it actually worked at one point but upon closer examination there's too many problems). Plus, Communicator never allowed this and I'm not sure users want/need it. So, I've changed the code so that a second "Search on this page..." request (or Ctrl-F or equivalent on your platform of choice, when this is working) will simply transfer focus to the existing Find dialog. This seems better than the currently observed behavior in 4.x since it permits you to easily type in a new search string without having to remove your hands from the keyboard. I'll check this code in when M14 gets the green light. Please comment if this strategy offends you in any way, though.

Adding "crash" keyword to all known open crasher bugs.

Adding "beta1" to keyword list since this is a crasher and I've already got the fix for it (waiting for code review).

Putting on on PDT+ radar for beta1.

Fix checked in, should appear in the Feb 09 builds.

no longer a prob! tested using 2000-02-09-08 comm bits on linux and winNT.