Based on my perusal of the code in nsXULWindow, it seems that before a window is displayed, it can potentially be sized by the following two means: - a call to sizeToContent(); in the window's load handler - persisted dimensions from RDF. I have a window that is attempting to use both of these sizing measures (the sidebar customize dialog). 1) sizeToContent is called to ensure that the window is not created with UI elements that are not visible, i.e. that the window is always large enough to accommodate its controls. 2) persistence is used to remember the size of the window. What I think should happen: - if the size selected via persisted data is smaller than the actual size of the data, the persisted data should be ignored and the window sized purely based on the actual dimensions of the content. - otherwise, the size of the window should be the size stored in the persistent data store. What happens now: - something odd, and hard to explain, and I'm fingering you dan, as the defacto owner of this code now that the other person chiefly blamed for it has left ;) The Sidebar customize dialog appears to increase in size with each launch, as if the dual resizing (sizeToContent, persistent size) is causing growth. Caveats: - calling sizeToContent could just be a waste of time. perhaps what we really need is a CSS min-width/height property that works, so that the user could never place him or herself into such a predicament in the first place.

nominating, getting on XPToolkit radar.

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

May God have mercy on us all. The 212 bug spam-o-rama is Now!

propagating nsenterprise+ from 94755

Dan/Peter - This not targeted, but has an nsenterprise+ keyowrd. Will this be fixed this week?

nsenterprise- for now; if you have a fix by friday, we will consider.

not a stop ship at this point = PDT-

I confirm that the sidebar customize dialog increases in size (both width and height) with each launch. XP Pro SP1 with Moz 1.2.1 (20021130). This behavior may also happen with subwindows... not sure. I created a sub-window with window.open() and this subwindow has an onresize event listener function which calls the sizeToContent() method. The strange thing is that this sub-window keeps changing sizes (width and height) of a few pixels all the time. The window looks like a heart pumping all the time. This happens in Phoenix 0.4 and Phoenix 0.5 (rv:1.3a) Gecko/20021207 and in K-Meleon 0.7 under XP Pro SP1. Testcase available if needed.

The sizes that are persisted onto the root element are the outer dimensions of the window, but unfortunately sizeToContent assumes that they are the inner dimensions of the window and inflates them appropriately. In my case my OS chrome dimensions are 4 pixels for borders and 19 pixels for the title so my customize tabs window increases by 9x27 pixels every time I open it. (The 9th pixel is added by sizeToContent to compensate for alleged rounding errors.) One workaround is to follow the lead taken by the file bookmark dialog :-)

If I understand what this bug is about, it is now manifesting itself in a very visible way in Firebird's add bookmark dialog: just expand/collapse the folder tree, and the width of the dialog increase regularly.

While I see the original design in the aforementioned bug 214527.. I also see Pierre later down say, "I just have to hook up the new folder stuff and tidy it [the dialog] up a bit." Let's not forget the "legislative" direction of a core member (Ben), but let us interpret its intent according to firebird's mission. We need to either leave this open with a helpwanted keyword, (in which case I would consider trying to fix it--I know no XUL..), or we need to mark the bug as WONTFIX and reopen it if we decide to add new folder functionality to the bookmark dialog.