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 issues. 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 pane). 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 :-/ ). Thanks, Jim

Reassign to mscott

*** 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 previously. 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. http://gooey/client/5.0/specs/mail/messenger/messenger.html#Envelope

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 well....

also tied to http://bugzilla.mozilla.org/show_bug.cgi?id=9942

*** 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.

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.

+ per mail triage

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 || | || || | ||__________||v| ----------------

P1 per mail triage

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

per putterman, gayatri is working on this so reassigning to her.

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.

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.

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.

Mass removing self from CC list.

Now I feel sumb because I have to add back. Sorry for the spam.