513318 - visibility:collapse causes scrollbar issues for XUL elements

Status: RESOLVED FIXED

(Core :: Layout, defect, P1)

Description

[Jim Porter (:squib)]

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.

Comment 1

[Jim Porter (:squib)]

Attachment: Minimal test case

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

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 4

[Nochum Sossonko [:Natch]]

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

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 6

[Mats Palmgren (inactive)]

Sure, I'll have a look...

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 8

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

Comment 9

[David Ascher (:davida)]

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 10

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/mozilla-central/rev/1c26852f7b77

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 400051 [details] [diff] [review]
Patch rev. 1

a1.9.2=dbaron

Comment 12

[David Ascher (:davida)]

Please checkin to 1.9.2.

Comment 13

[Mats Palmgren (inactive)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5e61cfb96d1b

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 400051 [details] [diff] [review]
Patch rev. 1

Approved for 1.9.1.4, a=dveditz

Comment 15

[Mats Palmgren (inactive)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2aefb5d57f96

Comment 16

[Mark Banner (:standard8)]

Thanks Mats :-)

Comment 17

[Al Billings [:abillings - ex-MoCo]]

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.