User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.8 When I'm looking web pages and some popup needs to come up, the firefox crashes (all windows opened of course). I've blocked up the popup windows with the Preferences and now I can "live", but I would like to have them on... It's a bud in 0.9.3 0.9 hasn't this problem Maybe it's just in pages when the window.open javascript function tries to open the window at the beginning... The window.open function works perfectly when the page is loaded completely. So it's a window.open problem while the loading of the body. Reproducible: Always Steps to Reproduce: 1. Go to any popup window web page 2. 3.

Alex: Could you provide TalkBack incident ID of your crash?

(In reply to comment #1) > Alex: Could you provide TalkBack incident ID of your crash? Of course... here you got some of 'em TB544347Y, TB543949H, TB543792W, TB539006X, TB539000E, TB538996E, TB538993X, TB536882M, TB536455Z, TB536329W, TB533012G, TB533008Z, TB532904E, TB525359W, TB516082Q, TB516081X, TB513618Z, TB513605W

Most of incidents has this stacktrace: 0x00000000 nsCOMPtr_base::assign_with_AddRef [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp, line 90] nsImageBoxFrame::DidSetStyleContext [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsImageBoxFrame.cpp, line 558] nsIFrame::SetStyleContext [../../../../dist/include/layout/nsIFrame.h, line 577] nsFrameManager::ReResolveStyleContext [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsFrameManager.cpp, line 1616] nsFrameManager::ComputeStyleChangeFor [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsFrameManager.cpp, line 1659] nsCSSFrameConstructor::AttributeChanged [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp, line 10088] PresShell::AttributeChanged [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp, line 5202] nsXULElement::SetAttrAndNotify [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 2225] nsXULElement::SetAttr [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 2148] nsXULElement::SetAttribute [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 1022] XPTC_InvokeByIndex [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102] XPCWrappedNative::CallMethod [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2027] XPC_WN_CallMethod [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1287] js_Invoke [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 941] js_Interpret [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 2973] js_Invoke [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 958] nsXPCWrappedJSClass::CallMethod [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1336] nsXPCWrappedJS::CallMethod [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 450] SharedStub [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147] nsEventListenerManager::HandleEventSubType [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp, line 1434] nsEventListenerManager::HandleEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp, line 1512] GlobalWindowImpl::HandleDOMEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp, line 892] nsXULDocument::HandleDOMEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/document/src/nsXULDocument.cpp, line 1257] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 2823] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleChromeEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp, line 3984] GlobalWindowImpl::HandleDOMEvent [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp, line 888] DocumentViewerImpl::LoadComplete [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp, line 913] nsDocShell::EndPageLoad [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp, line 4330] nsWebShell::EndPageLoad [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/docshell/base/nsWebShell.cpp, line 805] nsDocShell::OnStateChange [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp, line 4264] nsDocLoaderImpl::FireOnStateChange [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp, line 1232] nsDocLoaderImpl::doStopDocumentLoad [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp, line 867] nsDocLoaderImpl::OnStopRequest [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp, line 695] nsLoadGroup::RemoveRequest [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsLoadGroup.cpp, line 695] nsInputStreamChannel::OnStopRequest [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsInputStreamChannel.cpp, line 371] nsInputStreamChannel::`vftable' nsPrintOptions::AddRef [d:/builds/tinderbox/firefox-0.9.3/WINNT_5.0_Clobber/mozilla/gfx/src/nsPrintOptionsImpl.cpp, line 69] 0x8b560c45 other signatures/stacks: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB539006X http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB536455Z http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB536329W http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB525359W http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB516081X http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB513618Z

And what does they mean ? i do not know nothing about that

Alex: stacktrace should be usefull for developers, it provides links to problematic part of source code.

Ok, i didn't know exactly the working of this. Then i supposed i cann't do anything but wait :) I just wanted to paste you this erro because i think it's critical Thank you and i wait for resolution of this

I have downgrade to 0.9 and now there's no problem at all But i'd like to use the latest stable one :)

This is clearly the #1 crasher with early Talkback data for Firefox 1.0 PR1. Here are a couple of sets of crashes: Count Offset Real Signature [ 16 0x00000000 26066259 - nsCOMPtr_base::assign_with_AddRef ] Crash date range: 14-SEP-04 to 15-SEP-04 Min/Max Seconds since last crash: 26 - 17482 Min/Max Runtime: 1012 - 22473 Count Platform List 16 Windows XP [Windows NT 5.1 build 2600] Count Build Id List 16 2004091322 No of Unique Users 13 Stack trace(Frame) 0x00000000 nsCOMPtr_base::assign_with_AddRef [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/glue/nsCOMPtr.cpp line 90] nsImageBoxFrame::UpdateAttributes [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsImageBoxFrame.cpp line 372] nsCSSFrameConstructor::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 10114] PresShell::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp line 5192] nsXULElement::SetAttrAndNotify [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2225] nsXULElement::SetAttr [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2148] nsXBLPrototypeBinding::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeBinding.cpp line 483] nsXBLBinding::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp line 842] nsXULElement::SetAttrAndNotify [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2193] nsXULElement::SetAttr [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2148] nsXBLPrototypeBinding::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeBinding.cpp line 483] nsXBLBinding::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp line 842] nsXULElement::SetAttrAndNotify [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2193] nsXULElement::SetAttr [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2148] nsXULElement::SetAttribute [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 1022] XPTC_InvokeByIndex [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp line 102] XPCWrappedNative::CallMethod [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 2028] XPC_WN_CallMethod [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1287] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 941] js_Interpret [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 2973] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 958] js_InternalInvoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 1035] js_InternalGetOrSet [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 1078] js_SetProperty [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsobj.c line 2849] js_Interpret [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 2164] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 958] js_InternalInvoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 1035] JS_CallFunctionValue [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsapi.c line 3698] nsJSContext::CallEventHandler [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp line 1297] GlobalWindowImpl::RunTimeout [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp line 5083] GlobalWindowImpl::TimerCallback [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp line 5445] nsXULWindow::CreateNewContentWindow [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp line 1832] nsXULWindow::CreateNewWindow [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp line 1716] nsWindowCreator::CreateChromeWindow2 [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/toolkit/xre/nsWindowCreator.cpp line 123] nsWindowWatcher::OpenWindowJS [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp line 620] nsWindowWatcher::OpenWindow [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp line 458] GlobalWindowImpl::OpenInternal [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp line 4682] GlobalWindowImpl::Open [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp line 3280] XPTC_InvokeByIndex [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp line 102] XPCWrappedNative::CallMethod [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 2028] XPC_WN_CallMethod [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1287] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 941] js_Interpret [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 2973] js_Execute [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 1162] JS_EvaluateUCScriptForPrincipals [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsapi.c line 3649] nsJSContext::EvaluateString [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp line 946] nsJSThunk::EvaluateScript [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp line 286] nsJSChannel::InternalOpen [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp line 533] nsJSChannel::AsyncOpen [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp line 513] nsURILoader::OpenURI [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/uriloader/base/nsURILoader.cpp line 827] nsDocShell::DoChannelLoad [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp line 5884] nsDocShell::DoURILoad [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp line 5663] nsDocShell::InternalLoad [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp line 5449] nsWebShell::OnLinkClickSync [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/docshell/base/nsWebShell.cpp line 652] OnLinkClickEvent::HandleEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/docshell/base/nsWebShell.cpp line 438] PL_HandleEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/threads/plevent.c line 674] 0x778b0c24 nsFormSubmission::ProcessValue [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/html/content/src/nsFormSubmission.cpp line 1455] 0x8a370815 (816853) URL: http://www.bose.com/learning/project_sound/bose_suspension.jsp (811667) Comments: I clicked on a link within BestBuy.com ==================================================================================================== Count Offset Real Signature [ 15 0x00000000 c61e5ce1 - nsCOMPtr_base::assign_with_AddRef ] Crash date range: 14-SEP-04 to 15-SEP-04 Min/Max Seconds since last crash: 99 - 29463 Min/Max Runtime: 100 - 29463 Count Platform List 13 Windows XP [Windows NT 5.1 build 2600] 2 Windows 2K [Windows NT 5.0 build 2195] Count Build Id List 15 2004091322 No of Unique Users 15 Stack trace(Frame) 0x00000000 nsCOMPtr_base::assign_with_AddRef [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/glue/nsCOMPtr.cpp line 90] nsImageBoxFrame::UpdateAttributes [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsImageBoxFrame.cpp line 372] nsCSSFrameConstructor::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 10114] PresShell::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp line 5192] nsXULElement::SetAttrAndNotify [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2225] nsXULElement::SetAttr [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2148] nsXBLPrototypeBinding::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeBinding.cpp line 483] nsXBLBinding::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp line 842] nsXULElement::SetAttrAndNotify [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2193] nsXULElement::SetAttr [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2148] nsXBLPrototypeBinding::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLPrototypeBinding.cpp line 483] nsXBLBinding::AttributeChanged [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp line 842] nsXULElement::SetAttrAndNotify [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2193] nsXULElement::SetAttr [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 2148] nsXULElement::SetAttribute [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp line 1022] XPTC_InvokeByIndex [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp line 102] XPCWrappedNative::CallMethod [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 2028] XPC_WN_CallMethod [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1287] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 941] js_Interpret [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 2973] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 958] js_InternalInvoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 1035] js_InternalGetOrSet [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 1078] js_SetProperty [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsobj.c line 2849] js_Interpret [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 2164] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 958] js_InternalInvoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 1035] JS_CallFunctionValue [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsapi.c line 3698] nsJSContext::CallEventHandler [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp line 1297] GlobalWindowImpl::RunTimeout [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp line 5083] GlobalWindowImpl::TimerCallback [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp line 5445] nsXULWindow::CreateNewContentWindow [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp line 1832] nsXULWindow::CreateNewWindow [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsXULWindow.cpp line 1716] nsWindowCreator::CreateChromeWindow2 [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/toolkit/xre/nsWindowCreator.cpp line 123] nsWindowWatcher::OpenWindowJS [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp line 620] nsWindowWatcher::OpenWindow [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp line 458] GlobalWindowImpl::OpenInternal [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp line 4682] GlobalWindowImpl::Open [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp line 3280] XPTC_InvokeByIndex [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp line 102] XPCWrappedNative::CallMethod [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp line 2028] XPC_WN_CallMethod [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp line 1287] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 941] js_Interpret [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 2973] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 958] js_InternalInvoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c line 1035] JS_CallFunctionValue [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/js/src/jsapi.c line 3698] nsJSContext::CallEventHandler [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp line 1297] nsJSEventListener::HandleEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/dom/src/events/nsJSEventListener.cpp line 184] nsEventListenerManager::HandleEventSubType [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp line 1436] nsEventListenerManager::HandleEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp line 1516] nsGenericElement::HandleDOMEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp line 1960] nsGenericHTMLElement::HandleDOMEventForAnchors [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/html/content/src/nsGenericHTMLElement.cpp line 1365] nsHTMLAnchorElement::HandleDOMEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLAnchorElement.cpp line 326] nsGenericElement::HandleDOMEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp line 1990] nsHTMLImageElement::HandleDOMEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLImageElement.cpp line 579] PresShell::HandleEventInternal [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp line 6057] PresShell::HandleEventWithTarget [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp line 5982] nsEventStateManager::CheckForAndDispatchClick [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp line 2921] nsEventStateManager::PostHandleEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp line 1921] PresShell::HandleEventInternal [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp line 6109] PresShell::HandleEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp line 5919] nsViewManager::HandleEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp line 2290] nsViewManager::DispatchEvent [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp line 2030] (819005) URL: http://www.bilsport.se/artikel_bild_topp.php3?visa_id=48731&bildnamn=top_02_produktnytt.gif&avdelning=11# (819005) Comments: I was about to click on a picture to enlarge it. Then Firefox just shut down. (817309) Comments: Looking at wincustomize.com at the wallpaper section (816614) URL: wincustomize.com (815246) URL: www.customize.com (813535) URL: www.pentax.com (813232) URL: http://www.vsen.tv/gallery3/folderview.asp?bid=2&folder=WCG+2004+Brasil Since the real stack signature is beneath 0x00000000, this crash will be difficult to query for. Just go to: http://talkback-public.mozilla.org/reports/firefox/FF10PR1/smart-analysis.all And search for nsCOMPtr_base::assign_with_AddRef for more stack info and user comments. Marking topcrash+ and nominating for aviary1.0 to get this on the radar early.

Not sure if it belongs in this bug or not, but I've experienced three crashes so far with 1.0PR on Linux, all related to launching a popup window. All from http://www.pgdp.net/c/tools/proofers/proof_per.php (needs login), using javascript onclick: on links to open a new window. Popup blocking is enabled; no sites added to allow list. TB IDs are TB817272Y, TB831321Q, TB831599W. Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10 Mandrake 9.2: Kernel 2.4.22 / XFree86 v4.3 / WindowMaker v0.80.2 I have not yet been able to reliably reproduct this crash.

I've not been able to reproduce this using any of the URLs given in talkback reports or using my own testcases with window.open. Some sort of timing problem, maybe...

(In reply to comment #10) > I've not been able to reproduce this using any of the URLs given in talkback > reports or using my own testcases with window.open. Some sort of timing > problem, maybe... See bug 259822. I think it's the same error, and I can always reproduce it.

(In reply to comment #11) > (In reply to comment #10) > > I've not been able to reproduce this using any of the URLs given in talkback > > reports or using my own testcases with window.open. Some sort of timing > > problem, maybe... > > See bug 259822. I think it's the same error, and I can always reproduce it. All the url's in this bug (and bug 259822) give me a stacktrace like in bug 258943 (crashes in nsImageBoxFrame::AttributeChanged). I'm using Firefox 1.0PR on Mac OS X. The stacktraces in this bug look different (crashes in nsCOMPtr_base::assign_with_AddRef), but that seems to be related to the platform. I alwasy crashed at the same location. Should we dupe these 2 (bug 258943 and bug 259822) to this one, and mark it for all platforms ?

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

jst and dbaron can you have a look at this? we want to try and get this for 1.0

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

(In reply to comment #14) > jst and dbaron can you have a look at this? we want to try and get this for 1.0 See bug 258943 comment 31 : This crash might have accidently been solved a few days ago. Maybe the fairies did it ?

This happens to me consistently on OS X (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10) for any window.open() which specifies a "width" in the feature-set parameter. I do not get crashes when width is not specified.

still repro (semi-random, but often enough to make it unusable...) on: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040930 Firefox/0.10 StumbleUpon/1.998

Uri: Any chance you can put together a quick testcase that crashes and attach it to this bug? I've been having trouble reproducing this with the various urls I've found in Talkback data.

Click on the words "Click Me!" to crash Firefox Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10 This is 100% reproducable for me.

(In reply to comment #20) > Created an attachment (id=160808) > testcase for crashing Ff/0.10 on OS X > > Click on the words "Click Me!" to crash Firefox > Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 > Firefox/0.10 > This is 100% reproducable for me. Though I'm annoyed by this bug too (I had a crash with this build a little while ago), I couldn't 100% reproduce it on your testcase. In my case it happens sometimes, but not always with the same links. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041001 Firefox/0.10

(In reply to comment #21) > Though I'm annoyed by this bug too (I had a crash with this build a little while > ago), I couldn't 100% reproduce it on your testcase. In my case it happens > sometimes, but not always with the same links. > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041001 > Firefox/0.10 I had the same problem with Firefox/0.10 on GNU/Linux, it would crash randomly, on sites, and if I viewed the site/page later, it'd work perfectly. But, Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 doesn't seem to crash anymore. I just upgraded today, so I will try it out for a bit to make sure this bug is really gone.

How to reproduce: recipe derived on: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041002 Firefox/0.10 StumbleUpon/1.998 Background: a few times people have pointed the finger at sessionsaver (among other possibilities for plugin trouble). I am pretty sure that the trouble is not with sessionsaver, but with the number of tabs that are open. It may be either just more likely with many tabs, or caused by many tabs. Steps: (clean install, clean profile [sic!]) 1. Bookmarks -> Firefox Crew Picks -> Open in tabs 2. from the google news page, open up all the headlines in new tabs; repeat until you have 40+ tabs open [tabs fall off the right edge, and are no longer all displayed] 3. go to: http://story.news.yahoo.com/news?tmpl=index2&cid=1059 [this should be the news photo popular slideshows page, from which all the photos are links to javascript popups] 4. click on any of the js popup photo links should be near 100% repro please confirm

(In reply to comment #23) > Background: a few times people have pointed the finger at sessionsaver (among > other possibilities for plugin trouble). I am pretty sure that the trouble is > not with sessionsaver, but with the number of tabs that are open. It may be > either just more likely with many tabs, or caused by many tabs. I've used no tabs in my browsing and won't use them henceforce, but encounters this bug.

This problem does not occur on both of my Macintoshes. One is a G3 iBook, problem occurs. Other is a G4 500MHz, proble has not occurred yet. I have not determined any differences as to Firefox or OS versions or system extensions.

Hmmm... the machine I'm seeing this on is a G3 iMac running OS X 10.3 (Panther). Perhaps this is G3-specific? (would be weird, but weird things happen). Floyd - on your iBook, is this 100% reproducable (with the testcase I attached)? So far, I seem to be the only one here who can reproduce this consistently.

(In reply to comment #23) > Steps: > > (clean install, clean profile [sic!]) > > 1. Bookmarks -> Firefox Crew Picks -> Open in tabs > 2. from the google news page, open up all the headlines in new tabs; repeat > until you have 40+ tabs open [tabs fall off the right edge, and are no longer > all displayed] > 3. go to: http://story.news.yahoo.com/news?tmpl=index2&cid=1059 [this should be > the news photo popular slideshows page, from which all the photos are links to > javascript popups] > 4. click on any of the js popup photo links > > should be near 100% repro > > please confirm I have noticed that often times when I have this crash it is with no tabs open whatsoever. Usually its at work, where our intranet app does a popup at body onLoad and FF crashes instantly. If i restart FF and go to that page again, it works flawlessly. Mike, the bug you mention may be related to what I encounter, but I'm not so sure.

In reply to uriber@gmail.com: Yes it is 100% reproducible on my G3 iBook using the posted test case and every other window.open() example I have tried (they all include a width= argument). The one exception was when I tried disabling "fast user switching", which was one thing different about the settings on my two computers. When I first disabled it and tried a wndow.open example, it worked and did not crash. However, it was only that one time. Subsequent attempts caused the crash. I think this must have been a fluke but thought I would mention it. Also, I don't think this problem occurred before I upgraded the iBook to Panther. Previously I was running Jaguar (10.2.8). However, I cannot say for sure that I used a javascript window.open() with Firefox running under Jaguar. So it may be a G3 / OSX 10.3 specific problem.

is this the same with bug I filed: FF10PR1 crashes when I try to open the GMAIL CONTACTS (it's a pop-up): Bug 262686

(In reply to comment #28) > In reply to uriber@gmail.com: > > So it may be a G3 / OSX 10.3 specific problem. It's 100% reproducible on my G3 ibook with 10.2.8, so it's not Panther-specific.

Works for me... Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 iBook G3 700 MHz - OS X 10.3.5

Even though I wasn't able to reproduce the crash using this testcase I am still having crash trouble with other popup window sites.

WFM: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10.1

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

I'll second comment 24; I don't use tabs in browsing (only windows) and have gotten the popup crash on Linux.

Well, isn't this just fabulous, I am running: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041003 Firefox/0.10 And up until I installed THIS version, the problem hadn't re-occured. Like I said in the bug filed before; find out the prick who submitted a patch that CAUSED this breakage and remove his rights to submit code in future.

Matt, let's try and keep things civil.

Matt, let's try and keep things civil.

Had a crash again with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041004 Firefox/0.10

This still occurs with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 What tends to happen is that I have it occur sometimes once or twice a day - it does not happen consistently - but is always triggered by clicking on a link that pops up a window. Today's crash was triggered by a phpMyAdmin Query Window link. I have the following extensions installed if that helps: Web Developer 0.8, Gmail Notifier 0.3.3 and SpellBound 0.6.0. Talkback ID: TB1129052Q I had, prior to 0.10.1 been using a nightly, I think it was 20040928 or 20040929 which I hadn't managed to crash in the week or so before this new release.

using Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 had a crash on window.open on body onLoad. restarted FF and this time it worked perfectly. talkback id: TB1136161Q

I have the same problem: the test case didn't work for me, I use tabs a lot, it seems to only work after a certain uptime of the browser. Re https://bugzilla.mozilla.org/show_bug.cgi?id=255372#c40 : I don't use any of your extensions. What I have is Sage, Adblock, Linky, Single window, MiniT and mouse gestures.

I can reproduce a popup crash 100% of the time. Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041006 Firefox/0.10.1 In Gmail, when viewing an email, you are given an option to send a gmail invite to the sender. This normally opens a pop-up. I've tried switching between compiled and binary installs, with the same effect. With Firefox 0.10.1 on Windows XP and Windows 2000, I get the popup fine, without a crash. However, I have definitely been experiencing many crashes with .10 and .10.1 on Windows as well, mostly (all?) associated with pop-ups. Email me at martin@simaltech.com for gmail invites for testing. Hopefully someone more skilled that me can use this to construct a test case.

(In reply to comment #32) > Even though I wasn't able to reproduce the crash using this testcase I am still > having crash trouble with other popup window sites. Now I am getting this crash 100% of the time -- same build, different day.

I also see this with 0.10.1 on Linux, but only on 32bit architectures - amd64 doesn't exhibit the bug, but x86 and powerpc both do. Backtrace comes out to be: http://www.planetarytramp.net/firefox-bt Steps to reproduce - this is 100% reproducible with a freshly opened firefox session, a bit less reliable after the browser has been running for some time: Open browser. Go to gmail (I, too, have invites available if necessary) Click contacts Click "Import Contacts" segfault leading to the above back trace. I'm happy to debug further if someone wants to point me in the right direction.

(In reply to comment #17) > This happens to me consistently on OS X (Mozilla/5.0 (Macintosh; U; PPC Mac OS X > Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10) for any window.open() which > specifies a "width" in the feature-set parameter. I do not get crashes when > width is not specified. I was wrong about this. The actual crucial feature is not "width", but "toolbar". Any window.open() which does not require a toolbar (i.e., specifies a non-empty feature set, which does not include "toolbar") crashes. If "toolbar" is specified (or no featureset is specified there is no crash). Which suggests the following workaround: Set dom.disable_window_open_feature.toolbar to "true". All windows will open with a toolbar, and no crashes. This works for me, at least. I hope this information will somehow be useful in tracking down the source of this bug.

What I meant to write is: If "toolbar" is specified (or no featureset is specified) there is no crash. Sorry for the spam.

(In reply to comment #45) > I also see this with 0.10.1 on Linux, but only on 32bit architectures - amd64 > doesn't exhibit the bug, but x86 and powerpc both do. > Backtrace comes out to be: > http://www.planetarytramp.net/firefox-bt > Steps to reproduce - this is 100% reproducible with a freshly opened firefox > session, a bit less reliable after the browser has been running for some time: > Open browser. > Go to gmail (I, too, have invites available if necessary) > Click contacts > Click "Import Contacts" > segfault leading to the above back trace. I've yet to see this crash myself, and I just tried again to reproduce it following the above instructions w/o luck, using a build from today on Linux x86. > I'm happy to debug further if someone wants to point me in the right direction. Do you have any extensions installed? If so, try a clean install with a clean profile and let us know, and if you're able to catch this in a debugger, poke around an see if you see anything odd...

(In reply to comment #30) > (In reply to comment #28) > > In reply to uriber@gmail.com: > > > > So it may be a G3 / OSX 10.3 specific problem. > > It's 100% reproducible on my G3 ibook with 10.2.8, so it's not Panther-specific. It took a few days before it crashed my G4, 400 MHz. But then it crashed 3 times in a row before I forced the toolbar, so it isn't G3 specific. But it does crash my two G3s more often. Maybe it's some kind of timing problem, more likely to crash on a slower computer? (That could explain why more tabs increases the probability of a crash for some also) (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001 Firefox/0.10.1)

I spent some time testing this today on a Mac G3 400 MHz Running 10.2.8 as well as on my own machine G4 867 MHz running 10.3.5 and was not able to reproduce it. I tried Uri's attachment on both machines and it did not crash (just spawned a new window.) I tested with a clean profile as well as an existing profile. I also went back and forth between gmail since that was mentioned as one problem site but saw no issues. Can the people on this bug that are still having issues with crashing (especialy the ones that are experiencing it 100% of the time) provide more information - such as what extensions/themes are installed, how much RAM they have, specific sites they were at when it crashed. This will help us out since we are not able to currently reproduce it with the data provided. Thanks.

(In reply to comment #50) > Can the people on this bug that are still having issues with crashing (especialy > the ones that are experiencing it 100% of the time) provide more information - > such as what extensions/themes are installed, how much RAM they have, specific > sites they were at when it crashed. This will help us out since we are not able > to currently reproduce it with the data provided. Thanks. I haven't managed to force it to crash. Sometimes I can use Firefox for days without a crash, but when it starts crashing, it continues for a while. That is after the first crash, start up Firefox, click on an popup-link and it crashes again (about 100% then, which makes it impossible to finish whatever you were trying to do. Not depending on site). Between that it doesn't crash. I'm not sure how I've managed to make it stop crashing, I usually return to 0.9.3. Which site doesn't seem to matter, I think Uri's attachment is as good as any to reproduce the crash. I have no extensions/themes installed. New profile except a bookmarkfile, or an old profile. 160-224MB of RAM, 233-400 MHz G3-G4, Mac OS 10.2.6 or 10.3.5.

I just installed Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20041006 Firefox/0.10 on OS X 10.2.8, ibook G3 500MhZ with 384MB RAM. On first try, the testcase crashed FF with both a clean and an old profile. After restart, I could open it several times, so I tried to click on the pictures at http://www.swosh-music.com/content/media_photos_band.php it worked, but it took quite long before opening the picture in a new window, even giving me a spinning beachball (usually happened before crashing). Then I wanted to try to do the same when having opened many tabs. But I didn't even came to click on a link, because opening about 5 additional tabs crashed FF. Just tried the same again: testcase, swosh-music.com in new tab, opened pictures on swosh, opened several new tabs, tried swosh again, tried testcase again. And everything worked. Then I tried to open the cuneaform extension which always crashed on me with the 21sept. build, there was the beachball, but the window was opened. But when I tried to close it, FF crashed. Restarting FF, opening and closing cuneaform, worked fine. So it went down from 100% to occasional crashes for me. Extensions I have installed: keyconfig jump link dictionary search bugmenot image-show-hide linky openbook switchproxy tool tab double-click cookie button download manager tweak user agent switcher go up (disabled) digger (disabled) adblock cuneaform I don't have gmail, but if anyone cares to invite me, I'll be more than happy to test it. :-)

Marcia Knous asked for some specifics. On iBook 500MHz with 256 MB ram, the crash occurs 100% on the test case. Also crashes on http://www.wayneart.org/wacschedule.php?db=children when clicking on one of the class names that is suppoed to open a small window with a description of the class. I have no Firfox extensions or additional themes installed, just the default installation. The suggeted work-around setting om.disable_window_open_feature.toolbar to "true" avoid the crash so I'll gep that option set for the time being. Would it help if you had a copy of crash log or core dump? I'm not sure I know where those are saved or if some option needs to be set to save the kinds of details you would need.

The original reporter says this problem occurs with the 0.9.3 release build and not with the 0.9 release. It might make sense for someone who can actually reproduce this issue to: 1. Verify the above and 2. Try the 0.9.1 and 0.9.2 release builds as well? We may easily be able to narrow it doewn to a couple of checkins if we can narrow this down a bit more. there were not all that many checkins between 0.9 and 0.9.3 in the first place.

> Can the people on this bug that are still having issues with crashing (especialy > the ones that are experiencing it 100% of the time) provide more information - > such as what extensions/themes are installed, how much RAM they have, specific > sites they were at when it crashed. This will help us out since we are not able > to currently reproduce it with the data provided. Thanks. I'm seeing this on a clean, brand new, profile (as well as on my regular profile). My machine's specs: 350 MHz G3, 384 MB SDRAM, OS X 10.3.5. Talkback incident IDs (using the atached testcase): TB1158364Y (with the 0.10 release) and TB1156886H (with the 20041006 nightly).

(In reply to comment #54) > The original reporter says this problem occurs with the 0.9.3 release build and > not with the 0.9 release. It might make sense for someone who can actually > reproduce this issue to: > > 1. Verify the above > I do not see the crash on 0.9.3. I should also mention that I do not see the crash on a recent trunk build (20040928). If there's somewhere out there an archive of nightlies between 0.9 and 0.10, I'll be willing to try out some of them to help see where the regression occured.

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

I found the nightly build archives and conducted a binary search. Results: Branch builds up to and including the 20040906 build do not crash on the testcase. Branch builds from 20040908 and onwards do crash. I couldn't get the 20040907 build to work at all: The "Select a Profile" dialog didn't display any profiles, didn't allow me to create a new one, and didnt let me continue without selecting a profile. So we're left with about 48 hours of checkins to search.

Based on the dates in my previous comment, I think the main suspect for this bug is the patch for bug 252326 (attachment 158155 [details] [diff] [review]). It has to do with window.open(),a nd it was checked into the Aviary branch on 2004-09-07. It's a big and complex patch, and it's beyond my abilities to determine how it is responsible for this crash (if at all). I'll leave a comment on that bug, and hopefully someone will be able to take it from there.

OK - given that this bug was reported on a 20040803 build, my previous comment looks a bit stupid. However, I think this means that we're dealing with more than one bug here. I think there's a Mac-specific bug which started on 20040908, and which was originally reported as bug 258943 (on 20040911), and then there's a non-Mac-specific bug, which started earlier, and was reported here. I'd recommend re-opening bug 258943 (and setting the Platform/OS back to Macintosh/OS X). All of my previous comments on this bug (as well as the testcase), would then apply to that bug. Apologies for all the spam. I think I'll go find something else to do now...

I backed up /home/marty/.mozilla and restarted Firefox with a fresh profile. Neither the Gmail Invite, Gmail Contact Import, nor http://story.news.yahoo.com/news?tmpl=index2&cid=1059 photo-clicking caused a crash (and these were 100% before). In my profile, I had the web developper extension, adblock, and a user agent switcher installed - but these were all removed when I started testing this bug. (Gentoo Linux x86) I'm going to try testing after more surfing/tab use, then add my extensions back one at a time.

Unfortunately I can't reproduce this bug either, neither with Firefox 0.10.1, nor with my SeaMonkey build (both on Windows XP). Looking at the stacktrace it doesn't seem too likely that this problem has been caused by bug 252326, but I'll check it again...

I was finally able to test the 20040907 build (The problem which stopped me from doing this before was bug 258308. I overcame it by asking Firefox not to ask me for a profile on startup). Build 20040907 crashes on the testcase. This rules out my suspicion of bug 252326 (the fix was checked in only after the 20040907 build). Apologies to Wladimir and everyone. Now that I know that the regression was between 20040906 and 20040907, I have a new suspect: bug 22183 (I'm not sure yet which patch was actually checked in at that date. I think it was attachment 157864 [details] [diff] [review]). The fixes for that bug deal directly with the toolbar (which is inline with my comment #46). So I hope I'm not making wrong accusations again.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviaryBranchTinderbox&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-06+08%3A00%3A00&maxdate=2004-09-07+08%3A00%3A00&cvsroot=%2Fcvsroot That should be a list of the changes between those two builds...

I suspect bug 22183 as well. It appears that a bunch of code was checked in originally when the intent was to enforce the location bar. When it was decided to do this by enforcing the statusbar instead most of the location bar change code was left in, although it should not be necessary. In particualr I suspect the code in browser.js which appears to still be in the the branch.

I posted my additional findings, for OS X, in bug 258943 (which was reopened per my recommendation).

More progress. I now know that this bug (or at least its root cause) was present in the code at least since build 20040514 (just before the Aviary branching). I also know that it was fixed on the trunk between the 20040803 and 20040804 (OS X) builds. Given this, I have strong reason to believe that attachment 155070 [details] [diff] [review] to bug 236889 is what fixed the bug on the trunk. How I know this (the long story): Previously I found out that changes made to the chrome on 20040907 were causing this bug to manifest itself consistently on my machine. I figured out I can retrofit older builds with the crash-causing chrome to see if it makes them crah on my testcase. I started by trying this on the 0.9.3 release - and indeed, it crashed as expected. I also needed to verify that the trunk wasn't crashing. I injected the "crashy" branch chrome into a recent trunk build - no crash. Now there were two possibilities - either this regressed on the branch, or was fixed on the trunk. To test this, I took a pre-brach build (20040515), and injected the crashy chrome. It crashed. From here on it was a binary search on the trunk. Seven "download - replace chrome - test" cycles later, I was able to pin-point the fix to between the 20040803 and 20040804 trunk builds. I then ran the following bonsai query: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-08-03+09%3A00%3A00&maxdate=2004-08-04+10%3A00%3A00&cvsroot=%2Fcvsroot and noticed the 236889 fix, which touched, among other things, nsImageBoxFrame - the class in which, according to the stack traces, was where this bug is crashing.

Using the method described above, I was able to reproduce the crash on Firefox 0.8 (20040206) and Firebird 0.7 (20031007). Those versions pretty much choked on the new chrome, but I still managed somehow to try my testcase and crash. I couldn't get Firebird 0.6 to run at all (even with the original chrome), so I left it alone. Bottom line - if this is a regression, it happened before 20031007. As far is I can tell, the bug might have been there, dormant, since the dawn of time, only to be awaken on September 2004 (on OS X, perhaps a bit earlier on Windows) by some innocent-seeming chrome changes. It's a strange coincidence that it was apparenty fixed, on the trunk, one day after the build on which this bug was reported (on the branch). I need to leave my iMac now for a few of days, so you probably won't be hearing from me on this bug soon. I'd like to thank everyone who encouraged me to continue my investigations. I hope my findings will help fixing this bug. And finally, sorry for using this bug a my personal blog for the last couple of days :-)

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041010 Firefox/0.9.1+ Flat screen iMac 10.2.8 The test case does not crash on a build from my tree, but I have added many null pointer checks. I have also tried with a modified test case which requests the 'about:' window (as the test case's pop-ip came up with an empty URL bar - Cmd-U on that page did describe itself as 'Source of about:blank'), and this also worked, but I got these messages in gdb: JavaScript error: chrome://browser/content/browser.js, line 476: isBidiEnabled is not defined WARNING: PresShell::EndLoad(nsIDocument *) RootScrollFrame is not scrollable?, file ../../../../../src/layout/html/base/src/nsPresShell.cpp, line 3547 Is the problem known or suspected to occur with builds from the HEAD? If not, I am probably wasting my time and yours.

This is a list of warnings and assertion failures evinced whilst trying to reproduce this bug. Since the problem (if it is actually in) could be in code a year old or so, I can't really rule any of these out on inspection.

(In reply to comment #69) > Is the problem known or suspected to occur with builds from the HEAD? If not, > I am probably wasting my time and yours. I'm afraid you probably are. Please read the beginning of comment #67.

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Windows XP Not using tab browsing. But problem occurs on a regular basis, not 100% of time though. Sample HTML i am using to open popup <a onClick='javascript:window.open("client_class_detail.php?ClassID=<?PHP echo($classRow["ClassID"]); ?>","","resizable=1,WIDTH=615,HEIGHT=400")' onMouseOver="window.status='See Class Details'; return true" href='#'><?PHP echo($classRow["Name"]); ?></a>

After a fews days use, the dom.disable_window_open_feature.toolbar set to true workaround does prevent prevent firefox from crashing. Thanks for the tip, it should be made the default while the bug hasn't been fixed.

Talked to dbaron about this one, and he does *not* want to land his fix for bug 236889 on the branch, but he'll have a look and see if there's parts of that that could be landed, or if he can see what the problem with nsImageBoxFrame might be here. Thank you Uri for all your great detective work here! :)

The three recent Linux talkback reports that I looked at all have the string file:///usr/lib/firefox/searchplugins/google.gif (in 16-bit characters) on the stack.

The Linux crashes seem to involve crashing on the following code in nsImageBoxFrame::UpdateImage: // otherwise, we need to load the new uri if (mImageRequest) { mImageRequest->Cancel(NS_ERROR_FAILURE); mImageRequest = nsnull; } The nsImageBoxFrame::UpdateImage is not the top frame on the stack, but the second from the top. The current point in that function is the nsCOMPtr_base::assign_with_AddRef call associated with the |mImageRequest = nsnull| line. The top stack frame, however, has led to jumping to some other location and the crash is due to either SIGSEGV or SIGILL, with the EIP usually being 0x09??????, an address that's not inside any shared object.

FWIW, the top of the Linux stack I was looking at is: 0x096c798b nsImageBoxFrame::UpdateImage() [/builds/tinderbox/firefox-0.10.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsImageBoxFrame.cpp, line 607] nsImageBoxFrame::AttributeChanged() [/builds/tinderbox/firefox-0.10.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/xul/base/src/nsImageBoxFrame.cpp, line 266] nsCSSFrameConstructor::AttributeChanged() [/builds/tinderbox/firefox-0.10.1/Linux_2.4.20-28.8_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp, line 10114] Which, like the Windows stacks, has a frame missing, but a different one (UpdateImage vs. UpdateAttributes)

Still having it on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041016 Firefox/1.0

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

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

(In reply to comment #63) > Now that I know that the regression was between 20040906 and 20040907, I have a > new suspect: bug 22183 (I'm not sure yet which patch was actually checked in at > that date. I think it was attachment 157864 [details] [diff] [review]). The fixes for that bug deal > directly with the toolbar (which is inline with my comment #46). So I hope I'm > not making wrong accusations again. Do you know what the hours of the builds are? The checkin you suspect is, I presume, http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-06+16%3A07&maxdate=2004-09-06+16%3A09&cvsroot=%2Fcvsroot However, based on the stack and on comment 75, I think http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-07+07%3A49&maxdate=2004-09-07+07%3A51&cvsroot=%2Fcvsroot may be a possibility.

You're absolutely right. I created a bit of a mess here. My appologies. Right after writing comment #67, bug 258943 was re-opened according to my recommendation (at that point I thought that there was a separate, OS X-specific bug. I no longer believe that now). So my next findings were posted there, form bug 258943 comment 36 onwards (don't bother reading everything before comment 40). In bug 258943 comment 40, I verified that the patch you're pointing to is really the one that started the crashing. Specifically, I believe the problem has to do with the drawing of the icons on the re-designed search bar. Why are these are drawn when the new window is supposed to have the toolbar hidden, is a mystery to me.

In my case [Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1], this happens only after Firefox has eaten up a good amount of memory. At that point, (even if I close all tabs any extra FF windows, no memory is released -- another bug, IMHO) clicking on any javascript link that causes popups of the kind that have been mentioned will cause a crash. Again, above-described crash will not happen for me if Firefox has gobbled up less than, say, 40 MB. I've seen others report that this crash happens only after some time. For me this crash is directly related to the amount of memory the process has allocated rather than the length of time it's been running (although there's usually a positive correlation between running time and memory allocated, since FF for some reason never free()s any substantial amount of memory).

The string on the stack doesn't necessarily correspond to the attribute in question -- it doesn't make sense, and it could be in a piece of uninitialized stack.

(In reply to comment #77) > Which, like the Windows stacks, has a frame missing, but a different one > (UpdateImage vs. UpdateAttributes) The reason the frame is missing is that gcc does tail-call optimization in nsImageBoxFrame::UpdateAttributes (it frees the stack space before calling UpdateImage).

And, FWIW, there's nothing corrupt about the Linux stack at all (at least for incident 1310792). Talkback is just unable to show the top frame correctly because the call instruction crashed, so EIP shows the place (not code) that it called but EBP still points to the beginning of the calling stack frame (since the caller wasn't real code, or whatever, so it didn't save ESP into EBP yet). The stack seems 100% consistent with simply crashing on the Release() call in nsCOMPtr_base::assign_with_AddRef, called from nsImageBoxFrame::UpdateImage, called (via tail call optimization) from nsImageBoxFrame::UpdateAttributes, called from nsImageBoxFrame::AttributeChanged. FWIW, in that incident, the nsCOMPtr's mRawPtr looks like a real heap address (0x09502f90), but its vtable pointer (0x0939b271) does not look like a code address (rather, it looks like a heap address). This makes the underlying problem seem like either a reference counting bug or a memory corruption bug. That it was fixed by bug 236889 makes me suspect the former.

This happens with any popup link on http://www.itsolutions.intuit.com/, such as the ROI calculator link.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 This happens with any popup link on http://www.itsolutions.intuit.com/, such as the ROI calculator link.

I get this also running FFPR under Xandros Desktop v2.0, I did let the Feedback report for the first few days but now it's happening too often so I have disabled the Feedback function. Crash with popups seems to be random, I tried it with popups blocked and permission for one domain and it still crashed when I tried to open a popup on that domain. I've now turned off popup blocking, allow javascript to raise/lower windows and it's still causing random crashes on various sites. No set pattern at all. Is there a file I can find on my box and submit to you to help bugfix this?

So, is anybody who's seeing this on a non-Macintosh platform using the default theme? If not, what theme are you using?

I'm seeing this on FreeBSD with the default theme, and no extensions loaded. I am not alone. Other users are seeing it as well. A good FreeBSD trigger is changing the locale to a value other than en_US. However, users in the en_US locale also encounter this crash periodically with no themes or extensions loaded. One thing's for sure. The workaround of setting dom.disable_window_open_feature.toolbar to true works for everyone.

I've just crashed a firefox 0.10.1 20041001 using the method up there (open all google news headlines, and a yahoo popup), on a clean profile - not even the linky ext to open the headlines. I'm running linux. Too bad the QA wasn't activated, I can try & get it if it is useful.

I am able to reproduce the bug on Mac OS X, and the |primaryFrame| object in nsCSSFrameConstructor::AttributeChanged has all of its member variables marked as 0xdddddddd but the vtable pointer looks ok. That seems bizarre.

So I think the obvious fix here is to set the chromehidden attribute, and perhaps do all the rest of the work that happens in ApplyChromeFlags, a lot earlier. The obvious place that "seems nice" is right after ApplyPersistentAttributes in nsXULDocument::ResumeWalk. It would be nice to do it before StartLayout, I think -- although maybe frames other than the root aren't constructed before StartLayout and doing it in the document observer's EndLoad notification would be fine. I need to figure that out.

This should fix it (I've only tested with the testcase so far, but I'll double check the Mac build shortly). I think what's really keeping this fixed on the trunk is style change coalescing. I suspect that before that landed my list-style-image patch just happened to tweak things in a way that Purify would still have objected to, but that didn't crash -- although I could be wrong about that. (SHOULD INVESTIGATE) I'm not sure whether we really want to depend on style change coalescing to handle this kind of thing, or whether there's some invariant that we should really be maintaining on the trunk. (SHOULD DISCUSS) I think we definitely *do* want to make the setting of chromehidden and those other things happen earlier -- but that could be risky, and we can do it on the trunk. (SHOULD FILE SEPARATE BUG)

Comment on attachment 162810 [details] [diff] [review] low risk patch for branch OK, never mind, this doesn't fix the real crash. (Perhaps the image is already loaded?)

(Although it's possible that it could fix some of the crashes we're seeing in talkback...)

This one is a little harder to fix because there's no new request.

(In reply to comment #97) > Created an attachment (id=162807) > testcase for crash with alerts Are you sure this is the same bug? All new testcases crashes for me even after setting dom.disable_window_open_feature.toolbar to true, which this bug never has done before. (Or am I missing some workaround for that fix?)

(In reply to comment #102) > Are you sure this is the same bug? All new testcases crashes for me even after > setting dom.disable_window_open_feature.toolbar to true, which this bug never > has done before. (Or am I missing some workaround for that fix?) Setting that preference simply makes Firefox's UI stop being a (very complicated) testcase for the underlying XUL bug.

> So, is anybody who's seeing this on a non-Macintosh platform using the default theme? If not, what theme are you using? Windows 2000, default theme, no extensions here.

https://bugzilla.mozilla.org/attachment.cgi?id=162811&action=view This link also crashes the latest nightly (Oct 20) Windows version as well.

Attachment 162811 [details] crashes for me on Windows 2000 Pro SP4 (talkback ID TB1438231G). I've never gotten any of the popup crashes on this machine, FWIW. Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

So I'm trying to make sense of what's going on here in all the noise... the real problem is that the frame code canceling mImageRequest triggers onload, which destroys the frame, then we access members on the frame, right? An added twist is that we end up triggering the style change from UpdateImage() which is ultimately called from AttributeChanged(). So the calls look like: CSSFrameConst::AttributeChanged(src) nsImageBoxFrame::AttributeChanged nsImageBoxFrame::UpdateImage // onload fires, style changes CSSFrameConst::AttributeChanged(style) // frame destroyed ProcessRestyledFrames() (on the already-destroyed frame) I suspect this is what causes the crash even with the "low risk patch for branch", but I'm not sure what the stack for that crash was... For the rest, frames are indeed not created till StartLayout() is called. So possible solutions are: 1) Prevent onload from firing while we're in nsCSSFrameConstructor::AttributeChanged by tossing a dummy layout request into the loadgroup. 2) Do UpdateImage() off a PLEvent. On trunk, I bet we could achieve the same effect by removing the node from the document in onload instead of just setting it to display:none, since that will cause sync frame destruction. So we probably need to do something about this on the trunk too.

3) set chromehidden at a reasonable time (would work for the branch, although we'd still want to fix the underlying bug)

An issue darin pointed out about using a dummy request for onload prevention in cases like this is that somebody could change document.location() to cancel the loadgroup. (Although I guess that hopefully wouldn't fire onload.) Anyway, this is a plevent patch. I'll test the Mac shortly, but it fixes both testcases.

Comment on attachment 162906 [details] [diff] [review] plevent patch for branch Yeah, this does really fix the crash on the Mac.

Hrm, but it really doesn't do the right things with onerror notifications and anything else that the listener cares about...

Comment on attachment 162946 [details] [diff] [review] plevent patch for branch So this still changes our behavior regarding onerror, but I don't think it's that serious, and this version is a little more consistent than the previous patch about it.

Comment on attachment 162948 [details] [diff] [review] plevent patch for branch sr=darin assuming bz is happy. we should file a bug on the fact that it isn't possible to tell if we should call PL_DestroyEvent when PL_PostEvent fails.

Comment on attachment 162949 [details] [diff] [review] plevent patch for branch Calling DisconnectListener() drops the ref to it, but the problem is that image requests hold a weak ref to the listener. See http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/public/imgILoader.idl#7 9 So this patch, as written, could cause the imgRequest to make a call on a deleted listener (say if the frame is animated and we animate the next frame before the cancellation event fires). We need to make the event hold a ref to the listener too and release the listeners only after it has cancelled the requests. r-, based on that.

I think this addresses bz's comments.

Comment on attachment 162984 [details] [diff] [review] plevent patch for branch Yes, this works. r=bzbarsky.

no longer crashes on 20041022.

Comment on attachment 162984 [details] [diff] [review] plevent patch for branch sr=darin good catch, bz!

Comment on attachment 162984 [details] [diff] [review] plevent patch for branch a=asa for aviary checkin.

Fix checked in to AVIARY_1_0_20040515_BRANCH, 2004-10-22 13:41 -0700. Fix checked in to MOZILLA_1_7_BRANCH, 2004-10-22 13:44 -0700. (While I was there, I noticed nsContentUtils::CanLoadImage returns a boolean on the former branch and an nsresult on the latter branch. That seems highly dangerous.)

(In reply to comment #123) > (While I was there, I noticed nsContentUtils::CanLoadImage returns a boolean on > the former branch and an nsresult on the latter branch. That seems highly > dangerous.) Yeah, that already bit me (luckily I caught it before checking in what I was working on). But I don't think we want to change that now...

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

I've been experiencing the same issue: any javascript pop-up would cause my Firefox browser to crash. Mac OS X 10.3.5, Firefox 1.0PR. The interesting thing is that it seemed dependent on how many open tabs I had -- if there were only three or four tabs open, the pop-up would come up. But if I had about a dozen tabs open like I normally do, javascript pop-ups would crash Firefox every time. Well, tonight I downloaded 1.0RC1 to replace 1.0PR -- and the problem is completely gone. I can open up fifteen browser tabs, then click on one javascript pop-up link after another. All the pop-ups come up properly with nary a crash. Congratulations, developers -- I think you're nailed this bug.

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

I am no longer crashing with the testcases in this bug and in Talkback data using the latest Firefox 1.0 RC1 release, so looks like the crash is gone. Are we leaving this open for some more work or should we mark this fixed?

It's not fixed on the trunk.

Can we set 'Firefox 1.1' as the target for this bug ? I'm asking this, because there's no 'blocking-aviary1.1' flag or something similar. Sorry for the bugspam.

Setting targets is something for the developers to do, and there's no need for bug spam to point it out to them. If it doesn't get fixed by the time that 1.1 is imminent (in a few months), that would be the time for others to worry about it (with a blocking nomination I would guess). I'll set version to trunk though.

I'm not able to reproduce a crash with any of the test cases on recent trunk builds wfm

(In reply to comment #132) > I'm not able to reproduce a crash with any of the test cases on recent trunk builds > > wfm The patch was never checked in to the trunk. The original testcase does't crash the trunk because the underlying bug was obfuscated by some unrelated JS changes made on the trunk. David Baron's testcase doesn't crash recent trunk builds for me either, but I'm still a bit worried that the underlying bug wasn't really fixed, and might be exposed again at some point in the future. I would recommend keeping the bug open until David Baron verifies that the root cause of it had indeed been fixed.

I filed bug 279171 as a followup, although we may need an additional followup bug as well.

I got this same error with v3.52 of firefox. As soon as I goto a page with working java it crashes.No workaround so I deleted everything and tried to re-install, same results. I am now working with v3.0.10. Works fine. Waiting for this issue to be resolved.