Right side of entire Thunderbird window is cut off if toolbar width exceeds window width

RESOLVED FIXED in Thunderbird 3.1a1

Status

Thunderbird
Mail Window Front End
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Rich, Assigned: dmose)

Tracking

unspecified
Thunderbird 3.1a1

Firefox Tracking Flags

(blocking-thunderbird3.0 needed, thunderbird3.0 .1-fixed)

Details

(Whiteboard: gs, URL)

Attachments

(5 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
Build Identifier: Thunderbird/3.0 ID:20091204171430

Also present in: Shredder/3.0.1pre ID:20091221073909

When Thunderbird is opened in a non-maximized state, the right side of the window is not completely shown.  If the migration assistant window is opened and the use new toolbar option is selected followed by the selection of the old toolbar option, the window will then re-size normally.  Upon closing and reopening Thunderbird, the issue remains.


Reproducible: Always

Steps to Reproduce:
1.Open Thunderbird, not maximized, using original toolbar option previously selected in last instance of using Thunderbird
2.Open migration assistant and toggle between use new toolbar and use original toolbar
3.Window will re-size normally, but when Thunderbird is closed, issue persists
Actual Results:  
Could reproduce the issue

Expected Results:  
Should have been able to use the original toolbar selection and re-size Thunderbird with the right side of the window not cut-off

I will submit images of this behavior
(Reporter)

Comment 1

8 years ago
Created attachment 418707 [details]
Image of the issue with the right side of the window

This is how the window appears upon opening Thunderbird in a non-maximized state using the original toolbar option chosen with the Migration Assistant
(Reporter)

Comment 2

8 years ago
Created attachment 418708 [details]
Thunderbird shown after toggling between original and new toolbars

This image shows the subsequent normal appearance of Thunderbird.  To obtain this I opened the Migration Assistant, chose use new toolbar, then chose use original toolbar. I then closed the Migration Assistant.  The windows would re-size and appear as one would expect until Thunderbird was closed and reopened.
blocking-thunderbird3.0: --- → ?
Flags: blocking-thunderbird3.1?
Confirming as I've seen various reports of this and its easy to reproduce.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

8 years ago
See also bug 534006.

Comment 5

8 years ago
I think describing this behavior as happening when Thunderbird is opened non-maximized may be oversimplifying.

Saying that toggling the state of the toolbar from old to new and back to old temporarily resolves the issue may also be oversimplifying though that may be true for particular window sizes.

I think whether the truncated window exists when opening Thunderbird depends not only on whether the window is non-maximized, but on what size this non-maximized window is.  It can be non-maximized, but still be wide enough that the right side of the window is not cut off.

On the other hand, it can narrow enough that toggling the toolbar between old and new does not prevent the right side from being cut off.

There is some debate right now at bug 534006 as to exactly what that bug is about, but it still appears to me that that one and this one are probably about the same thing and that the behavior is related to whether or not the window is wide enough to accommodate he whole toolbar be it old or new.

Do people who find that toggling the toolbar temporarily fixes the problem still find that to be true if they reduce the width of the window?
Adjusting summary to what I think is actually going on. The new toolbar is effectively wider due to the text that is now alongside the buttons.

Not sure I'd block a 3.0.x release on this, as the default is for less buttons, and if more buttons are added the user can adjust the text/button preference in the customisation.
Assignee: nobody → clarkbw
Summary: Right side of entire Thunderbird window is cut off unless window is maximized → Right side of entire Thunderbird window is cut off if toolbar width exceeds window width

Comment 7

8 years ago
I agree with the new summary, but this *is* also a regression, since a too-wide toolbar in 2.x doesn't cause this. Presumably, something changed when tabs were added.
(In reply to comment #7)
> I agree with the new summary, but this *is* also a regression, since a too-wide
> toolbar in 2.x doesn't cause this. Presumably, something changed when tabs were
> added.

I think the regression is more in toolkit/gecko somewhere - I can reproduce it in Firefox. if I shrink the width of the window really small. There may be some things we can do to help it in Thunderbird however, hence why I haven't moved it.

Comment 9

8 years ago
(In reply to comment #6)
> Adjusting summary to what I think is actually going on. The new toolbar is
> effectively wider due to the text that is now alongside the buttons.
> 
Yes, this seems to be true though there is some potential terminology confusion here, since the Migration Assistant appears to use the terms "original toolbar" to mean one with a relatively large number of buttons,the default in Thunderbird 2 and "new toolbar" to mean one with relatively few buttons, the default in Thunderbird 3.

If I understand your comment correctly, "new toolbar" in it refers to the text being to the right of the icons regardless of how many icons there are.

As recently shown in bug 534006, the window truncation can actually occur even in a maximized window.  Apparently several of us thought this didn't occur in a maximized window because a maximized window was large enough to accommodate all our buttons, but the problem can occur in a maximized window if there are enough toolbar buttons.

I now also see why toggling the toolbar to "new" and back to "original" appears to fix the problem for some window sizes.

When one is using the "original toolbar" (many buttons), Thunderbird 3 still initializes with the text to the right of the buttons perhaps making the toolbar "too big".  Switching to "new toolbar" greatly reduces the number of buttons making the toolbar "small enough".  Just discovered:  Then switching back to "original toolbar" brings back the larger number of buttons but with the text below the buttons perhaps making the toolbar "short enough" even with the larger number of buttons.

Comment 10

8 years ago
That may be an oversimplification also.  It's accurate for me, but may be due to customizations I've done and forgotten about. I don't know if this is true or not, but it may be that the default for Thunderbird 2 was also "Icons beside Text" and I changed it to "Icons and Text".  If so, that might be contributing to the behavior I'm seeing and might mean that what I'm seeing isn't relevant to everyone else.

Updated

8 years ago
Duplicate of this bug: 534006

Comment 12

8 years ago
In response to Bob, yes, opening Thunderbird 3 maximized with the original toolbar does place the text to the right of the buttons and truncate the display.  Switching toolbars to "new" and back to "original" moves the text to below the buttons and corrects the display truncation.  I have not customized the display in any way except to add the Contacts button to the Compose (Write) toolbar.  It was there, standard, in T-Bird 2; it defaults not there in T-Bird 3.  Personally, I'd rather it was there by default as in T-Bird 2.

Just one more thing (and this is a separate issue but I haven't checked for or reported a bug on it).  Since upgrading to T-Bird 3, when I start it, my CPU utilization goes to 100% and stays there for 1-2 minutes while T-Bird says in the status line that it is "determining which messages to index".  T-Bird 2 never did that.  It may be just me, but if others are seeing it, it needs to be reported and checked.
I think we understand the issue -- please no more comments that aren't about how to solve it.  

My guess is that we need to tweak some overflow: properties on the toolbar.  I'm curious whether the same issue can be made to happen in a heavily customized firefox or seamonkey.

Comment 14

8 years ago
(In reply to comment #13)
> I think we understand the issue -- please no more comments that aren't about
> how to solve it.  
> 
> My guess is that we need to tweak some overflow: properties on the toolbar. 
> I'm curious whether the same issue can be made to happen in a heavily
> customized firefox or seamonkey.

I haven't tried, but Comment 8 above says it can be reproduced in Firefox.

Comment 15

8 years ago
Sorry, should have tried before posting last comment, but, yes, it's very easy to reproduce in Firefox by making the window narrow.

Comment 16

8 years ago
It might not be the same issue in Firefox though.

When Firefox is first started with a new profile, the display contains an element that I don't know what to call.  It extends the width of the screen, starts with a "i" in a blue circle on the left followed by the text "Mozilla Firefox is free and open source software from the non-profit Mozilla Foundation.".  On the right is a button containing the text "Know your rights" followed by a Close button.

If the window is made too narrow to accommodate this thing, the vertical scrollbar disappears. Specifically, when the Close button can no longer be seen, the vertical scrollbar disappears.

I also stumbled across the fact that if the NoScript extension puts up a warning (in a yellow background) with a Close button on the right, and the window is made so narrow that this Close button can not bee seen, the vertical scrollbar disappears.

I'm not currently able to induce the behavior in Firefox (3.5.6) in relation to the amount of space taken up by buttons in a toolbar.
Duplicate of this bug: 538605
(Assignee)

Updated

8 years ago
Assignee: clarkbw → dmose
blocking-thunderbird3.0: ? → needed
Flags: blocking-thunderbird3.1?
(Assignee)

Comment 18

8 years ago
Created attachment 420914 [details] [diff] [review]
patch, v1

Here's patch that fixes the problem.  The comment in the patch explains what's going on.  I'm working on a test, but that's still in progress, and if push comes to shove, we could consider taking the code change without the test for 3.0.1.  I'll continue working on the test today.
Attachment #420914 - Flags: review?(bugzilla)
Attachment #420914 - Flags: approval-thunderbird3.0.1?
Makes sense for me for 3.0.1.

For trunk, i wonder if the right longer term fix is to change the box structure so that the toolbar default behavior works.  Thoughts?
(Assignee)

Comment 20

8 years ago
That does sound more ideal.  Right now, the <toolbox> is actually a child of the XUL <window>, which has a CSS overflow setting of -moz-internal-unscrollable, so I suspect that trying to tweak that either won't work or will cause other problems.  So the obvious solution would be to interpose another box between the <window> and all of its children.  I'm not really convinced it's worth the conceivable complexity/performance costs of adding another box or the person-minutes/hours to spend more time on this, unless there's reason to believe that this is likely to bite us in another form again.
Comment on attachment 420914 [details] [diff] [review]
patch, v1

I think this is a definite improvement on what we do now. r+a=Standard8
Attachment #420914 - Flags: review?(bugzilla)
Attachment #420914 - Flags: review+
Attachment #420914 - Flags: approval-thunderbird3.0.1?
Attachment #420914 - Flags: approval-thunderbird3.0.1+
Landed on trunk as <http://hg.mozilla.org/comm-central/rev/e2ff07247663> and 1.9.1 as <http://hg.mozilla.org/releases/comm-1.9.1/rev/fd4c289f8691>.
status-thunderbird3.0: --- → .1-fixed
Assuming fixed and we'll deal with any follow-ups elsewhere.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
OS: Windows XP → All
Hardware: x86 → All
Target Milestone: --- → Thunderbird 3.1a1
Depends on: 541052
Bad fix! 

See Bug 541052...

overflow-y: hidden leads to an effective maximum height of the toolbox, so that toolbars will be cut off or hidden at the bottom.

Test it by installing at least 2 extensions that add toolbars... (e.g. QuickFolders + TagToolbar) I will add an attachment with screenshots...
Created attachment 422809 [details]
Shows how a toolbar gets "Pushed off" the area of the toolbox

2 extensions that create toolbars: quickfolders and tag toolbar. By draggin multiple folders to QuickFolders, these flow to the next line, causing QF toolbar to increase - eventually tag toolbar is pushed off screen, then the contained buttons start to go off screen as well
How to fix this: the original bug proposed to make overflow hidden for the toolbox container. Instead we should only hid the overflow for the actual (first) toolbar; if I add these rules, I can fix both issues Bug 541052 and Bug 536245. Note that overflow-y does not need to be specified.

#mail-toolbox {
  overflow-x:visible !important;
  overflow-y:visible !important;
}
#mail-bar3 {
	overflow-x:hidden !important;
}
I will add an attachment with a screenshot
Axel, please do the follow-up suggestions in bug 541052. Comments on a fixed bug are likely to get lost/ignored.
Created attachment 423001 [details]
TB after fix

For testing I have added buttons to the toolbar and switched it to "Icons beside Text".
After applying the userChrome rules from my previous comment:

1. the mail toolbar is cut off at the right, as expected
2. the quickfolders toolbar can expand (as designed) by floating its buttons down
3. the other screen elements are not affected (e.g. scrollbars of message pane are visible)

Can somebody more versed in patching TB create a patch? I believe the overflow rules that were added for #mail-toolbox must be removed.
You need to log in before you can comment on or make changes to this bug.