513597 - Specifying only minheight or minwidth attributes on a box doesn't allow a splitter to resize the box below their preferred height or width, but specifying both at once or using CSS works

Status: UNCONFIRMED

(Core :: Layout, defect)

Description

[Phil Ringnalda (:philor)]

Attachment: Fairly minimized demo

No idea whether this is expected or a bug, but I'm required to know before landing my workaround (which may very well be utterly wrong-headed) for bug 499543.

The attachment is a minimized version of the SeaMonkey/Thunderbird mail 3pane, which uses a minheight and minwidth on the message pane so that it will snap closed if you drag it down to a small enough size. Ordinarily, that works fine, but if you use View - Headers - All, or a larger font size, so that your header pane is more than 100px tall, when you drag the splitter down the header text displays on top of the statusbar.

I had thought that was the fault of using a deck, which I'd heard elsewhere (like bug 469487) meant it would be treated like a positioned element, and draw in a separate layer on top of non-positioned elements, but minimizing it showed that the problem was having both minheight and minwidth.

STR:
1. Load the attachment
(1.5. On Linux, where an empty statusbar is nearly invisible crammed on the left size, spot the statusbar)
2. Drag the splitter down, watching as the text spills out over the statusbar.

Comment 1

[[e-mail]]

Strictly speaking I think the bug is that it doesn't work with only minheight!
(Try it again but using only a min-height style instead.)

You can of course add content (e.g. a spacer with a large border will do) to the thread pane to make it overflow the message pane in the same way (given the min-height style or "equivalent" pair of attributes).

Comment 2

[Phil Ringnalda (:philor)]

While that does keep me from knowing whether the overrun happens with just one, I wouldn't think that's the bug that _I_ want fixed: I want to have both, because I want the collapse effect when we hit the minwidth in vertical layout, I just want resizing to resize the content, instead of shoving it out over the top of a later element (or, of course, to know that doing so is right and intended and how it's supposed to work, if there's an explicable reason for why it's right).

Comment 3

[[e-mail]]

I'm not sure what you're trying to achieve.

Normally a XUL element has an intrinsic preferred and minimum size which is given along its axis by adding up all its children and across its axis by taking the maximum of all its children. This can be overridden by specifying dimensions either as XUL attributes or via CSS. If the children are flexible then they will try to fit to their parent's new size but this is not guaranteed and as with HTML overflow can occur and is visible by default.

Comment 4

[Phil Ringnalda (:philor)]

Okay, I think I'm starting to understand. Given some minimal content in the boxes, call it always 100px high,

<vbox/>
<splitter/>
<vbox/>

does nothing at all, except that you can add a collapse attribute to the splitter, which has the documented behavior of collapsing when you click the grippy, and the undocumented behavior of collapsing the instant you try to drag the splitter.

<vbox/>
<splitter/>
<vbox height="500"/>

will let you drag down to the 100px content-height of the bottom box and then stop.

<vbox/>
<splitter/>
<vbox minheight="200" height="500"/>

will let you drag down to the 200px minheight (since it's higher than the height of the content), and will then stop, except

<vbox/>
<splitter collapse="after"/>
<vbox minheight="200" height="500"/>

will let you drag down to the minheight, when it will (undocumentedly) collapse, and

<vbox/>
<splitter collapse="after"/>
<vbox minheight="50" height="500"/>

(where the height of the content is more than the minheight) will only let you drag down to the 100px height of the content, where it will collapse (or stop, without a collapse attribute).

Where I got confused was because in none of those cases can you ever in any way drag down below the height of the content, so there's never any call to think about overflow: either your content is something like a <browser> that can fit in any size container, or it's something that will put a stop to resizing before it has to overflow. But in the single (undocumented) magical case where you have both a minheight and a minwidth specified, that changes the rules, and now the intrinsic height doesn't matter, and instead of stopping at the height of the content if it's more than the minheight, it will overflow.

So, thanks for solving my problem by telling me that my workaround should be to specify overflow: hidden to keep from getting visible overflow, but I'm still not sure whether this is invalid because it's intended-though-undocumented that specifying both minheight and minwidth at once means you want to be able to resize below the intrinsic height, or needs to morph because it's intended-though-undocumented-and-unimplemented that specifying just one should do the same thing, too, or valid because that magic meaning for minheight+minwidth wasn't intended, it just happened.

Comment 5

[[e-mail]]

(In reply to comment #4)
> <vbox/>
> <splitter collapse="after"/>
> <vbox minheight="50" height="500"/>
> 
> (where the height of the content is more than the minheight) will only let you
> drag down to the 100px height of the content, where it will collapse (or stop,
> without a collapse attribute).
Which is the real bug, since if you had used style="min-height: 50px;" then you would have been able to drag it down to 50px, and the content would overflow.

> it's intended-though-undocumented-and-unimplemented that specifying just one
> should do the same thing, too
Correct.

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #5)
> 
> > it's intended-though-undocumented-and-unimplemented that specifying just one
> > should do the same thing, too
> Correct.

In which case either this bug should morph or we should file a new bug on implementing that behavior?  And probably should document the current behavior somewhere on MDC and link to the bug from there as well, I suspect.