Last Comment Bug 322701 - When opening Options dialog second time Options window is empty
: When opening Options dialog second time Options window is empty
Status: VERIFIED FIXED
[rft-dl]
: regression, smoketest, verified1.8.0.2, verified1.8.1
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: P1 blocker with 1 vote (vote)
: mozilla1.9alpha1
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
: Neil Deakin
Mentors:
: 322706 323323 (view as bug list)
Depends on:
Blocks: 319463
  Show dependency treegraph
 
Reported: 2006-01-07 14:21 PST by Nikola Kocić (Kole89)
Modified: 2008-07-31 14:17 PDT (History)
26 users (show)
dbaron: blocking1.9a1+
bzbarsky: blocking1.8.1+
dveditz: blocking1.8.0.2+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Fix for the reentry problem (5.40 KB, patch)
2006-01-11 21:49 PST, Boris Zbarsky [:bz] (still a bit busy)
bugs: review+
dbaron: superreview+
dbaron: approval‑branch‑1.8.1+
dveditz: approval1.8.0.2+
Details | Diff | Splinter Review

Description Nikola Kocić (Kole89) 2006-01-07 14:21:55 PST
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.
Comment 1 Peter van der Woude [:Peter6] 2006-01-07 15:14:03 PST
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060107 Firefox/1.6a1 ID:2006010712

Confirmed
Comment 2 JConley 2006-01-07 15:16:30 PST
*** Bug 322706 has been marked as a duplicate of this bug. ***
Comment 3 JConley 2006-01-07 15:18:03 PST
Works in 20060106-06 trunk
Comment 5 Doron Rosenberg (IBM) 2006-01-07 16:50:08 PST
cc:ben,bz

I only checked in :)
Comment 6 Francesco Castellana 2006-01-08 03:12:33 PST
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...
Comment 7 philippe (part-time) 2006-01-08 04:05:24 PST
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
Comment 8 Nikola Kocić (Kole89) 2006-01-08 08:54:36 PST
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
Comment 9 Michael Mak 2006-01-08 09:45:49 PST
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
Comment 10 Doron Rosenberg (IBM) 2006-01-08 12:48:58 PST
We really don't need any more "me too" comments :)
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2006-01-08 16:18:58 PST
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.
Comment 12 Dave Townsend [:mossop] 2006-01-10 14:46:38 PST
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.

Comment 13 David Baron :dbaron: ⌚️UTC-10 2006-01-11 16:59:11 PST
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
Comment 14 David Baron :dbaron: ⌚️UTC-10 2006-01-11 17:28:41 PST
This was caused by bug 319463 -- I confirmed by local backout.
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2006-01-11 21:35:33 PST
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.
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2006-01-11 21:49:39 PST
Created attachment 208245 [details] [diff] [review]
Fix for the reentry problem

This fixes this bug for me...
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2006-01-13 21:30:46 PST
Fixed on trunk.
Comment 18 Boris Zbarsky [:bz] (still a bit busy) 2006-01-13 21:31:39 PST
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.
Comment 19 Elmar Ludwig 2006-01-14 00:33:20 PST
*** Bug 323323 has been marked as a duplicate of this bug. ***
Comment 20 Ben Goodger (use ben at mozilla dot org for email) 2006-01-24 10:12:09 PST
Comment on attachment 208245 [details] [diff] [review]
Fix for the reentry problem

r=ben@mozilla.org
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2006-01-30 13:59:29 PST
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 22 David Baron :dbaron: ⌚️UTC-10 2006-01-31 22:39:08 PST
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.
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2006-02-01 14:00:12 PST
Fixed on 1.8.1 branch
Comment 24 Daniel Veditz [:dveditz] 2006-02-14 15:54:44 PST
Comment on attachment 208245 [details] [diff] [review]
Fix for the reentry problem

approved for 1.8.0 branch, a=dveditz for drivers
Comment 25 Boris Zbarsky [:bz] (still a bit busy) 2006-02-14 18:48:00 PST
Fixed for 1.8.0.2
Comment 26 Tracy Walker [:tracy] 2006-02-27 14:38:57 PST
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
Comment 27 Tracy Walker [:tracy] 2006-08-22 08:20:04 PDT
verified with 2.0b2 builds from 0821

Note You need to log in before you can comment on or make changes to this bug.