User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.13) Gecko/2009080316 Ubuntu/8.04 (hardy) Firefox/3.0.13 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090826 Shredder/3.0b4pre Under normal circumstances, applying the CSS "visibility:collapse;" to a XUL element is functionally equivalent to "display:none;". However, under certain circumstances, the element still contributes to the height of the document for the purposes of scrolling. This also applies to setting the attribute "collapsed" to true. This only seems to happen when an element that wraps text is contained within an hbox, e.g.: <hbox> <label> stuff </label> </hbox> What's more, any elements within the label shown above will be laid out vertically for the purposes of calculating the object's height. This error doesn't occur with inner elements that don't wrap (e.g. <hbox><hbox>stuff</hbox></hbox> wouldn't cause this). Additionally, XBL elements inside the label do *not* contribute to the object's height. They work as you'd expect. Finally, none of this actually affects the layout of elements in the document, only the overall dimensions of the document/containing element. Reproducible: Always Steps to Reproduce: 1. Construct a XUL document like in the attachment Actual Results: A scrollbar appears when the visibility is set to "collapsed". Expected Results: No scrollbar.

A test case showing the error in action, because a picture is worth 1000 words.

I just talked to roc; he mentioned that he might have time to take a look at this in about a week, so I'm going to ping him then.

I'm seeing this on the testcase here, and I also experienced this in the duped bug. Confirmed.

So pretty clearly we're reflowing the contents and not forcing the children's size and position to 0,0, which adds the contents to the overflow area for the frame. I think we need to just set the overflow area of visibility:collapsed XUL elements to empty. Mats, can you take this?

Sure, I'll have a look...

For consideration when prioritizing, it would be super helpful if we could get this before Thunderbird 3 ships (currently expected to be early November or sooner) on the 1.9.1 branch.

FYI, i tested Shredder w/ attachment 400051 [details] [diff] [review] applied, and it totally fixed the problem we're seeing. I'm eagerly awaiting it (on 1.9.1).

Comment on attachment 400051 [details] [diff] [review] Patch rev. 1 a1.9.2=dbaron

Please checkin to 1.9.2.

Comment on attachment 400051 [details] [diff] [review] Patch rev. 1 Approved for 1.9.1.4, a=dveditz

Thanks Mats :-)

Verified for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090929 Shiretoko/3.5.4pre using attached testcase.