Closed Bug 32055 Opened 22 years ago Closed 21 years ago

Can't read (scroll) message when there are too many addressees


(SeaMonkey :: MailNews: Message Display, defect, P2)



(Not tracked)



(Reporter: jar, Assigned: gayatrib)




(Whiteboard: [nsbeta3+][UE1][PDTP2])

In the end, I figured out how to work around this problem, but a newbie could be
quite frustrated.  This is not a beta stopper... but I think it surfaced some UI

a) Get a message, and click on the "expand the list of addressees".  This is the
little triange at the end of an address list.
b) Click to read the next message (or perhaps delete the current message).
c) The next message appears with its list expanded.  Specifically, the
"expand/contract" on the message pane is "Remembered" from message to message.

If you get "unlucky," and your next email message has a LOT of addressees, then
it will take up the ENTIRE message pain.  This will mean that:

d) You can't click on the "contract" list of addressees, because it is off screen!!!
e) You can't see *any* of the body of the message, because not even the scroll
bar for the message body is visible :-(

There are several UI questions to consider:

1) Should expand/contract be remembered across messages?
2) Should the "contract" icon be to the left of the list so that it is
accessible when the list is "really long?" (rather than being off screen :-( )
3) Should it be possible to scroll the address list? (There are no scroll bars,
so you can't see more than a screen full of addresses no matter what). One
option would be to limit the size of the address portion to 50% of the message
3) Should the address list scroll with the message (so that we don't preclude
reading messages when the address list is large!).

Yes, someone actually sent me a message with a VERY large list of names... and
yes... it was a pain to deal with (go to previous message, colapse list, go back
to next message, read now visible text :-/ ).


Reassign to mscott
Assignee: phil → mscott
QA Contact: lchiang → laurel
*** Bug 33574 has been marked as a duplicate of this bug. ***
The envelop area should scroll with the message.  This was agreed upon a long 
time ago and is stated in the UE spec. (Let me know if people disagree and want 
to revisit this issue).

This eliminates the complexity of potentially 2 scroll bars in the message area 
(yuk) and having to remember whether the envelop area was expanded or collapsed 

It also allows the user to scroll the header info out of the way and be able to 
view more of the message.  Once the user has read the header info, they don't 
need to always be able to see it as they read the message.

I don't disagree with that proposed functionality. But unfortunately it is
current impossible to make the headers scroll with the body because the body
lives in its own iframe. The headers are in a separate area. I've talked to
evaughan and hyatt about this before and they have both told me that it will not
be possible to implement this as long as the body is in a separate iframe and it
needs to be in that iframe for security reasons because the iframe forms a
sandbox around the message body. =(

Hmm... if you can't put the two iframes into a mutha-scrolling-region, the
barest of minimum fix for this would be to make the "expand/contract triangle"
more available.
Specifically, the little triangle that expands and contracts the list of
addressees is located at the *end* of the line *only*.  When the line is too
long, the contract triangle is not on screen :-(.  I'd suggest that when the
addressees list is expanded, that there be a contract triangle at the *start*
and at the *end* of the addressee line.
It probably still makes more sense to *only* have the expand triangle at the end
of the compact line.

I'm amazed that the two iframes can't fit into a larger scrollable region... oh
Target Milestone: --- → M17
Keywords: nsbeta3
Target Milestone: M17 → M18
*** Bug 9942 has been marked as a duplicate of this bug. ***
*** Bug 42030 has been marked as a duplicate of this bug. ***
I'm also amazed that our FE infrastructure won't support such a straightforward
interface, and one which has been the spec for several years now.  Even if it's
too late to go back and fix the infrastructure for 6.0, I hope we plan to do it
for 6.1 since those headers really take up a lot of message real estate compared
to 4.x.
OS: Windows NT → All
Hardware: PC → All
Per bunch of folks talking about beta3 bugs - Suggestion: bound the vertical 
size of the addressee list so that very long lists (rare) have a scroll bar on 
the right. If too difficult, would go with putting the twisty on the left.
Keywords: mail2
Whiteboard: [nsbeta3+]
+ per mail triage
Keywords: UE1
Whiteboard: [nsbeta3+] → [nsbeta3+][UE1]
Just thinking loudly:
What about putting the iframe (sandbox) with the message in an outer iframe 
which contains both the headers and the iframe with the message. The inner 
iframe should then be as big as necessary to display the full message without 
scrollbars and the scrollbar (if necessary) should be on the outer iframe.

| Headers    |^|
|____________| |
||          || |
|| Message  || |
||          || |

P1 per mail triage
Priority: P3 → P1
I hope this gets fixed. At 800 x 600 with View -> Headers -> All set, there are 
4 - 6 lines of actual message text available. Having an 800 x 600 window open 
and only seeing 4 lines of the message is not acceptable.
PDT downgrading to P2
Priority: P1 → P2
Whiteboard: [nsbeta3+][UE1] → [nsbeta3+][UE1][PDTP2]
per putterman, gayatri is working on this so reassigning to her.
Assignee: mscott → gayatrib
Depends on: 52246
Per a conversation with selmer today, the solution that is being implemented is 
putting a twisty on the left side so that if the list of recipients is expanded, 
there is always a way to collapse the list.

If I expand the list and then move onto the next message, is that list of 
recipients also expanded (if there are enough recipients that the list needs to 
be expanded)?
It would be expanded, and the twisty would be there too--if you wish to compress 
it back again.
No longer depends on: 52246
Fix checked in. If there are 15 or more emails addresses in to/cc fields, the 
toggle button now comes up at the beginning of the list, rather than at the end 
of the list.
Closed: 21 years ago
Resolution: --- → FIXED
expand/collapse widget appears at beginning of header line for long (15 and
over) header line.

OK uisng 2000-09-15-08 commercial build linux rh6.0
OK using 2000-09-15-05 commercial build NT 4.0
OK using 2000-09-15-04 commercial build mac OS 9.0
Is this really fixed? See bug 56825.
Keywords: UE1
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.