Somewhere along the way to TB3, the header pane stopped auto-resizing to fit in larger content, like when you expand lots of to-recipients, or switch to view > headers > all. Furthermore, user can't resize the header pane manually. Which is almost worse than TB2, even though we now have a scrollbar. The point is, what's the usage scenario for people who expand list of TO- or CC-recipients or switch to "view all headers?" I think we can safely assume people do so because they actually want(!) to view and act upon the expanded set of information. E.g., I want to check if Paul is among the 20 recipients of my mail, and then click on paul's contact to mail him, add him to my addressbook or whatever. Much more so with view all headers: I actually /want/ to view them, with as little scrolling as possible. Currently, TB's behaviour in such scenarios is very unfriendly, not to say ridiculous: "Expanding" the list of to-recipients reveals just one(!) extra row of recipients, and for all the rest of them the user is forced to scroll along. Of course, header pane manual and/or auto-resize should leave a minimum height of the message pane always visible (e.g. 2 lines or 2 cm).

From Bug 513587, comment #0 (more link ... works wrong) > And the frame containing this header information cannot be resized to contain > it all: a scrollbar on the right can't be gotten rid of.

STEPS: A) "View > Headers > Normal" 1. View email with 10 to 50 or more to-recipients with "View > Headers > Normal" 2. Click more-button, expecting that to-addresses will be expanded so you can see them all and act on any of them B) Choose "View > Headers > All", expecting to view "all headers" CURRENT behaviour: A) "View > Headers > Normal" - you see exactly ONE extra line of to-recipients at first sight (about 6 unknown addresses) after expanding - you have to scroll a lot to see more adresses (7+) - the maximum you will ever get to see after scrolling is 4 lines of addresses, and nothing else then (no subject etc.) B) "View > Headers > All" - You can see a maximum of 7 address lines (with ample space between them) or 10 lines of other headers at a time EXPECTED behaviour: A) for "View > Headers > Normal" 1.) when user expands a header using "more"-button a) increase height of header pane automatically, just as much as needed to fit all visible headers in (first time and unless d) applies first) b) always calculate and limit to a maximum total height for applying auto-resizing, so that a minimum height of the message body is still visible (e.g. 2 lines or 2 cm) c) allow manual resizing of the header pane (e. g. user decides he wants to see less of the header pane and more of the message body, in terms of height), but not more than max total height as dynamically calculated in b) d) use a run-time variable or pref (better) to remember the manual resize height of the header pane and reuse it as the new maximum height for auto-expanding the header pane next time (headerPaneMaxAutoHeightUser) (This will allow the user to mimick the current truncating behaviour, so as to see more of the message, but user can choose himself as he pleases and adjust any time). 2.) when user collapses an expanded header a) if header pane (after collapsing) has now MORE height than needed to fit all visible headers in their current expand-state --> decrease current (auto-)height so as to just fit all headers b) if header pane (after collapsing) has still LESS height than needed to fit all visible headers in their current expand-state --> do nothing (respect user-defined max auto-height) B) for "View > Headers > All" 1.) when user toggles to "View > Headers > All" a) immediately increase header pane height up to current max-auto-height (max-Total-Height as calculated as above, or MaxAutoHeightUser, whichever is smallest). b) (optionally) consider storing a separate headerPaneMaxAutoHeightUserAllHeaders (user-definable as described above) for "ALL headers", because we can assume that user wants the two scenarios to behave differently in terms of max-height. 2.) when user toggles back to "View > Headers > Normal" a) collapse everything and use default height as we do now It's not as difficult as it sounds.

I'm not sure I agree with every single detail here, but I think the overall sentiment is right: we should make the header pane resizable, and probably explore using a XUL splitter to make it collapsible as well.

