Closed Bug 240313 Opened 21 years ago Closed 17 years ago

Put 'overflow:auto' into Envelope Panel CSS by default

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 223132

People

(Reporter: mcow, Unassigned)

Details

Attachments

(1 obsolete file)

For a while, there has been, floating around the newsgroups, a CSS tweak for the envelope panel to be added to userChrome.css: #msgHeaderView { max-height: 14em !important; overflow: auto !important; } This has been suggested as a way to prevent the envelope panel from squeezing the body content out of the window in the View|Headers|All mode (see bug 41994). The overflow rule also mitigates the problems in bug 91662, since the overflow also provides a horizontal scrollbar when the headers contain very wide address information (e.g. attachment 145897 [details] from bug 240263). I've noticed one drawback: the way that overflow:auto is handled is a little squinky. If you've got an envelope panel which is well within the maximum height (if any), but requires a horizontal scrollbar, the box does not expand to provide space for the scrollbar, so a vertical scrollbar is also displayed where it really shouldn't be needed. Using the max-height for the envelope panel isn't ideal either; it's not possible to set that height via a percentage (because there's no specified height for the containing window), so a vertically-narrow message window still has the problem where an envelope panel can squash the message body (and the status bar), and even have the bottom edge of the window encroach into the envelope panel space, without generating a scrollbar for the envelope. Still, I think these drawbacks are pretty minimal compared to the fairly major UI problems seen in bug 91662, bug 188138, and to a lesser extent bug 41994.
This needs moa.
CC'ing Ben, who is bravely going forth to do battle with bug 91662.
I discovered something -- maybe old news. Prior to the fix for bug 63654, a message with a long To: header would cause the panel width to expand (3pane, normal layout) to the point of pushing the splitter to the left; however, a message with a long From: header would simply be clipped by the right edge. (I don't know if this distinction was ever drawn in bug 91662, and I'm not going to go read it again to find out.) With the fix in place, both types of header are clipped on the right; the splitter remains fixed. With the suggested overflow rule in place, the scrollbar appears for the case with the long To: header, but not the long From: header (both with the pre-fix 1.6 and the post-fix 1.8).
Almost but not quite. With the old code, both types of long header would cause the panel to expand. Eventually the entire message area would drop off the right of the window. Then I changed it so that the From header would have its own scrollable region so it's not really clipped, you can click in it and press end etc. Then Stefan changed it so that the folders have fixed width which also stops them from getting squeezed by a long To header.
(In reply to comment #4) > With the old code, both types of long header would cause the panel to expand. "Old" meaning, before you made this change you're talking about? What's the last milestone build before that patch went in? > Eventually the entire message area would drop off the right of the window. What? I don't know what you mean by this sentence. > Then I changed it so that the From header would have its own scrollable region > so it's not really clipped, you can click in it and press end etc. I don't see this either. Altho you can click on the From, you can't put the keyboard focus onto it. (Are you sure you don't mean the SUBJECT? Because that *did* change, around 1.4 I think; Subject header can take focus, and can scroll within its own region.)
(In reply to comment #5) >>Eventually the entire message area would drop off the right of the window. >What? I don't know what you mean by this sentence. What I mean is that it expanded so much that it got clipped on the right. >Are you sure you don't mean the SUBJECT? Yes, I meant the subject :-[ I just tried and really long from and to headers seem to have the same effect.
(In reply to comment #6) > I just tried and really long from and to headers seem to have the same effect. If you're using 1.7/1.8, and don't have the CSS overflow rule, then yes, they both will appear the same. With 1.6, and I see the long To: push the splitter over, but not the long From:. With any version with the CSS overflow rule, I see the horizontal scrollbar for the long To: header, but not the long From:.
Right, Stefan fixed the splitter effect by unflexing the folders.
I get the feeling we're talking past one another, Neil. The CSS rule proposed in this bug still mitigates (by providing a horizontal scrollbar on the panel) the problem of the header being so long it can't be read entirely, and more important, of the Attachments box being pushed off the right -- but only for a long To: (or CC:) header. A long From: will still exhibit both those problems. Possibly this difference should be its own bug. The difference, looking at the envelope with the DOM inspector, must have to do with the differing structures of |mail-multi-emailHeaderField| and |mail-emailheaderfield|. I'll bet a long Reply-To: would behave the same as a long From: since it's also shown in a |mail-emailheaderfield|. (Incidentally, I believe there's an old bug about supporting multiple addresses in From: which is apparently legal in the RFC.)
Product: Browser → Seamonkey
Moving my front-end RFEs from MailNews to Thunderbird (sorry for spam)
Component: MailNews: Main Mail Window → Mail Window Front End
Product: Mozilla Application Suite → Thunderbird
Version: Trunk → unspecified
See bug 9942, which should fix this bug.
Bug 223132 comment 92 put forth the suggestion of applying the rules to a different element in the structure: #expandedHeaderView The claim is that using this element rather than #msgHeaderView prevents lines across the background (there's a screenshot there to show what is meant by this). So I've been testing this. As part of the testing, I'm seeing that the chrome in the 2a1 and 3a1 builds is somewhat better behaved than that in the 1.5 release. With 1.5, using the proposed CSS on either element with the 'normal' headers (four lines) always results in a vertical scrollbar that scrolls about one pixel; this no longer happens with the nightlies. Additionally, I see that by using #expandedHeaderView, the 1px black border at the bottom of the envelope is not included in the scrolling area -- instead, it's always visible [1]. This is an improvement. There are still a few glitches in the "Normal Headers" mode, but they're minor and somewhat obscure: - I have occasionally, but not consistently, seen a disabled horizontal scrollbar appearing in the first standalone window opened in a session, when no horizontal scrolling is called for; but that disappeared on resize or on opening another message. Other than that, the horizontal scrollbar shows only if the To, From or CC headers are wider than the envelope panel. - At least once, I've also seen a disabled vertical scrollbar in a case where no vertical scrolling was necessary. - Viewing a message with a To: or CC: header with enough addresses to wrap to two or more lines results in some peculiar scrolling behavior which affects subsequent views of a typical four-header message: these latter messages are displayed with one or more extra, blank lines in the envelope which force a scrollbar, even tho there's plenty of room to expand the envelope within the max-height parameter. (Note that this same message results in a symptom v. similar to bug 262875 / bug 174613, but in those cases the symptom doesn't carry over to other messages.) If it weren't for this last point, I would be comfortable saying that, with whatever changes went into the chrome for 2.0, adding this CSS would be a big improvement; bug 223132, one of TB's most-duped, would go away. [1] There is actually a glitch here, too, but it's unrelated to this CSS: if a message has more than four headers shown in the envelope (with Normal headers display), the black border is not shown at all. However, if the envelope is ever collapsed to Brief headers mode, and then re-opened, the black border is shown for 5-or-more header messages thereafter.
Assignee: sspitzer → mscott
QA Contact: esther
- Viewing a message with a To: or CC: header with enough addresses to wrap to two or more lines results in some peculiar scrolling behavior which affects subsequent views of a typical four-header message: these latter messages are displayed with one or more extra, blank lines in the envelope which force a scrollbar, even tho there's plenty of room to expand the envelope within the max-height parameter. (Note that this same message results in a symptom v. similar to bug 262875 / bug 174613, but in those cases the symptom doesn't carry over to other messages.) I think I might know what causes this bug: the use of collapsed="true" conflicts with the display: inline; style on the email addresses.
This change would also mitigate the problem at bug 247833.
Version: unspecified → Trunk
Per comment 12: I've been running with the 'new' CSS and have been pretty happy with it in general. I have noticed, however, that with the envelope panel now showing the 'Tag' header, when I switch from a tagged to an untagged message, I'm seeing a disabled horizontal scrollbar along the bottom of the panel, hiding the fourth header header line, and forcing a vertical scrollbar to scroll that line into view. This is just a variant on an earlier-seen problem, but one that's easy to reproduce.
(In reply to comment #12) > [1] There is actually a glitch here, too, but it's unrelated to this CSS: if a > message has more than four headers shown in the envelope (with Normal headers > display), the black border is not shown at all. However, if the envelope is > ever collapsed to Brief headers mode, and then re-opened, the black border is > shown for 5-or-more header messages thereafter. Bug 259255 is about the missing border line.
Following up on this subsequent to the changes for bug 335973, which went in in July. (In reply to comment #12) > There are still a few glitches in the "Normal Headers" mode, but they're > minor and somewhat obscure: > - I have occasionally, but not consistently, seen a disabled horizontal > scrollbar appearing in the first standalone window opened in a session > > - At least once, I've also seen a disabled vertical scrollbar in a case > where no vertical scrolling was necessary. I no longer see the horizontal scrollbar at all, except for certain pathological cases involving a test messages from bug 355232 and bug 340327 (see #3 below). A long address header (single or multiple entry) no longer triggers the display of the scrollbar. > - Viewing a message with a To: or CC: header with enough addresses to wrap > to two or more lines results in some peculiar scrolling behavior which > affects subsequent views of a typical four-header message: these latter > messages are displayed with one or more extra, blank lines in the envelope > which force a scrollbar, even tho there's plenty of room to expand the > envelope within the max-height parameter. I no longer see this either. > If it weren't for this last point, I would be comfortable saying that, with > whatever changes went into the chrome for 2.0, adding this CSS would be a big > improvement; bug 223132, one of TB's most-duped, would go away. (In reply to comment #15) > I have noticed, however, that with the envelope panel now > showing the 'Tag' header, when I switch from a tagged to an untagged message, > I'm seeing a disabled horizontal scrollbar along the bottom of the panel No longer seeing this, either! The glitches I see now are: 1) If a long multi-address To: or CC: header is expanded, the height of the panel does not change; instead, a scrollbar appears, and you have to scroll down to see the rest of the addresses. 2) When a given envelope is instantiated (first 3-pane, each non-cached standalone window), if the message does not have a tag, there is no scrollbar (with normal headers displayed). When you then view a message with a tag, the panel height increases, and there still is no scrollbar. However, whenever you go back to a message that doesn't have a tag, the panel height decreases, but there is a scrollbar that lets you scroll one header's worth of height -- for the invisible (or empty) Tag header, I presume. This unnecessary scrollbar is present henceforth on all untagged messages. 3) The pathological cases of bug 355232 and bug 340327: This is tedious, but bear with me. - With *no* overflow control in the panel (that is, this CSS not present), when you view one of those messages with an address header that will not wrap, there is a twisty displayed. Expanding the twisty causes the symptoms described at those bugs (message body scrollbar pushed beyond window border, column widths in thread pane expanded). - With scrolling overflow, expanding the twisty causes a horizontal scrollbar that actually hides the lower header -- which means it could hide the twisty, preventing you from un-expanding the header. However, in this case, the symptoms from those bugs do not occur. - If the overflow-x control is changed to HIDDEN, expanding the twisty in these pathological cases does nothing. No horizontal scrollbar, no change in panel height, and no bug symptoms. I think this is ready. Patch forthcoming.
Despite the glitches described in comment 17, I think this is a huge improvement over the problems of bug 223132 -- one of TB's most-duped and most-despised bugs. This patch fixes that bug, bug 234078, and the symptoms at bug 355232 and bug 340327. The CSS will need to be ported to pinstripe, too, I assume.
Attachment #253500 - Flags: superreview?(mscott)
Attachment #253500 - Flags: review?(mscott)
Scott, are you not interested in this for 2.0? I know it's not perfect, but I really think it's a serious improvement.
QA Contact: front-end
This bug needs Triage for a new Assigned To: Nominating Wanted Tb 3.0 I suggest we land this for bakeing to see what side effects crop up.
Flags: wanted-thunderbird3.0a2?
I'm tempted by this one, but i don't know that I get all the consequences yet.
Assignee: mscott → nobody
Flags: wanted-thunderbird3+
This is one of two related bugs for scroll bars in the header pane so we can control the amount of real estate the pane uses. Comment #0 presents the CSS that has been adopted by many to set a fixed height to the expanded header pane and get scroll bars when the height is less than the height needed by either Normal or All headers. A variant of this CSS applies it to the Expanded view of the header view deck. With ether variant, this works well and is the easiest improvement to apply. We add the CSS to the default theme and 3rd party themes will pick it up from there. What is more problematic are horizontal overflow scroll bars. The impact to Header pane is the same result that hits <Form> Text Boxes. This indicates a problem in the core code. Basically with text boxes, the issue is reservation of vertical space for the scroll bar which leads to the quirky behavior noted in Comment #0. Therefore I believe what We should check in would be use of {overflow-y: auto;} instead of the bidirectional {overflow: auto;}. I see the vertical height as the most important behavior to fix. As to horizontal, that is going to need some code work and here is why I think that. At present we can read long header lines by clicking the cursor on the line and using the End and Home keys to scroll the line. A common line involved is the News feed path from posting host through to the serving host. This line will not break due to no breaking spaces. So it is clear that the header box has a Clipping Box that defines the view area while the content flows to it's full length "Off Screen". A users choice of system fonts and sizes will alter the portion visible. Other headers effected include x-trace and references. In the case of references there are break points and the code should apply format=flowed and break to a new line.
(In reply to comment #22) > Therefore I believe what We should check in would be use of > {overflow-y: auto;} instead of the bidirectional {overflow: auto;}. Did you look at the patch?
The (In reply to comment #23) > (In reply to comment #22) > > Therefore I believe what We should check in would be use of > > {overflow-y: auto;} instead of the bidirectional {overflow: auto;}. > > Did you look at the patch? > The patch in attachment 253500 [details] [diff] [review] needs to be updated. The class .headerNameBox could not be found with DOMi in Tb 2.0.0.14.
Go ahead and update it. Note how much traction the original patch got. Note the reaction in comment 21, where the poster is unwilling to edit his own chrome.css file to try it out. This bug is still open because of FUD. Why should I put more effort into it? My point was, your suggestion seemed to have missed the fact that I already was aware of, and implemented, using overflow-y; plus, I believe my overflow-x rule is more useful than leaving it set to the default.
Okay, then since I've been assuming the only difference between this and bug 223132 was that this was your less-noisy place to work, I'm duping over there (sorry about the resulting cc, but you know how to take care of that). Thanks for all the investigation of consequences, it's going to be a big help figuring out what to do there.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: wanted-thunderbird3.0a2?
Flags: wanted-thunderbird3+
Resolution: --- → DUPLICATE
Attachment #253500 - Attachment is obsolete: true
Attachment #253500 - Flags: superreview?(mscott)
Attachment #253500 - Flags: review?(mscott)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: