240263 - Long 2nd Email Addy in 'To:' pushes scroll bar off Message Window

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Phil Miller]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040401 Debian/1.6-4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040401 Debian/1.6-4

In an email message in which a second email address in the 'To:' field exceeds
some length (not sure of exact minimum), the scroll bar on the right-hand side
of the window is no longer visible, even with the window maximized.

Reproducible: Always
Steps to Reproduce:
1. Open a message with a long 2nd recipient address
2. Look at right-hand side of window
Actual Results:  
The scroll bar is not visible, necessitating mouse wheel usage to move through
the message.

Expected Results:  
Wrapped or truncated the too-long address.

I will attach the message that exhibits this.

Comment 1

[Phil Miller]

Attachment: A message exhibiting this behavior

Comment 2

[Mike Cowperthwaite]

See also bug 188138.

If you add the following lines to userChrome.css, this problem is mitigated:

/*
 * Make the message header view pane scrollable
 */
 #msgHeaderView {
   max-height: 14em !important;
   overflow: auto !important;
 }

You can set the max-height as desired, or even omit it; it simply limits the 
height of the envelope panel when a lot of lines are being displayed (e.g. when 
View | Headers | All is selected).

*** This bug has been marked as a duplicate of 91662 ***

Comment 3

[Phil Miller]

(In reply to comment #2)
> See also bug 188138.
This has nothing to do with either attachments or the 3-pane view, but simply
how ANY message display is layed out. Neither does this case exhibit 'jiggling'
of any UI elements. Both 188138 and 91662 associate this issue with those
additional complexities in their summaries, which is why I submitted a new bug
without reading down 300+ comments between those.
So, please either adjust their summaries, or reopen this bug as the base case of
the other 2.

> If you add the following lines to userChrome.css, this problem is mitigated:
> 
> /*
>  * Make the message header view pane scrollable
>  */
>  #msgHeaderView {
>    max-height: 14em !important;
>    overflow: auto !important;
>  }
> 
> You can set the max-height as desired, or even omit it; it simply limits the 
> height of the envelope panel when a lot of lines are being displayed (e.g. when 
> View | Headers | All is selected).

What has the height of the header panel got to do with anything? The width is
what's causing the problem.

> *** This bug has been marked as a duplicate of 91662 ***

See above. I believe this is not a strict duplicate of the above, because it
describes the general case, of which 91662 is a specific example.
Therefore, I'm reopening this, pending appropriate adjustment of the other 2 or
a solution to the whole ball of wax.

Comment 4

[Mike Cowperthwaite]

You're right, the height doesn't have anything to do with adjusting for this 
bug; the overflow rule is sufficient for your bug.  The height does mitigate the 
problem of the related bug 41994.

You're wrong about everything else.

Comment 5

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 6

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420