36628 - Using "visibility: collapse" to expand/collapse a portion of a dialog doesn't work

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Charles Manske]

Load the attached test file (comming soon) into the browser.
Click on the "Fewer" button. It will resize so the right and bottom edges
stretch out to the entire screen rather than hiding to content in the 
box around the 2 lists (tree elements) and resizing smaller, as it should.
The button text changes to "More". Click on that and size will return to
what is the 'expanded' state.

Comment 1

[Charles Manske]

Attachment: Test file for "collapse" attribute

Comment 2

[Charles Manske]

When we use "visibility: collapse" in a real dialog, such as the Composer's
Image Properties dialog, we crash.

Comment 3

[Steve Lamm]

visibility: collapsed use to work in the sidebar, and it doesn't anymore.
Marking a regression.

Comment 4

[andreww]

ack - we use visibility collapse in AIM in the toolbar also.

Comment 5

[Eric Vaughan]

Hmmm. The enclosed example does not crash. I ran though all my collapse 
regression tests and they all pass. Anyone have a simple example the does not 
work?

Comment 6

[Peter Trudelle]

Why is this marked a smoketest blocker? Are there steps to reproduce the crash
using just the current build?  Is work on such a dialog blocked by this?  Is
being able to collapse the sidebar somehow critical to our development effort? I
don't see why we'd keep the tree closed for this.  Should it be resolved as wfm?

Comment 7

[Charles Manske]

I don't think this is a smoketest issue.
Unfortunately, a "simple" example won't work. I guess there's an accumlated
effect of complex contents inside the box we are trying to expand/collapse.
Check the image dialog in Composer: It no longer crashes, but it doesn't 
collapse -- the right and bottom sides expands to full screen instead.
I have simpler dialogs that I can change to using "visibility:collapse" instead
of "display:none" that might be better tests.

Comment 8

[John Morrison]

per cmanske above, removing smoketest keyword -- I'll look at this again
(but as noted, visibility: collapse does work in basic examples.) Also, I 
have not crashed using the testcase above.

Comment 9

[Charles Manske]

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

Comment 10

[John Morrison]

Okay: what I can reproduce is that (apparently) setting/removing
the 'collapsed' attribute from a xul:box does not collapsed its
contents when that xul:box is contained in a titledbox.

However, this does work when the box is *not* contained in a titledbox.

In addition, I have not come up with a scenario where altering the 
CSS visiblity property of the style attribute fails to collapse the 
contents of a xul:box. Any other examples/XUL snippets to reproduce?

(Note: I am leaving aside (for now) any sizeToContent() weirdness that results
when the box fails to collapse (i.e., wrong size result, odd clipping))

Will attach testcase in one moment (and it is type 'text/xul' so you 
can just load the URL directly into mozilla).

Comment 11

[John Morrison]

Attachment: testcase; xul:box attribute 'collapsed' fails inside titledbox

Comment 12

[John Morrison]

Well, duh! I was running the wrong build --- apr28 win95 -- so my comments above 
apply to that build (there's still a problem). 

However, using may02 win95, I see that setting/removing the collapsed attribute 
on xul:box does not work, whether it is contained in a titledbox or not.

Changing the CSS 'visibility: collapse' does work in this example for the 
current build, though.

Comment 13

[Steve Lamm]

When I run the example in viewer, only the last one works, "using the CSS
visibility property inside a titlebox." However, if I load it up in mozilla,
none of them work.

Comment 14

[John Morrison]

Last one works for me (win95 2000050308). However, I was lazy and used a 
single var for toggling state -- try clicking more than once on the last 
button (if you have previously clicked on another button).

Comment 15

[Charles Manske]

Please note that there are 2 issues here:
1. We set the attribute "collapsed" to "true" to trigger the CSS rule:
visibility: collapse
The problem with the attribute spelling is now fixed.
But the behavior of using "visibility: collapse" still causes problems,
as in the Composer Image dialog.
Another example is when I try to set "visibility:collapse" on the Composer
<toolbox>. If I remove any "class" attributes from the buttons in that toolbar,
it works, so there's something bad happening with CSS-derived sizes
(the rect passed into nsBox::SetBounds() has negative height, causing 
assertions). I'll try to generate some text cases in the next week or so.

Comment 16

[Charles Manske]

This is fixed, but irrelevant, since we won't be hiding the toolbar anyway.