User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060107 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060107 Firefox/1.6a1 When opening Options dialog second time Options window is empty Reproducible: Always Steps to Reproduce: 1.Open Options dialog from Tools-Options 2.Press "OK" button 3.Open Tools-Options again Actual Results: Dialog is empty. Expected Results: Dialog should be same as when opened first time.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060107 Firefox/1.6a1 ID:2006010712 Confirmed

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

Works in 20060106-06 trunk

works in 20060106 1551pst build fails in 20060106 1653pst build http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=20060106+1520&maxdate=20060106+1641&cvsroot=%2Fcvsroot regressed from Bug 319463 ?

cc:ben,bz I only checked in :)

Confirming on Linux, too, with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060107 Firefox/1.6a1 Maybe OS should be changed to All Of course on Linux this refers to Edit > Preferences...

Confirmed on Mac OS X (10.4.3) Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060107 Firefox/1.6a1 ID:2006010705

Same happens in Thunderbird - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060108 Thunderbird/1.6a1 ID:2006010806

Also happens in the new Firefox trunk nightly Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060108 Firefox/1.6a1 ID:2006010806

We really don't need any more "me too" comments :)

I won't be able to look into this in the foreseeable future (probably ever). Someone who's actually interested in this stuff should step through and see what's going on.

A couple of quick tests. I have two extensions that use the prefwindow widget and only one is affected by this bug. The difference is that one has all the prefpanes hardcoded in, the broken one uses the dynamic overlays in the same way as the firefox options does. Having investigated with DOMi, the dynamic overlay is getting loaded into the document for the blank options, but for some reason the box holding the pane is staying at 0 size, as is all its content.

I see numerous assertions when this happens: ###!!! ASSERTION: initial containing block already created: 'nsnull == mInitialContainingBlock', file /builds/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 9220 ###!!! ASSERTION: Popup set is already defined! Only 1 allowed.: 'Not Reached', file /builds/trunk/mozilla/layout/xul/base/src/nsRootBoxFrame.cpp, line 270 ###!!! ASSERTION: no common ancestor at all???: 'parent', file /builds/trunk/mozilla/layout/base/nsLayoutUtils.cpp, line 293 ###!!! ASSERTION: node in map twice: 'Not Reached', file /builds/trunk/mozilla/layout/base/nsFrameManager.cpp, line 1633 ###!!! ASSERTION: node in map twice: 'Not Reached', file /builds/trunk/mozilla/layout/base/nsFrameManager.cpp, line 1633 ###!!! ASSERTION: node in map twice: 'Not Reached', file /builds/trunk/mozilla/layout/base/nsFrameManager.cpp, line 1633 ###!!! ASSERTION: node in map twice: 'Not Reached', file /builds/trunk/mozilla/layout/base/nsFrameManager.cpp, line 1633 ###!!! ASSERTION: node in map twice: 'Not Reached', file /builds/trunk/mozilla/layout/base/nsFrameManager.cpp, line 1633 ###!!! ASSERTION: unexpected second call to SetInitialChildList: 'Not Reached', file /builds/trunk/mozilla/layout/generic/nsContainerFrame.cpp, line 108 ###!!! ASSERTION: Found more undisplayed content data after removal: 'context == nsnull', file /builds/trunk/mozilla/layout/base/nsFrameManager.cpp, line 628

This was caused by bug 319463 -- I confirmed by local backout.

