I'm not sure if anything can be done about it which is reconcilable with the redesigned composition window, but the current layout may pose a challenge for users running a low screen resolution and thus have a limited windows width. Following changes were made in bug 642163: - the formatting bar has moved about 100px to the right, leading empty space; - the end of the attachment pane is aligned with the end of the format bar. Consequently, - the minimum window size to show all UI items has increased by 100px; - the attachment pane is cropped once the format bar gets truncated. The latter effect is a regression from previous behavior where only the format bar was cropped but the attachment pane was allowed to slide into the address area without being truncated. If possible, it would be good to uncouple the attachment pane from the format bar alignment, given that it becomes inaccessible when the window is small (which is typically the case for visually impaired users or those who don't want to use up the full screen; also, netbooks may be affected, where I don't know the size specifications). Workaround: Disable toolbar visibility if the window size cannot be increased.

With removing the FormatToolbar-box and leaving the FormatToolbar left-aligned, the attachments-box will no more fall out of the window. Andreas, should I make the FormatToolbar left-aligned again? Then we can use this Bug for this.

You could also reduce the size of the menulist for choosing a font, since it can easily expand to ridiculous sizes if you have a font with a long name. 150px should be plenty for it.

I was thinking about that as well but figured that I may need the width to accommodate the longest string for a font. On the other hand, the SMTP box in the new account wizard has a menu box which can be smaller than the longest string but nevertheless shows the drop-down in the full width as necessary. So, that might serve as a template (once you've picked the font you may no longer care about its full name being constantly visible). > - the end of the attachment pane is aligned with the end of the format bar. I'm wondering what's causing that given that the changes in bug 642163 are mainly adding the indent but not putting everything into a grid or similar restraining structure. Is the added pack="end" possibly doing this?

(In reply to comment #3) > I'm wondering what's causing that given that the changes in bug 642163 are > mainly adding the indent but not putting everything into a grid or similar > restraining structure. Is the added pack="end" possibly doing this? The formatting bar forces the width of its parent node to be larger than the window, and then the flexiness of the addressing/attachment widgets fill up that space.

That makes sense, I don't see though why the attachment pane was uncoupled from the format bar in the old implementation (thus wasn't affected by it getting cropped) but now it is. Resolving that dependency should fix much of the issue, but it's not obvious to me where in attachment 526996 [details] [diff] [review] this was introduced.

This patch reverts the aligning of the FormatToolbar with the addressing-widget. On Windows7 and OSX I added 3px padding on top of the FormatToolbar to separate it from the address headers. On Linux I gave no padding because theme depending the toolbars are enough seperated and padding could look weird. On WindowsXP the seperation is made by borders.

Just a drive-by comment: I'm not _really_ happy with this fix. I would prefer to see the toolbar get pushed over to the right as the window shrinks, and then get cropped. But I agree with rsx11m, the attachment pane didn't used to get cropped as the window shrank, and so fixing that would be a better fix, imo. Thanks, Blake.

Given the effect shown in bug 657559, I think this is a blocker for the 3.3 release.

If we decide that we want to keep the padding the way it is now, the solution here is to set flex="1" on FormatToolbar-box and FormatToolbar, though we'd also probably want to make the font menulist a bit smaller to make up for the lost space.

Comment on attachment 531459 [details] [diff] [review] Move the FormatToolbar to the left again Given this seems to take care of the behavior in bug 657559, I really want to see this in ASAP, so ui-r+. Bonus points if you can add some flex to the boxes as Jim mentioned in comment 11.

Comment on attachment 531459 [details] [diff] [review] Move the FormatToolbar to the left again Review of attachment 531459 [details] [diff] [review]: ----------------------------------------------------------------- We still have css rules for the removed "FormatToolbar-box" element in mail/themes/qute/mail/compose/messengercompose-aero.css… And I would still prefer to see the splitter on top of the FormatToolbar, but we can leave that for another bug, I guess… Other than that, r=me.

I haven't added the flex="1" because before the aligning patch it has also no flex. I tried both and saw no difference. Removed the surplus FormatToolbar-box selectors in messengercompose-aero.css.

I'll opening a new Bug for the splitter on top of the FormatToolbar.

Yeah, if you remove the wrapping FormatToolbar-box, flex="1" is no longer necessary. It's only useful when the actual <toolbar> isn't the outermost element.

Checked in: http://hg.mozilla.org/comm-central/rev/f40b3d53a385

This works fine for me in yesterday's nightly 3.4a1pre build on Windows 7, the attachment pane remains visible even when the format bar is cropped, and entered text is correctly wrapped again with bug 657559 fixed in the process. The only minor effect I see is that if you narrow the window width further beyond any reason, a horizontal scrollbar shows up for the editor window. This doesn't affect text wrapping, thus I don't think needs specific attention, it just looks a bit odd.

(In reply to comment #18) > The only minor effect I see is that if you narrow the window width further > beyond any reason, a horizontal scrollbar shows up for the editor window. > This doesn't affect text wrapping, thus I don't think needs specific > attention, it just looks a bit odd. I see this only when the window is smaller than the longest word which can't be wrapped. And this is okay to see the whole word. The same happens with TB 3.1. So this is no regression and normal behavior.

I'm getting the scrollbar earlier than that (522px on either Windows 7 and Linux), and yes, I see it in Miramar 3.3a1 already as well. It wouldn't make much sense for practical purposes to use anything below that threshold, given that other UI elements are getting really narrow. Thus, I don't think that's much relevant, and this bug is definitely fixed. Thanks! :-)