:))) Thanks, Dan, for adding "wanted TB3+"! For the record (and for the link, as Whiteboard doesn't link) This bug is a followup from well-known Bug 223132 (need scrollbar on header panel), which used to cause some stir among users before it was finally fixed, after 5 years and more than 100 votes.

This patch allows the header box to be resized. At this moment, I've only tested on Mac, but it should theoretically work anywhere; I've made it styled analogously to the folder-pane splitter on each platform. I think this can alleviate header size pane that folks are feeling in a somewhat significant way, so I'm going to mark this blocking and pull it back into b4, because I think it wants user-testing to shake out any issues. Starting off by requesting ui-review from Bryan. Assuming he's on board, I'll do the remaining cross-platform testing and then request regular review.

Just a note that this bug is a followup to bug 223132, in case that information is useful at some point. I've removed that info from the status whiteboard so that it's easier to skim through the bug 3.0b4 blockers.

Comment on attachment 397826 [details] [diff] [review] allow the header to be resized I like the concept but I'm minusing because I think we need more of an overall design. The splitters have historically brought usability issues because when they collapse many users cannot find how to bring them back. Sometimes users mistakenly collapse things and then get stuck with the information gone. We need a solution for this if we want to continue. Adding a gripper to the splitter helps people to grab the area but I don't think this solves the issue of where the header went and how to get it back. A possible solution would be that we only allow the splitter to collapse up to the button box (the top line), but not more. That solution only partially covers the usability issues here. Once the splitter covers up information we need a strategy for letting people know that new information has arrived. We could always open the splitter up when looking at a new message, i.e. it remembers location only for messages it has seen. This would mean we never cover information you haven't seen but we also require people to shrink it every time. Likely not ideal. I filed bug 514452 recently because I think we can at least get the date field removed in order to save space in the header. Since space saving is the overall goal of this bug I think it makes sense to start with those others first.

another space saver to look into is bug 499180

(In reply to comment #7) > > A possible solution would be that we only allow the splitter to collapse up to > the button box (the top line), but not more. > > That solution only partially covers the usability issues here. Once the > splitter covers up information we need a strategy for letting people know that > new information has arrived. We could always open the splitter up when looking > at a new message, i.e. it remembers location only for messages it has seen. > This would mean we never cover information you haven't seen but we also require > people to shrink it every time. Likely not ideal. While not ideal, isn't it still significantly better than the status quo?

I would argue that lack of easy discovery is no excuse to not include a useful feature. I can't tell you how many times in support forums, I've had to tell a poster to "check your view message body as..settings" when html wasn't displayed. Likewise when clicking of the sort order column in the thread pane. Maybe we should consider keeping a copy of LocalStore.rdf/prefs.js and notifying the user just what he changed in the last session in the next session. Something like "You made some changes..in your last session...would you like to make these changes permanent." The first reaction to a situation that one doesn't understand is to re-start.

If you ask me, please don't make things too complicated by trying to add too many things. The solution I propose in comment #2 is actually quite simple: 1) Always adjust the height of the header pane automatically (expand/shrink) as needed to fit in all currently displayed content, unless 2) autosizing will be restrained in both directions by one of the following three conditions, whichever occurs/applies first: - headerPaneMaxAutoHeightTotal (calculated dynamically, each time the height of the header changes, to ensure we are never completely covering the message body) - headerPaneMinAutoHeightTotal (calculated dynamically to ensure we are always showing the default, collapsed headers in full) - headerPaneMaxAutoHeightUser (user can drag the edge of the header pane and initially decrease its vertical size ( < headerPaneMaxAutoHeightTotal), and the new height will be remembered as headerPaneMaxAutoHeightUser and applied as the current maxAutoHeight for the header pane until user manually resizes it again, decrease or increase). ----------------------------------- Cases explained: - So, if user does nothing, we'll always keep the height of the header as small as possible, and auto-resize(increase) as much as needed to fit all expanded headers, but we never completely cover the body (headerPaneMaxAutoHeightTotal). - If user once chooses to see less of an expanded header than currently shown, we'll respect that cut-off height for subsequent auto-resizing, so user needs to scroll for the rest of it. Meanwhile, we still keep the height of the header always as small as possible, so user is only setting a custom maxHeight value (headerPaneMaxAutoHeightUser). That's a single number variable to save and read at runtime, maybe a pref. - In addition, even if headerPaneMaxAutoHeightUser suggests otherwise, we always show at least the calculated default height that fits all collapsed headers of the message (headerPaneMinAutoHeightTotal, as we do now). And of course we still never cover the body completely. In other words, both the calculated max and min height take precedence over the user defined height if necessary.

I'm not sure if I completely understand all components of comment #11, but it sounds reasonable to let the user decide how much vertical space the header pane is allowed to use. To prevent it from collapsing, a minimum height should be ensured based on the standard headers. When additional headers are present, the header pane is allowed to expand up to some height before the scrollbar kicks in. The user should be able to further expand or reduce the vertical height with a grippy, at which point this becomes the new maximum height for the scrollbar threshold. This seems sufficiently intuitive.

I think the ideas in comment 11 are worth trying. The only thing I would put a hold on is the remembering of the gripper height (headerPaneMaxAutoHeightUser). The grippers present a classic usability problem for lots of users. It's not obvious when a change is made via a gripper, there's no notification or undo. Because it's always active a change can be accidentally made at anytime and then because it remembers it's position users continue to have a poorly sized header and feel that Thunderbird made that change as they did it accidentally. The windows task bar suffered this for years as it was always resizeable and movable from the bottom to the sides. You could see users desktops with a 3x sized task bar on the left hand side of the screen and they would claim that it just changed that way over time. Eventually Windows added a "Lock Taskbar" mode that prevented editing unless it was unlocked and changed. The solution wasn't perfect but it helped to prevent a lot of users from frustration at a small expensive of a minority of users who wanted to customize the taskbar infrequently. Lets try adding a gripper for when the header has a scroll bar due to viewing all headers or expanding addresses beyond the max-height I think we can add this fairly easily. It would give users control to view more of the headers without scrolling the header view. However if we wanted to try adding a gripper that could remember height location we would need to do a lot more design that prevents the average person from altering their header UI inadvertently into something useless.

> A possible solution would be that we only allow the splitter to collapse up to > the button box (the top line), but not more. IIRC, that's trivial to implement: Set a min-height, and the splitter obeys it.

As much as this would be great to get, we determined at drivers today that if this was the last bug standing, we wouldn't hold for it, so marking as blocking-. If someone wants to iterate on this patch, though, we'd consider approving it to land if it were ready soon enough.

What are the chances to get something done without an explicit splitter, i.e., reestablishing the TB 2.0 behavior of resizing the header pane to fit the visible content (including after expanding a header/address twisty, now "more" button), while having a CSS-given max-height in place? The current method seems to calculate the minimum height needed and then retains it when expanding an address list, showing the scroll bar instead. This wouldn't allow the user to control the pane height interactively yet, but at least with a userChrome.css entry. A description of how the msgHeaderView or expandedHeaderView height is currently calculated might be helpful as a start, if anybody knows.

With today's nightly, bug 489609 reverted the scroll-bar patch, but only for View > Header > Normal. Thus, the header pane resizes now again when clicking on "more", even beyond the 14em limit. If you select View > Headers > All, the limit applies again and the scroll bar appears, actually shrinking the pane if it was larger before. I don't think it's a good solution as it also reintroduces some of the issues seen before bug 223132 added the scroll bar, so this would still need some work.

Ya know, we have been going round and round on the topic of headers for years. Who wants to see them, where, how many etc. Most of the time, (although I don't view a huge amount of email) I could care less about the headers. I always know who's email/newsgroup post I'm opening. I'm more interested in content. For me showing the content, and giving me a button "show info" that would appear in a separate window would be quite enough. The cell-phone analogy would be listening to the voice mail, then requesting "envelope information" on the call if needed. 9 times out of 10, just listening to the message is enough.

Well, that may be your model of usage, but you cannot apply this to all users. Especially in a professional setting it may well be necessary to get all the header information at one glimpse, thus it certainly makes sense to make that a configuration option (along with bug 456596, which somehow got off the radar). Everybody has different needs, there is no one size fits all...

(In reply to comment #16) > What are the chances to get something done without an explicit splitter, i.e., > reestablishing the TB 2.0 behavior of resizing the header pane to fit the > visible content (including after expanding a header/address twisty, now "more" > button), while having a CSS-given max-height in place? The current method seems > to calculate the minimum height needed and then retains it when expanding an > address list, showing the scroll bar instead. Per some discussion with BenB on IRC, that's actually what's proposed in bug 525225, which, unfortunately, triggers bug 492645 in Gecko, so we can't take that change just yet. :-(

Yes, that's why I've added it as dependency. Maybe some hack will be found in the ongoing discussion on bug 489609 for a solution still doable for TB 3.0.

dmose, I'm going to defer to you about whether this is a blocker.

If this were the last bug standing, I don't think we'd hold for it, so marking as blocking- wanted+.

IMHO this would deserve to be blocking 3.1. It's causing the same problem for which bug 456596 (or dupe Bug 517611) have been flagged blocking-thunderbird3.1 beta1+, because a lot of migrating tb2 users will obviously and frequently suffer from this (high visibility).

This qualifies as a blocker 3.1 because the transition223 user experience of this will be awful - and what a shame: We're an email reader, but we're unable to handle as basic a scenario as showing more than a handful of addresses in cases where the user explicitly wants us to show more.

Our current belief is that we'll get bug 550487 to address the message header problems for this release. Given that, this bug doesn't block. If that changes, and we have problems getting that to work right, we could reconsider.

(In reply to comment #26) > Our current belief is that we'll get bug 550487 to address the message header > problems for this release. Given that, this bug doesn't block. Does Bug 550487 really address the problem of this bug? I don't see how, at all. > If that changes, and we have problems getting that to work right, We do. With TB in window size, I'm looking at a message that show's 2 and a half addresses in first line. When I click on [206 more], the actual result is that the partial address is wrapped to the next line, and I am actually seeing LESS than before (still only the first line, now with 2 addresses). To see the remaining 206 addresses, I have to scroll(!) within tiny header height which allows a maximum of 5 lines at a time, as described in comment 0. It's 4 lines on bigger screens and with TB maximised. > we could reconsider. Please do!

> (comment #27) Does Bug 550487 really address the problem of this bug? No, it doesn't and wasn't intended to. It steers what you see upon the opening of the message, the problem occurs when expanding the headers with either View > Headers > All or the "more" button. As I'd see it, the proper solution still depends on fixing the underlying XUL wrap+scroll bug. As such, it also doesn't block bug 550487.

Right, all I was trying to communicate with that comment is that we thought that bug 550487 would leave the message header interactions in a good-enough state such that we could get away without fixing this bug for 3.1.

I'd nevertheless see those as two orthogonal issues. The default opening of a message is fixed by the other bugs, but fully expanding the headers remains an issue. It may be even more surprising for the user that the message-header pane actually shrinks in height once the "x more" button is pressed for a mailnews.headers.show_n_lines_before_more value larger than the default one. It still would be good to keep this bug on the radar for 3.1.x if possible, though it likely would require again some tricks of line-counting and header adjustments (unless the XUL issue can be fixed and is doing it right).

I'm wondering if it would be possible to measure the actual pane height before the user clicks a "more" button, then set it as min-height for the pane before allowing it to scroll. When switching to the next message, that min-height would have to be removed again along with the scroll bar. In this way, reducing the pane height on "more" would be avoided, and the user given a chance with the mailnews.headers.show_n_lines_before_more preference to steer the height.

Thunderbird is still suffering from this, a lot. How about resetting the target milestone? Could this be important enough to be fixed by Thunderbird developers themselves?

Thomas, I've created a simple addon that does the obvious, and not-really-correct thing. You can find it at https://addons.mozilla.org/en-US/thunderbird/addon/resize-header/ It's not what we want to land in Thunderbird, but perhaps it will tide you over until we get the developer time to fix the bug in the proper way. Thanks, Blake.

And here we are in TB 6.0 and this UI headache is STILL not fixed. Not only does expanding the list of recipients fail to expand the view of them, it also pushes the Other Actions control to the bottom of the header list, i.e., completely out of sight and accessible only by using that wretched scroll bar. Thanks for your add-on, Blake, but it works only when messages are displayed in the message pane, not when they are displayed in their own window. I personally hate the behaviour of the message pane (and also dislike the security risk of inadvertently opening messages simply by hitting an up- or down-arrow key). So I never use it, and am stuck with this horrible UI gaffe of a tiny, non-resizable header pane (pain). Somebody, PLEASE, fix this.

Hmm, I bet I could fix that in the add-on… (Heck, _anyone_ could probably fix it in the add-on. It's not that complicated. :) I've added a to-do for it, so hopefully I'll get to it sometime tonight. Thanks, Blake.

And I've uploaded version 2.0 to <https://addons.mozilla.org/en-US/thunderbird/addon/resize-header/>, and asked for a full review, so hopefully that will become available soon. In the meantime, you can get it from <https://addons.mozilla.org/en-US/thunderbird/addon/resize-header/versions/>. Thanks for the feature request. :)

Downloaded and installed -- seems to work fine. Thank you for acting so quickly! Stuart

The scrollbar has disappeared again, see the screenshot which shows how it looks immediately after "75 more" was clicked, no scrollbar, and the alignment is wrong.

Comment on attachment 580670 [details] scrollbar missing again This is bug 709515, not directly related to the issue here.

More than 2 years after the fact, and we are heading for 2012, and I still walk up to my friends and say: Look, here's the coolest mail reader, but, uhm, well, it will never show more than, uhm, 3 recipients at a time, and when you click to see MORE, you'll actually see LESS... :( We are making TB an object of ridicule, and no matter how many workarounds may be needed due to other bugs outside our responsibility, this should get a timeline and be fixed, by the main developers of TB. Blake, why not land your addon into the core? Are there any UX problems with the addon behaviour?

Jim, ^^?

(In reply to Blake Winton [On vacation until Jan 9th] (:bwinton - Thunderbird UX) from comment #33) > Thomas, > I've created a simple addon that does the obvious, and not-really-correct > thing. You can find it at > https://addons.mozilla.org/en-US/thunderbird/addon/resize-header/ > > It's not what we want to land in Thunderbird, but perhaps it will tide you > over until we get the developer time to fix the bug in the proper way. Thomas, Blake said the fix is "not correct". That's what prevents it from going into core, and that should not be overridden. He created an addon specifically for you. If this bothers you so much, why don't you take over maintenance the addon? Personally, this problem hasn't bothered me at all, so I don't think you need to warn your friends about it upfront.

In any case, the "proper" fix for this pretty much requires getting seamless iframes implemented in Gecko so that we can just make the header scroll with the message. Once we get that, a lot of our problems will vanish. I know protz was working on seamless iframes, but I think he's pretty busy at the moment (as am I).

Agreed. That'd be bug 80713, and it's actually making progress, as squib said, so there's hope.

Nevermind, bug 80713 doesn't help, because we don't want the pane to grow without limit, reducing the message content to almost nothing - that was the bug that bug 525302 fixed. Rather, we need a proper fix for bug 525225 (which this bug already depended on). Sorry for the confusion.

What I'd like to see is a way to totally collapse the *entire* header, then have way to simply pop it up in a panel (overlayed on top of the message list pane) on mouseover of either the header divider (this is how the Mailtweak extension does it, except it doesn't use a panel, so it causes the content to move when it pops down) or optionally, a little icon. You can see a short shockwave video of what I'm describing here: http://www.web2test.net/Minimal_UIs.swf First, you'll see how the Treestyle Tab uses a panel overlay when displaying the Tab bar (which is on the left side) so the tab bar is displayed in a panel overlayed onto the pages content. Then you'll see Thunderbird with the Mailtweak extension set to auto show/hide the Account/Folder pane and the Message Header. This extension has been unsupported for some time and no longer works in recent Thunderbird builds so I can't use it any more, and like I said, it is not the best implementation because it doesn't use panel overlays, which causes the content panes to get pushed around when the Folder pane and/or the Header panes are displayed. I've already made a Feature Request to the Compact Header extension author and he said he'd look into implementing this...

It just seems to me that we are "barking up the wrong tree here" Most of the problem revolve around integrating the header view into the message view. Why should it be integrated at all, at least in the complex case of "view headers all" My thoughts are that a popup window showing all the headers would be a much better approach. After all, we don't expect "view message source" to be included as a main viewing feature. A simple button to raise a window to display all headers should work fine in lieu of the more button.

> It just seems to me that we are "barking up the wrong tree here" > Most of the problem revolve around integrating the header view into the message view. Sorry to say, but you are indeed at the wrong tree :-). Your tree is: bug 464309 / bug 9942. > My thoughts are that a popup window showing all the headers would be a much > better approach. ... A simple button to raise a window to display all headers ... In normal header mode, you can already do Ctrl-U and see the message source.

(In reply to Ben Bucksch (:BenB) from comment #42) > (In reply to Blake Winton [On vacation until Jan 9th] (:bwinton - > Thunderbird UX) from comment #33) > > Thomas, > > I've created a simple addon that does the obvious, and not-really-correct > > thing. You can find it at > > https://addons.mozilla.org/en-US/thunderbird/addon/resize-header/ > > > > It's not what we want to land in Thunderbird, but perhaps it will tide you > > over until we get the developer time to fix the bug in the proper way. > > Thomas, > > Blake said the fix is "not correct". That's what prevents it from going into > core, and that should not be overridden. > The hint is in bug 526478 : if one will add #msgHeaderView, #msgHeaderViewDeck { max-height: 450px !important; } in userChrome.css, Blakes resize-headers extension works fine in newer TBs where max-height should be adjusted to your own requirements! (tested around in 14.0 beta).

(In reply to Thomas D. from comment #40) > walk up to my friends and say: Look, here's the coolest mail reader, but, > uhm, well, it will never show more than, uhm, 3 recipients at a time, and > when you click to see MORE, you'll actually see LESS... :( We are making TB Actually, this does show more for me. The trouble is, there is no "less" button, so there is no way for me to toggle it back. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 ID:20120713141924 Hope this helps.