Open
Bug 522278
Opened 16 years ago
Updated 15 years ago
Header pane does no longer expand, shows scroll bar instead when opening address lists
Categories
(SeaMonkey :: MailNews: Message Display, defect)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
ASSIGNED
People
(Reporter: rsx11m.pub, Assigned: mnyromyr)
References
Details
(Keywords: polish, regression)
Attachments
(2 files, 1 obsolete file)
|
1.88 KB,
patch
|
philip.chee
:
review-
neil
:
superreview-
|
Details | Diff | Splinter Review |
|
1.23 KB,
patch
|
Details | Diff | Splinter Review |
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?
| Assignee | ||
Comment 2•16 years ago
|
||
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 3•16 years ago
|
||
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 4•16 years ago
|
||
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-
Comment 5•16 years ago
|
||
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.
Comment 6•16 years ago
|
||
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.)
Comment 7•16 years ago
|
||
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.
Comment 9•15 years ago
|
||
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-
You need to log in
before you can comment on or make changes to this bug.
Description
•