When displaying all header entries the buttons "forward", "archive", "junk" and "trash" are shown with a too little height.

RESOLVED WORKSFORME

Status

Thunderbird
Message Reader UI
--
trivial
RESOLVED WORKSFORME
9 years ago
9 years ago

People

(Reporter: Joachim Herb, Assigned: clarkbw)

Tracking

(Blocks: 1 bug, {polish})

Trunk
Thunderbird 3.0rc1
polish
Dependency tree / graph
Bug Flags:
blocking-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [no l10n impact])

Attachments

(4 attachments)

(Reporter)

Description

9 years ago
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
(Reporter)

Comment 1

9 years ago
Created attachment 397458 [details]
Correct arrangement of buttons in "Normal" header view
(Reporter)

Comment 2

9 years ago
Created attachment 397459 [details]
"All" header view with misaligned buttons
Yes it is but I think that is deliberate for better use of vertical space.
This bug should be wontfix.
(Reporter)

Comment 4

9 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Updated

9 years ago
Blocks: 513553

Updated

9 years ago
Blocks: 456814
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.
Component: Mail Window Front End → Message Reader UI
Keywords: polish
OS: Windows Vista → All
QA Contact: front-end → message-reader
Hardware: x86 → All
Target Milestone: --- → Future
(Assignee)

Comment 7

9 years ago
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

Updated

9 years ago
Blocks: 489609

Updated

9 years ago
Flags: blocking-thunderbird3?
(Assignee)

Comment 8

9 years ago
Created attachment 402049 [details] [diff] [review]
patch to add the min-height requirements

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.
Assignee: nobody → clarkbw
Status: NEW → ASSIGNED
Attachment #402049 - Flags: review?(dmose)

Updated

9 years ago
Flags: blocking-thunderbird3? → blocking-thunderbird3+

Updated

9 years ago
Whiteboard: [no l10n impact]

Comment 9

9 years ago
Created attachment 402384 [details]
Half-button cutoff

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

Comment 10

9 years ago
(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.
(Assignee)

Updated

9 years ago
Whiteboard: [no l10n impact] → [no l10n impact][needs review dmose]
(Assignee)

Updated

9 years ago
Target Milestone: Future → Thunderbird 3.0rc1
Version: unspecified → Trunk

Updated

9 years ago
Duplicate of this bug: 518800

Comment 12

9 years ago
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.

Updated

9 years ago
No longer blocks: 489609
Ben, is this still fixed when in text only mode?

Updated

9 years ago
Whiteboard: [no l10n impact][needs review dmose] → [no l10n impact][needs review bwinton]
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.
Attachment #402049 - Flags: review?(dmose) → review?(bwinton)
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...

Comment 17

9 years ago
WFM here too
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091020 Shredder/3.1a1pre
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
Whiteboard: [no l10n impact][needs review bwinton] → [no l10n impact]
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.  ;)
Attachment #402049 - Flags: review?(bwinton)
You need to log in before you can comment on or make changes to this bug.