255372 - FF10PR1 Crash with any javascript popup window (window.open) [@ 0x00000000 - nsCOMPtr_base::assign_with_AddRef ]

Status: RESOLVED WORKSFORME

Description

[Alex]

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.

Comment 1

[Adam Hauner]

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

Comment 2

[Alex]

(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

Comment 3

[Adam Hauner]

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

Comment 4

[Alex]

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

Comment 5

[Adam Hauner]

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

Comment 6

[Alex]

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

Comment 7

[Alex]

I have downgrade to 0.9
and now there's no problem at all

But i'd like to use the latest stable one :)

Comment 8

[Jay Patel [:jay]]

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.

Comment 9

[Nathan Strom]

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.

Comment 10

[Brian Ryner (not reading)]

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...

Comment 11

[rom16384]

(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.

Comment 12

[Jo Hermans]

(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 ?

Comment 13

[Jo Hermans]

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

Comment 14

[chris hofmann]

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

Comment 15

[:Gavin Sharp [email: [e-mail]]]

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

Comment 16

[Jo Hermans]

(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 ?

Comment 17

[Uri Bernstein (Google)]

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.

Comment 18

[Mailer Key]

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

Comment 19

[Jay Patel [:jay]]

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. 

Comment 20

[Uri Bernstein (Google)]

Created attachment 160808 [details]
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.

Comment 21

[Ryuichi KUBUKI]

(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

Comment 22

[Vibhor Chowdhary]

(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.

Comment 23

[Mailer Key]

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

Comment 24

[Ryuichi KUBUKI]

(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.

Comment 25

[Floyd Miller]

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.

Comment 26

[Uri Bernstein (Google)]

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.

Comment 27

[Vibhor Chowdhary]

(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.

Comment 28

[Floyd Miller]

In reply to [e-mail]:

  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.

Comment 29

[Prem Vilas Fortran Rara]

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

Comment 30

[Mario Wittmann]

(In reply to comment #28)
> In reply to [e-mail]:
>
>   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.

Comment 31

[Joel Nelson (don't send email)]

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

Comment 32

[Joel Nelson (don't send email)]

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

Comment 33

[Prem Vilas Fortran Rara]

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

Comment 34

[Prem Vilas Fortran Rara]

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

Comment 35

[Nathan Strom]

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

Comment 36

[Matt]

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.

Comment 37

[Paul Shuttle]

Matt, let's try and keep things civil.

Comment 38

[Paul Shuttle]

Matt, let's try and keep things civil.

Comment 39

[Ryuichi KUBUKI]

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

Comment 40

[Paul Wright]

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.

Comment 41

[Vibhor Chowdhary]

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

Comment 42

[Gummi]

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.

Comment 43

[Martin Glaude]

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 [e-mail] for gmail invites for testing.  Hopefully
someone more skilled that me can use this to construct a test case.

Comment 44

[Joel Nelson (don't send email)]

(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.

Comment 45

[Thom May]

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.

Comment 46

[Uri Bernstein (Google)]

(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.

Comment 47

[Uri Bernstein (Google)]

What I meant to write is:

If "toolbar" is specified (or no featureset is specified) there is no crash.

Sorry for the spam.

Comment 48

[Johnny Stenback (:jst)]

(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...

Comment 49

[Dan Karlsson]

(In reply to comment #30)
> (In reply to comment #28)
> > In reply to [e-mail]:
> >
> >   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)

Comment 50

[Marcia Knous [:marcia - use ni]]

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.

Comment 51

[Dan Karlsson]

(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.

Comment 52

[Mario Wittmann]

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. :-)

Comment 53

[Floyd Miller]

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.

Comment 54

[Bill Gianopoulos [:WG9s]]

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.

Comment 55

[Uri Bernstein (Google)]

> 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).

Comment 56

[Uri Bernstein (Google)]

(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.

Comment 57

[Uri Bernstein (Google)]

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

Comment 58

[Uri Bernstein (Google)]

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.

Comment 59

[Uri Bernstein (Google)]

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.

Comment 60

[Uri Bernstein (Google)]

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...

Comment 61

[Martin Glaude]

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.

Comment 62

[Wladimir Palant (for Adblock Plus info Cc [e-mail])]

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...

Comment 63

[Uri Bernstein (Google)]

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.

Comment 64

[Johnny Stenback (:jst)]

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...

Comment 65

[Bill Gianopoulos [:WG9s]]

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.

Comment 66

[Uri Bernstein (Google)]

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

Comment 67

[Uri Bernstein (Google)]

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.

Comment 68

[Uri Bernstein (Google)]

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 :-)

Comment 69

[Ben Fowler]

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.

Comment 70

[Ben Fowler]

Created attachment 161667 [details]
Warnings and Assertion failures

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.

Comment 71

[Uri Bernstein (Google)]

(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.

Comment 72

[Mike]

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>

Comment 73

[Gummi]

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.

Comment 74

[Johnny Stenback (:jst)]

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! :)

Comment 75

[David Baron :dbaron: ⌚️UTC-8]

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.

Comment 76

[David Baron :dbaron: ⌚️UTC-8]

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.

Comment 77

[David Baron :dbaron: ⌚️UTC-8]

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)

Comment 78

[Ryuichi KUBUKI]

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

Comment 79

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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

Comment 80

[:Gavin Sharp [email: [e-mail]]]

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

Comment 81

[David Baron :dbaron: ⌚️UTC-8]

(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.

Comment 82

[Uri Bernstein (Google)]

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. 

Comment 83

[Chimpy McFlightsuit]

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).

Comment 84

[David Baron :dbaron: ⌚️UTC-8]

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.

Comment 85

[David Baron :dbaron: ⌚️UTC-8]

(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).

Comment 86

[David Baron :dbaron: ⌚️UTC-8]

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.

Comment 87

[Todd Baur]

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

Comment 88

[Todd Baur]

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. 

Comment 89

[Anne Nichols]

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?

Comment 90

[David Baron :dbaron: ⌚️UTC-8]

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

Comment 91

[Joe Marcus Clarke]

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.

Comment 92

[Gummi]

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.

Comment 93

[David Baron :dbaron: ⌚️UTC-8]

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.

Comment 94

[David Baron :dbaron: ⌚️UTC-8]

Created attachment 162773 [details]
stack showing the real problem

Comment 95

[David Baron :dbaron: ⌚️UTC-8]

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.

Comment 96

[David Baron :dbaron: ⌚️UTC-8]

Created attachment 162806 [details]
simplified testcase for crash

Comment 97

[David Baron :dbaron: ⌚️UTC-8]

Created attachment 162807 [details]
testcase for crash with alerts

Comment 98

[David Baron :dbaron: ⌚️UTC-8]

Created attachment 162810 [details] [diff] [review]
low risk patch for branch

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 99

[David Baron :dbaron: ⌚️UTC-8]

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?)

Comment 100

[David Baron :dbaron: ⌚️UTC-8]

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

Comment 101

[David Baron :dbaron: ⌚️UTC-8]

Created attachment 162811 [details]
simplified testcase for crash

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

Comment 102

[Dan Karlsson]

(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?)

Comment 103

[David Baron :dbaron: ⌚️UTC-8]

(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.

Comment 104

[Stefan Ring]

> 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.

Comment 105

[Greg Tiller]

https://bugzilla.mozilla.org/attachment.cgi?id=162811&action=view

This link also crashes the latest nightly (Oct 20) Windows version as well.

Comment 106

[Nathan Strom]

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

Comment 107

[Boris Zbarsky [:bz] (no decent commit message means r-)]

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.

Comment 108

[David Baron :dbaron: ⌚️UTC-8]

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

Comment 109

[David Baron :dbaron: ⌚️UTC-8]

Created attachment 162906 [details] [diff] [review]
plevent patch for branch

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 110

[David Baron :dbaron: ⌚️UTC-8]

Comment on attachment 162906 [details] [diff] [review]
plevent patch for branch

Yeah, this does really fix the crash on the Mac.

Comment 111

[David Baron :dbaron: ⌚️UTC-8]

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

Comment 112

[David Baron :dbaron: ⌚️UTC-8]

Created attachment 162946 [details] [diff] [review]
plevent patch for branch

Comment 113

[David Baron :dbaron: ⌚️UTC-8]

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 114

[David Baron :dbaron: ⌚️UTC-8]

Created attachment 162948 [details] [diff] [review]
plevent patch for branch

Comment 115

[Darin Fisher]

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 116

[David Baron :dbaron: ⌚️UTC-8]

Created attachment 162949 [details] [diff] [review]
plevent patch for branch

Comment 117

[Boris Zbarsky [:bz] (no decent commit message means r-)]

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.

Comment 118

[David Baron :dbaron: ⌚️UTC-8]

Created attachment 162984 [details] [diff] [review]
plevent patch for branch

I think this addresses bz's comments.

Comment 119

[Boris Zbarsky [:bz] (no decent commit message means r-)]

Comment on attachment 162984 [details] [diff] [review]
plevent patch for branch

Yes, this works.  r=bzbarsky.

Comment 120

[Hussam Al-Tayeb]

no longer crashes on 20041022.

Comment 121

[Darin Fisher]

Comment on attachment 162984 [details] [diff] [review]
plevent patch for branch

sr=darin

good catch, bz!

Comment 122

[Asa Dotzler [:asa]]

Comment on attachment 162984 [details] [diff] [review]
plevent patch for branch

a=asa for aviary checkin.

Comment 123

[David Baron :dbaron: ⌚️UTC-8]

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.)

Comment 124

[Johnny Stenback (:jst)]

(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...

Comment 125

[:Gavin Sharp [email: [e-mail]]]

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

Comment 126

[Robin Munn]

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.

Comment 127

[Uri Bernstein (Google)]

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

Comment 128

[Jay Patel [:jay]]

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?

Comment 129

[David Baron :dbaron: ⌚️UTC-8]

It's not fixed on the trunk.

Comment 130

[Jo Hermans]

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.

Comment 131

[Michael Lefevre]

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.

Comment 132

[Tracy Walker [:tracy]]

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

wfm

Comment 133

[Uri Bernstein (Google)]

(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. 

Comment 134

[David Baron :dbaron: ⌚️UTC-8]

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

Comment 135

[Allen]

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.