User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.2pre) Gecko/20090829 Shredder/3.0b4pre When changing the header display from "Normal" to "All" the buttons for "forward", "archive", "junk" and "trash" in the header plane are shown with a too little height. This occurs only in "All" header display. When using the "Normal" header display the height is correct = the same as for the "reply/reply all" button. Reproducible: Always

Yes it is but I think that is deliberate for better use of vertical space. This bug should be wontfix.

But why has the "reply"/"reply all" button then a different size than the other buttons? And why are the labels not vertical centered? At the moment it doesn't look well designed. By the way, why saving vertical space in "all headers display"? There is enough. This might make sense in the "normal headers display". Could somebody point me to the changes in the Hg repository which resulted in this change, please? (Shouldn't there be a bug. I cannot find it). Then I could use user.css or an extension overlay to revert it for me (and others?).

Sorry it's my mistake: you are right ;-) Confirmed here on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090829 Lightning/1.0pre Shredder/3.0b4pre ID:20090829032304 At this moment I can't find any dupe.

There are other circumstances when this happens too, though I'm not sure what they are at the moment. I've seen this during development on Linux at least. My suspicion is that something's disrupting the align="baseline", but I don't know what.

I've noticed this happens on both Windows and Linux but not on Mac. For each of the problem OSes I had to set the button box with a min-height which prevented this from happening. I'm not sure this is the correct fix (in the sense that I'm using px values I found) but it does prevent this from happening. Here are the values I've used - Windows: http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/rev/cba554743386 Linux: http://hg.mozilla.org/users/clarkbw_gnome.org/ovidiu-header/rev/b42f637b0514

Here's a patch to set the min-height values for the gnomestripe and qute themes as described in my comment. I've tested this a lot in my extension but haven't tested it on trunk so here goes.

If that make sense, almost half-button is cutoff in my case.

(In reply to comment #6) > There are other circumstances when this happens too, though I'm not sure what > they are at the moment. I've seen this during development on Linux at least. It seems like this occurs exactly when there's a scrollbar in the message header. The issue also occurs with the default header settings if you make the max-height of #expandedHeaderView something small. (I think scrollbars caused by bug 513318 didn't do this, but those don't happen anymore anyway). What's especially weird is that we set the inner .button-box of the buttons to have a min-height of 16px (on gnomestripe at least), but the DOM inspector shows that these get squished to 5px tall.

In Build 20091001 with icons for these buttons, the problem is solved for me, probably because the icons cause the buttons to have a certain minimum width. It's probably not perfect, as the font size could be made bigger than the icons, but it's definitely better than the patch above. The real cause is, I guess, some "overflow: visible", plus something forcing the buttons to be small, in our TB skin.

Ben, is this still fixed when in text only mode?

Comment on attachment 402049 [details] [diff] [review] patch to add the min-height requirements Blake has graciously agreed to pick up some of my reviews; handing off to him. The current patch seems like a bit of a hack; I think it's worth playing around for 15 mins or so to see if you can understand what's actually going on here and what a less kludgey fix would be. Failing that, I suggest giving it an r+ anyway.

I can't seem to reproduce this bug on Mac OS X, or Ubuntu. Once I've got my WinXP box set up, I'll try to reproduce it there, but I thought I'ld let you know that it seems like it's fixed without the patch.

Confirmed here too on Windows XP: I cannot reproduce (in the past, see comment #5, I can) with latest Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091021 Lightning/1.0pre Shredder/3.0pre ID:20091021032416 It seems fixed by another bug...

WFM here too Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091020 Shredder/3.1a1pre

Comment on attachment 402049 [details] [diff] [review] patch to add the min-height requirements If it works without the patch, let's not change it. ;)