499543 - Message header and attachment box can display on top of the statusbar

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Nomis101]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; de-de) AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090620 Shredder/3.0b3pre

When you read an email in the message pane and drag the splitter down, than you can also see the description of the message header in the application border. This only happens for the message header, not for the main text of the email.

Reproducible: Always

Steps to Reproduce:
1. Select an email to see it in the message pane
2. Drag the splitter down

Comment 1

[Nomis101]

Attachment: Screenshot

Comment 2

[Ludovic Hirlimann [:Usul]]

Dan could this be a regression from your work on Header display ?

Comment 3

[Nomis101]

Attachment: Same for attachments

Today I recognized that I see the same also for attachments.

Comment 4

[OOO until Apr 20; Dan Mosedale (:dmosedale, :dmose)]

I'm not sure.  Nomis, did this just start happening?  If so, do you know exactly when?

Interestingly, for the headers case, I can only reproduce this when View > Headers > All is selected, rather than the default of View > Headers > Normal.

Comment 5

[Phil Ringnalda (:philor)]

Attachment: Fix v.1

Not even remotely new: you can see talk about it in all the "All headers needs a scrollbar" bugs. If <deck> wasn't always painted as though it's positioned, it would be a regression from that change; otherwise, it would be from whenever we first put a <deck> in.

The problem is that positioned elements are a separate layer painted on top of everything else, and <deck> is painted in that group, so the solution is to pull the statusbar up into that group, too.

You can actually see it with Normal headers view, too, but you have to outwit our cheating. I don't think it's actually documented, not anywhere I've seen anyway, but if you give a splitter a collapse attribute, like the collapse="after" on the threadpane splitter, don't give it a grippy, but do give the box that's "after" a minheight, then when you drag down to that minheight it collapses. So when you drag to 100px, and you're just about to see the Normal headerpane go over the statusbar, we collapse. If you change to a larger font size (Windows' Large Fonts isn't enough, but Extra Large Fonts is), then the headerpane will be tall enough to overrun before you hit the 100px collapse.

Comment 6

[Nomis101]

(In reply to comment #4)
> I'm not sure.  Nomis, did this just start happening?  If so, do you know
> exactly when?

I don't know exactly when this start happening, but I noticed it one or two weeks ago for the first time.

Comment 7

[Phil Ringnalda (:philor)]

We were doing it with headers as far back as 20040504 (the earliest build I found without looking too hard that actually worked at all), though attachments wouldn't have started until the attachment rewrite for 2.0.

Comment 8

[Nomis101]

Cool, Fix v.1 fixed the describet issue for me. :-)

Comment 11

[Günter]

There are more bugs on this issue:
bug 234078 (/2004-02-12)/ 287731 (/2005-03-25/)
but the "main" 223132 (/2003-10-21/) ... a real grandfather :-P 

Seems those should be combined to just one ..

Comment 12

[OOO until Apr 20; Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 385130 [details] [diff] [review]
Fix v.1

r=dmose, conditional on discussing with someone in layout and doing stuff to put us on the path of not getting bitten by this again.  I suspect this includes:

* Filing a bug, if the reason this is necessary is something that should be fixed

* Documenting what's going on at <https://developer.mozilla.org/en/XUL/deck> (or somewhere else, if that's more appropriate)

* Changing the comment in this patch to be more explicit about what's going here based on the above.  I.e. if it's truly working around a bug, say so in the comment and link to the bug.  

Thanks for the patch, and sorry for the slow review!

Comment 13

[OOO until Apr 20; Dan Mosedale (:dmosedale, :dmose)]

Since you've filed the bug 513597, I'm fine with you changing the theme comments to point to it, and going ahead and landing the workaround now.  If appropriate, a different/better workaround can come after we've heard something authoritative from the layout owners there.

Comment 14

[Phil Ringnalda (:philor)]

Attachment: Fix v.2

Examined in the light of the happy world where everyone's read the documentation that doesn't exist which explains that when you give a box a minheight less than the height and a minwidth less than the width, you're opting in to a different realm of splitter resizing, where you have to decide what to do with overflow, I think this'll be clear enough (and it's definitely righter than v.1).

The min-height and height in the CSS was (fortunately) doing nothing, because http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsBox.cpp#700 prefers attribute values over CSS, so the usable values in messenger.xul are what gets used, so I nuked the CSS and the comments about it, and nuked the stray pasteo of a couple of commented-out rules with no selector that's been in the Pinstripe version since 1.1, because it was in my patch's context, annoying me.

Comment 15

[Nomis101]

Is this fix for b4 or for RC1?

Comment 16

[OOO until Apr 20; Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 398564 [details] [diff] [review]
Fix v.2

Looks good; r=dmose.  Maybe add a note to <https://developer.mozilla.org/en/XUL/splitter> so that your research & discovery will be preserved for posterity?

Comment 17

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/comm-central/rev/63f1252cd1bc

Comment 19

[Phil Ringnalda (:philor)]

I would have added something along the lines of 

How much a splitter will resize a box, and what happens while resizing and when you get to the limit, depends on the height (or width) specified for the box as an attribute or in CSS, the min-height (or min-width), the intrinsic height of the box contents, and the presence or absence of a collapse attribute on the splitter.

For

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

the splitter will not move, unless there's a collapse attribute on the splitter, which will cause it to collapse as soon as it is dragged.

For

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

the splitter can be dragged down to the 100px intrinsic height of the lower box, when it will stop, or collapse if the splitter has a collapse attribute.

For 

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

the splitter can be dragged down to the 200px minheight, when it will stop or collapse.

For

<vbox></vbox>
<splitter>
<vbox height="500" style="min-height: 50"><vbox height="100"/></vbox>

the splitter can be dragged down below the 100px intrinsic height of the lower box, causing the child box to overflow, until reaching the min-height, at which point it will stop or collapse. That should also work with a minheight attribute specifying a value less than the intrinsic height, but because of bug 513597, only specifying both minheight and minwidth attributes, or specifying min-height or min-width in CSS, actually works to allow overflow.

but every time I try to do anything with devmo, it's broken, and I'm tired of trying to remember to do it.

Comment 20

[jenzed]

I updated the splitter page on MDC (https://developer.mozilla.org/en/XUL/splitter) with the note in comment # 19.