Open Bug 522278 Opened 10 years ago Updated 10 years ago

Header pane does no longer expand, shows scroll bar instead when opening address lists

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: rsx11m.pub, Assigned: mnyromyr)

References

Details

(Keywords: polish, regression)

Attachments

(2 files, 1 obsolete file)

This is a follow-up to bug 517924, which introduced a vertical scroll bar for #expandedHeaderView to allow scrolling of large header content. As a side effect, this does no longer expand the header pane when opening an address twisty, but displays the scroll bar instead. Reverting the fix for bug 517924 doesn't reintroduce the old behavior of expanding the header pane when opening a twisty, it will just cut off the excess content.

Since the corresponding Thunderbird bug 511408 has been deferred to TB 3.1a1, I'm filing this to find an acceptable solution which can still make it into SM 2.0 (or 2.0.1). Given that the header pane implementation is now different between SM and TB, an independent solution could be found here (and maybe contribute to TB later).

The suggestion is to combine old and new behavior, thus allowing the header pane to vertically expand until the max-height defined for #expandedHeaderView is reached, and only then show the scroll bar (e.g., for very long To or Cc lines, or for View > Headers > All).

Steps to reproduce:
1. Look at a message with lots of recipients;
2. open the "To:" or "Cc:" twisty to expand;
3. header-pane height unchanged despite max-height allowing more.

This a major issue for users receiving routinely messages with large address lists, involving two steps (opening twisty + scrolling) to view them all.
Flags: wanted-seamonkey2.0?
Flags: blocking-seamonkey2.0.1?
Duplicate of this bug: 522439
Boxes with overflow-x set to hidden will clip, thus they don't flex vertically, hence we need to do it manually.
Assignee: nobody → mnyromyr
Status: NEW → ASSIGNED
Attachment #407843 - Flags: superreview?(neil)
Attachment #407843 - Flags: review?(philip.chee)
Comment on attachment 407843 [details] [diff] [review]
set min-height on overflow

Nice try but this just causes an infinite loop (setting the min-height makes the box stop overflowing...)
Attachment #407843 - Flags: superreview?(neil) → superreview-
Comment on attachment 407843 [details] [diff] [review]
set min-height on overflow

This causes the height of the expanded header pane to oscillate rapidly. The header pane scrollbar appears/disappears continuously and the content pane bounces unpleasantly. I got a bit dizzy testing this patch out. Sorry.
Attachment #407843 - Flags: review?(philip.chee) → review-
The issue here is that the overflow container makes its contents reflow with infinite width first and then calculates its preferred height based on that.

I can, with a bit of fiddling, make the preferred height increase whenever you expand a twisty. However, it won't decrease again when you collapse a twisty, because the box is flexible and therefore likes to stay the same height. I'd also need to reset the height when the expanded view is reset.
Attached patch Unacceptable patch (obsolete) — Splinter Review
The problem with this patch is that I had to add align="center" to the expanded header box, which causes problems with the attachment pane. (This patch also does not have the "reset header height" code.)
Attached patch Possible patchSplinter Review
As discussed, this patch can't correctly shrink the header view.
Attachment #407980 - Attachment is obsolete: true
Following the related discussion in Thunderbird bug 525302 and bug 489609, the main problem appears to be a XUL Core issue tracked in bug 492645. The solution they came up with for a workaround is a conditional CSS for the overflow rules, which is switched on and off as needed. They don't have the problem of needing to shrink the header pane again when the twisty is closed though, their "more" button doesn't allow that any more.

Consequently, the options here are to either: (1) retain the current scrollbar behavior and wait for a fix in bug 492645, then do it right; (2) back out the scroll bar established in bug 517924 and wait for the XUL issue to be fixed; or (3) to go with a feasible compromise solution like attachment 407983 [details] [diff] [review].

Personally, I'd prefer (3) over either (1) or (2) as long as the header-pane height is reset to normal when leaving and coming back to the message.
Not blocking things on this. The header pane not taking the whole message pane any more is positive, but it probably should be allowed to expand to a certain extent. A patch that helps everyone would be nice, of course!
Flags: wanted-seamonkey2.0?
Flags: blocking-seamonkey2.0.1?
Flags: blocking-seamonkey2.0.1-
Duplicate of this bug: 533678
You need to log in before you can comment on or make changes to this bug.