Ah, wonderful. The stack to the assert dbaron sees is (I snipped some irrelevant stuff): #1 0xb539120e in PresShell::InitialReflow (this=0x8c5ae00, aWidth=15, aHeight=15) at ../../../mozilla/layout/base/nsPresShell.cpp:2724 #2 0xb57e925b in nsXULDocument::StartLayout (this=0x8ada6a8) at ../../../../../mozilla/content/xul/document/src/nsXULDocument.cpp:2044 #3 0xb57ecb8a in nsXULDocument::ResumeWalk (this=0x8ada6a8) at ../../../../../mozilla/content/xul/document/src/nsXULDocument.cpp:2964 #4 0xb57ebbbc in nsXULDocument::LoadOverlayInternal (this=0x8ada6a8, aURI=0x8bdb8f8, aIsDynamic=1, aShouldReturn=0xbfffcfc0, aFailureFromContent=0xbfffcfbc) at ../../../../../mozilla/content/xul/document/src/nsXULDocument.cpp:2660 #5 0xb57eb761 in nsXULDocument::LoadOverlay (this=0x8ada6a8, aURL=@0x8adad68, aObserver=0x8adad80) at ../../../../../mozilla/content/xul/document/src/nsXULDocument.cpp:2558 #6 0xb7e946d9 in XPTC_InvokeByIndex () at ../../../../../../../mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:69 ........ #15 0xb7eec2f7 in JS_CallFunctionValue (cx=0x8c5c3e0, obj=0x851b5f8, fval=139717128, argc=0, argv=0x0, rval=0xbfffe5b8) at ../../../mozilla/js/src/jsapi.c:4157 #16 0xb57b46f5 in nsXBLProtoImplAnonymousMethod::Execute (this=0x8acb3e0, aBoundElement=0x89fef10) at ../../../../mozilla/content/xbl/src/nsXBLProtoImplMethod.cpp:339 #17 0xb57a74b8 in nsXBLPrototypeBinding::BindingAttached (this=0x8ac98e0, aBoundElement=0x89fef10) at ../../../../mozilla/content/xbl/src/nsXBLPrototypeBinding.cpp:389 #18 0xb57a47e2 in nsXBLBinding::ExecuteAttachedHandler (this=0x8c668d8) at ../../../../mozilla/content/xbl/src/nsXBLBinding.cpp:784 #19 0xb57c5346 in nsBindingManager::ProcessAttachedQueue (this=0x8a5c868) at ../../../../mozilla/content/xbl/src/nsBindingManager.cpp:799 #20 0xb533c260 in nsCSSFrameConstructor::ContentInserted (this=0x8c5e300, aContainer=0x0, aChild=0x89fef10, aIndexInContainer=0, aFrameState=0x0, aInReinsertContent=0) at ../../../mozilla/layout/base/nsCSSFrameConstructor.cpp:9257 #21 0xb539120e in PresShell::InitialReflow (this=0x8c5ae00, aWidth=15, aHeight=15) at ../../../mozilla/layout/base/nsPresShell.cpp:2724 #22 0xb57e925b in nsXULDocument::StartLayout (this=0x8ada6a8) at ../../../../../mozilla/content/xul/document/src/nsXULDocument.cpp:2044 So we're reentering initial reflow. That's really not cool.

This fixes this bug for me...

Fixed on trunk.

Comment on attachment 208245 [details] [diff] [review] Fix for the reentry problem Requesting 1.8.1 approval like bug 319463 and 1.8.0.2 approval for when that one gets approval to go onto the 1.8.0.x branch.

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

Comment on attachment 208245 [details] [diff] [review] Fix for the reentry problem r=ben@mozilla.org

Comment on attachment 208245 [details] [diff] [review] Fix for the reentry problem This needs to go on branch if bug 319463 is going to...

Comment on attachment 208245 [details] [diff] [review] Fix for the reentry problem Perfectly happy taking this on the branch if we take what caused the regression. Don't take my branch-1.8.1+ as an opinion either way on that patch; I've forgotten what it was.

Fixed on 1.8.1 branch

Comment on attachment 208245 [details] [diff] [review] Fix for the reentry problem approved for 1.8.0 branch, a=dveditz for drivers

Fixed for 1.8.0.2

Verified with Firefox 1.5.0.2 builds from: Win 2006-02-27-06-mozilla1.8.0 Mac 2006-02-27-05-mozilla1.8.0 Lin 2006-02-27-05-mozilla1.8.0

verified with 2.0b2 builds from 0821