90276 - sizeToContent does not play nice with windows whose dimensions are persisted

Status: NEW

(Core :: XUL, defect)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 1

[Viswanath Ramachandran]

nominating, getting on XPToolkit radar. 

Comment 2

[Dan M]

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

Comment 3

[John Morrison]

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

Comment 4

[Hong Kwon]

propagating nsenterprise+ from 94755

Comment 5

[Jaime Rodriguez, Jr.]

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

Comment 6

[Hong Kwon]

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

Comment 7

[Jaime Rodriguez, Jr.]

not a stop ship at this point = PDT-

Comment 8

[Gérard Talbot]

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.

Comment 9

[[e-mail]]

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

Comment 10

[Pierre Chanial]

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.

Comment 11

[Sam Katz]

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.