Message preview pane is cut off on the right because message header toolbar doesn't scale (and is no longer customizable). Implement toolbar overflow/scalability.
Categories
(Thunderbird :: Message Reader UI, defect, P2)
Tracking
(thunderbird_esr78 wontfix)
Tracking | Status | |
---|---|---|
thunderbird_esr78 | --- | wontfix |
People
(Reporter: luetzow1813, Assigned: aleca)
References
(Regression)
Details
(Keywords: regression)
Attachments
(4 files, 1 obsolete file)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
Looking different e-mails in the preview window.
Actual results:
Hello everybody,
with Thunderbird 78 there is no right-clickable
customize function in the preview window, as you can see in
Thunderbird 68. So you can also get there from Extensions (=
Add-ons) such as "Allow HTML Temp" or "Display
Mail User Agent" added buttons not hide or remove.
This has the consequence that the preview window simply opens on
the right is cut off, which has or have different consequences
can:
a) The last switch on the right outer position will may be cut off
or disappear into the non visible area.
b) The date/time display of the e-mail is cut off or may disappear
completely into the non-visible area.
c) Mailtext is displayed, provided that the visible area of the
preview window, also cut off on the right.
The complete readability of an e-mail itself and the Header data
is only possible if the e-mail is sent by double-clicking will
open in a separate window.
In the German forum Thunderbird Mail DE you can find the
following Thread:
https://www.thunderbird-mail.de/forum/thread/85413-thunderbird-78-
vorschaufenster-wird-teilweise-rechts-abgeschnitten/
Sorry for my English. Translated from German with DeepL
Expected results:
If it is all well, then it should be none "cut off" on the right side.
Comment 1•4 years ago
|
||
Thomas, the forum post has screen shots
Comment 2•4 years ago
•
|
||
This is essentially caused by the nonsensical removal of message header toolbar customization, but in spite of that, it's also a bug in it's own right, namely that when users reduce the width of the TB window and hence the width of msg preview also gets reduced, the toolbar doesn't scale. When the entire toolbar with all text+icon buttons cannot fit, it should scale (i.e. not cause the entire layout to break) and either
- Allow the labels to truncate, and/or switch to icons-only when there's not enough horizontal space for text+icons
- show a [>>] disclosure button at the right end to access the off-screen buttons, or
- expand to two rows
Comment 3•4 years ago
|
||
Bug 1535265 (esp. the removal of message header toolbar customization) is a total UX desaster, and it's much worse for localizations like German where the button labels are much longer than in English. So we can neither remove unneeded buttons nor remove toolbar labels and just show icons-only, which was possible before and an excellent solution for reduced window with. Showing two windows side-by-side on a 22 inch screen already makes the Thunderbird message preview UI to fail. So sad.
Bug 1556261 requests to re-implement message header toolbar customization, 8 duplicates as of today and counting...
(In reply to Jim Porter (:squib) from Bug 1535265 Comment 29)
Is there a reason the message header toolbar in particular was rendered non-customizable in this patch? It's probably the single most important toolbar to customize, since it has all the buttons for operating on a single message, and is in a much more space-constrained environment than, say, the main toolbar. This is especially important for non-English locales, where the button text is often longer than English. Previously, you could switch to "icons only" or remove some buttons you don't need, but with this patch, there appears to be nothing you can do. Even in English, it causes problems for the Vertical 3-pane layout unless you make the message pane pretty wide.
I can understand removing some of the other toolbars (though I don't like it, since part of the reason for those being customizable was for easy extension hooks), but not the message header toolbar. Since Thunderbird still has one customizable toolbar - the main one - it's not like we can totally get rid of the
<toolbar>
element anyway. The additional cost/pain of keeping 2<toolbar>
s around seems pretty minimal compared to keeping 1 around.
+1
Reporter | ||
Comment 4•4 years ago
|
||
Hello everybody,
thank you for stating that it is indeed a bug.
For additional information. Thunderbird starts with my window maximized and I only work in this mode.
The described bug can be fixed, as already stated, if necessary by reducing the width of the folder bar (reduced to the left) and thus indirectly enlarging the preview window in individual cases.
But this is of course not a permanent solution, because the user usually does not want to constantly adjust the program window itself or parts of it.
Translated with DeepL.
Comment 6•4 years ago
|
||
Aleca, here is the bug we discussed earlier. I think buttons should auto-adjust to use icons only if they can't all fit, like for the quick filter toolbar icons.
Comment 7•4 years ago
|
||
(Or one of the bugs, I think I saw at least one more.)
Assignee | ||
Comment 8•4 years ago
|
||
The message header area needs a lot of love and some serious rethinking to improve readability, usability, and keyboard accessibility.
Do you think it's worth opening a meta bug to keep track of everything related to this area?
I have a mock-up to improve the whole area and offer the required flexibility to users without the necessity of making this a customizable toolbar.
I think buttons should auto-adjust to use icons only if they can't all fit, like for the quick filter toolbar icons.
I'll implement this.
Comment 10•3 years ago
|
||
(In reply to Alessandro Castellani [:aleca] from comment #8)
I think buttons should auto-adjust to use icons only if they can't all fit, like for the quick filter toolbar icons.
I'll implement this.
Any bandaid-fix would be well worth doing (e.g. "reduce-to-icons" when toolbar exceeds available width, or anything from comment 2).
Alex, would you perhaps have the time to try something here?
It's really pretty annoying because the former message header toolbar is the only thing which does not scale and breaks the entire msg preview, more so for languages with longer labels (any language other than English), and also for enterprise contexts where addons are used to add extra buttons for server archiving etc., e.g. as seen in Bug 1709530 Comment 0, attachment 9220284 [details].
Assignee | ||
Comment 11•3 years ago
|
||
I'll try to find some capacity for this week.
Assignee | ||
Comment 12•3 years ago
•
|
||
This is a WIP patch that doesn't work very well.
The main problem is that the CE header fields are populated a bit later and the full width size needed to check if the header is shrinking below that threshold is not correctly updated when the message becomes first visible.
Magnus, do you know if we have an observer that fires up when the message header is fully loaded with all data?
Another problem is the entire structure of this header, which is a bit complicated with many indented containers, most likely leftovers from de-xbl.
We should consider rebuilding this whole structure with pure HTML, CSS grid, and flexbox, which would make things easier to manage.
What do you think we should do here?
EDIT: Please ignore typos and crappy code in the patch. This is just a proof of concept.
Comment 13•3 years ago
|
||
Assignee | ||
Comment 14•3 years ago
|
||
Haven't tried, but possibly using https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries you could at least make sure that it uses icons when the width is clearly not going to work (parent width less then what, 500px?)
If I'm not wrong, container media queries are not supported anywhere other than on Chrome canary, but disabled behind a flag pref.
Assignee | ||
Comment 15•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Comment 16•3 years ago
|
||
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/9bd7b7700df2
Make the message header toolbar responsive. r=mkmelin
Comment 17•3 years ago
|
||
Awesome, thanks Alex for fixing this painpoint following my comment 2 and comment 10, and Magnus for the review!
Reporter | ||
Comment 18•3 years ago
|
||
Reporter | ||
Comment 19•3 years ago
|
||
Hello together,
the problem still exists in the German Thunderbird-Version 91.1.0 (Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1).
I have uploaded a screenshot.
"Date" cut on the right side, "openPGP"-information cut on the right side, the button "Anhänge" (german) cut on the right (End "]" of the button).
Greetings
Luetzow1813
Reporter | ||
Comment 20•3 years ago
|
||
The button (in german) on the right has the following complete text: "Anhänge abtrennen" (from the Add-on: AttachmentExtractor Continued).
Comment 22•3 years ago
|
||
(In reply to Luetzow1813 from comment #19 / comment #20)
the problem still exists in the German Thunderbird-Version 91.1.0 (Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1)...
The button (in german) on the right has the following complete text: "Anhänge abtrennen" (from the Add-on: AttachmentExtractor Continued).
Hi Luetzow1813, this bug has been resolved VERIFIED FIXED, so it's unlikely to still fail. Even if it did, we would have to deal with that in a new bug. I've tested this on German version of TB 91.1.2 and the header buttons adjust dynamically as they should (see screenshot). In your case, once again, it's most likely to be caused by add-ons. Please run ≡ > Help > Troubleshoot Mode…
before filing bugs against Thunderbird - if the bug does not occur without add-ons, it's most likely a bug caused by add-ons. Add-on bugs must be reported to add-on authors. Thanks!
Comment 23•3 years ago
|
||
wrong |
Yeah, this is happening again now. Probably a new regression. I will file a new bug.
Comment 24•3 years ago
|
||
Sorry I didn't realize I'm still on Thunderbird 78. I could swear I updated and saw this bug fixed, but I guess my memory doesn't serve me well.
Comment 25•3 years ago
|
||
Luetzow1813, what is weird, is that the button text is still shown. With the fix in this bug the text should be hidden when there isn't enough space. Do you use an extension that changes the message header buttons or do you use a userChrome.css customization?
Maybe it's also one of your extensions that places a button on the message header.
Description
•