Closed Bug 9942 Opened 25 years ago Closed 1 year ago

Message headers don't scroll with the message

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: akkzilla, Assigned: BenB)

References

(Depends on 1 open bug, Blocks 3 open bugs)

Details

(Whiteboard: [ue1])

Attachments

(7 files, 6 obsolete files)

Screenshot explaining why this is needed.
66.06 KB, image/png
Details
Screenshot showing some problems with the current patch
31.90 KB, image/png
Details
Screenshot showing another problem of the current patch
37.92 KB, image/png
Details
Fix, version 5. Trunk.
5.27 KB, patch
Details | Diff | Splinter Review
Screenshot of fix v4
105.01 KB, image/jpeg
Details
Fix, version 5. Against 1.7.6.
4.70 KB, patch
Details | Diff | Splinter Review
Screenshot showing buttons in header
28.40 KB, image/jpeg
Details 
The message header frame above the message frame is bigger than it needs to be
to show the headers; resizing the mail window or dragging up on the sash between
the thread pane and the msg pane resizes the header frame bigger as well as
resizing the message pane, resulting in a lot of empty space below the headers
which could be used for showing more of the message.

Also, a discussion in mozilla-mail-news seemed to reach general agreement that
everyone wanted the headers to scroll with the message, but they don't do that
now, and there doesn't seem to be a bug tracking that problem yet.

Taking a guess at alecf for the owner because this seems related to 4563 and
maybe Alec is already looking at these issues.
Summary: msg headers take up too much space and don't scroll with message → [DOGFOOD] msg headers take up too much space and don't scroll with message
Oh, forgot to mention the other problem: you can drag the sash between the msg
headers and the message body to resize the header area smaller, but as soon as
you load a new message the header frame resizes back to its previous too-big
size.  It should remember the size the user gave it.
QA Contact: lchiang → nbaca
Assigning QA to nbaca.
this is a very hard problem to solve but it has to be fixed.
I don't think I can do it for M9, but we definately should for M10. I was
waiting to tackle this for some of the intrinsic sizing stuff that may have been
implemented recently.
Status: NEW → ASSIGNED
Target Milestone: M10
Blocks: 11091
Adding rich because this might be all MIME stuff at this point.
I think I've done all the 3-pane XUL work. Rich?
Yeah, I'm working on getting XUL involved in how we display messages and a lot
of this will change once that is done.

- rhp
Assignee: alecf → rhp
Status: ASSIGNED → NEW
I'm just going to reassign this to rich, because I've seen his work on this.
Status: NEW → ASSIGNED
As of tonight (August 10) I checked in changes that will start displaying
messages as a mixture of XUL and HTML. This makes the headers looks much more
like the UI specs.

Currently, the feature is on a pref and can be activated via:

            user_pref("mail.mime_xul_output", true);

NOTE: I know that it works on windows for a few messages and then there is a
bug in layout that crashes. On linux, it crashes before display and I haven't
tried MAC, but I hope to get these fixed in the next week.

- rhp
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 10882 ***
Status: RESOLVED → VERIFIED
verified dup...see Bug 10882
Status: VERIFIED → REOPENED
I've tried setting this preference, but the message headers still take up too
much space (less than they did before, but still more than in 4.x) and they
still don't scroll with the message.
Resolution: DUPLICATE → ---
Bug 10882 mentions a UI spec which does in fact show the headers scrolling along
with the message.  So I wasn't imagining things, that really was part of the UI
design ...
Summary: [DOGFOOD] msg headers take up too much space and don't scroll with message → [DOGFOOD] msg headers don't scroll with message
Target Milestone: M10 → M14
With respect to the space taken up, I think we match the spec. With respect to
scrolling, the spec says scroll, and that's what we want to do. Rich wasn't
able to find a way to do that before he left for sabbatical. Changing the
summary to reflect the remaining issue, and moving to M14.
No longer blocks: 11091
target milestone is not m11 or m12 so removing this from the mail beta tracking
bug.
Status: REOPENED → ASSIGNED
Summary: [DOGFOOD] msg headers don't scroll with message → Msg headers don't scroll with message
I don't think we need the headers to scroll to be dogfood-ready. Changing the
bug summary to reflect that.
Target Milestone: M14 → M19
We need to look at this down the road, but getting the described behavior has a
lot of downside to it (from an implementation point of view, NOT usability.)

- rhp
Assignee: rhp → mscott
Status: ASSIGNED → NEW
Hi Scott,
This is one of the message display related issues in my list that I thought you
may want to look at when you are digging into the new display approach.

Good luck!

- rhp
Summary: Msg headers don't scroll with message → UI: Msg headers don't scroll with message
Keywords: nsbeta3
Target Milestone: M19 → M18
dup.


*** This bug has been marked as a duplicate of 32055 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
verified duplicate.
Status: RESOLVED → VERIFIED
reopening, this is not a duplicate of 32055, which has been fixed without fixing
this.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 47422 has been marked as a duplicate of this bug. ***
clearing M18 target to get this back on the radar.
Target Milestone: M18 → ---
Keywords: nsbeta3 → 4xp
I like the current way. I see it as similar to window titles. Maybe that's
because I use the standalone msg window, which isn't as space-limited as the 3 pane.

How about always showing (i.e. not scrolling) the minimized (one-row) view of
the header section?
Hmm I'm not sure why this particular bug got re-opened. I'm sure this is a dup
of a another bug. We've been trying to get this to happen for years! This is a
dup of another bug I have somewhere. The bug I'm thinking of talks about all the
engineering problems behind doing this. Last time I talked to evaughan about it,
he said it could takes a little over a MONTH of engineering time on his end to
make iframes know enough about xul to have a xul element scroll with an html
iframe. We've never been able to get the layout engineering resources necessary
to do this. It's not due to lack of effort, the task is just huge. And the
message body has to be in an iframe for security reasons. 
I reopened this particular bug because it was <one of> the first (2+ years ago),
and had been duped against a bug that is now closed, without being resolved.  Do
headers need to be in a XUL element?  Would putting them in an HTML iframe also
facilitate resolving other bugs, such as having their content to be
selectable/copyable?
Headers should be scrollable, selectable, copyable. What "bug fix" caused them
to not be that way now, 10882? Yuck. Message headers are displayed in upper
right pan. Fixed position dupe in body pane is dumb dumb dumb, especially since
not selectable or copyable along with the displayed body.
QA Contact: nbaca → olgam
One should note that bug http://bugzilla.mozilla.org/show_bug.cgi?id=47422 which 
has been marked a dupe of this has received 12 votes; there should be *some*
simple workaround for this for cases where one wants to see the header and still
be able to read the message too. would it be easier to implement
 to just display the complete message including headers in the same scroallable
window and suppress
the header pane in that case altogether? Maybe as a third option "inline" in
addition to "normal" and "all"? Many users ask for that.
Okay, so right now the headers are placed in an hbox that is part of mailnews
chrome, then the actual message display is handled by a browser object with
id=messagepane, correct?  Scrolling is being taken care of by the browser
object, and the difficulty is getting the header display inside of the browser
window.  

Would it be possible to put the header and browser displays within large main
chrome box and then tell the browser to not use a scrollbar for its content?  We
could try to get the browser to expand to display all of its content, but since
the browser (and header) are containted within the main chrome box, the main
chrome box would take care of the scrollbar and the contained header box and
browser window would scroll together.  
IMHO it should be the other way around - headers should become a part of a
browser window. This way it would probably be easier:
- to make headers selecatble
- to turn URLs in the headers (e.g. in the subject) into links
etc.
Look at comment #23.  That's why I suggested this alternate route.
Summary: UI: Msg headers don't scroll with message → Message headers don't scroll with the message
Yeah, but as comment #24 asked, why do headers need to be in a XUL element? Take
a look at how Mozilla shows a document of type message/rfc822 (see for example
attachment 54635 [details] of bug 106189) - it looks pretty nice the way it is, it only
needs the addresses turned into appropriate links...
Well, you loose twisty functionality.  And implementing the box full of
attachments would be a pain if not impossible.  Then you'd also have to make it
skinnable so you wouldn't be stuck with bland gray and light gray.
*** Bug 110258 has been marked as a duplicate of this bug. ***
nominating for nsbeta1
Keywords: nsbeta1
unless evaughan changed his time estimate of 2 months this will unfortunately
end up being a minus for the next release....
Related problem: I have received some E-mails with a few hundred addressees. I
can see three of them by default, but once I click on the little "+", the list
expands. The result is bigger than the full mozilla window. There is no way to
scroll the headers, so I can't find out the rest of the addressees' names, nor
can I read the actual message in this way. Fortunately, the "-" sign to collapse
the list has so far been in reach.....
If this really depends on other work, please file that work as a bug, if it
isn't already, and put its ID in this bug's 'depends on' field.  Is there no
other way to get the 4.x behavior? It seems odd to say it is too hard when most
other MUAs have long worked that way. cc jglick. 
Bug 56825 is a dup or very similar to this bug.
Yes, and it points out a worst case scenario where the product fills the screen
with headers so that you can't see any of the message unless you know how to
collapse the headers.  This doesn't happen often, but I have seen it, even on a
1600X1200 monitor.
Most mail UAs just treat the headers the same way as the rest of the message
text (after filtering out ignored headers).  We could do that too, and it would
solve this bug and many related ones (like "headers not selectable") -- just
make the headers part of the html content of the message window, not xul or a
separate frame or anything.
Blocks: 98889
*** Bug 117332 has been marked as a duplicate of this bug. ***
This bug really needs to be fixed (revert behaviour to NC4.x way) since there
seems to be no good reason to keep the current behaviour from a user's
standpoint. And, "because it would take a lot of engineering effort" should
never be a reason for not doing something that users are expecting (scrolling,
selectable headers.

Is there a good reason why headers should be *always* visible and permanently
take up valuable screen space? Isn't it enough if the user can read the header
when he calls up the message. Isn't it enough the the user can scroll to the top
of the message to read the header if he forgot what it said before he scrolled
the mail down?

Ideally, we could have:
- the headers as part of the body (scrollable, selectable)
- twisties in the header portion to expand/compact large TO, CC, BCC lists.
- An attachment window inside the header like it is now. It just scrolls with
the message. BTW Would it be wrong to put attachments into the body like M$ OE
and Lotus Bloats do it?
- Special buttons in (or above) the header for: "Edit Draft" etc.

I'm pretty sure if this is done, a *better place* for attachments and special
buttons will need to be found ;)
The current solution is really terrible. One consequence seems to be that
it is not even possible to select the text of the Subject with the mouse!
(I tried this with 2001123006 under linux).
Please, just including all headers in the plain text will be much better
than the current solution! If filtering of headers is a whish, it should be
taken from there. 
I dont know if this belongs here, but header filtering seems to happen
when forwarding an email as attachment too. However, there seem to 
be used different rules. No headers are filtered when email is forwarded
inline though.
Keywords: nsbeta1 → nsbeta1-
*** Bug 129286 has been marked as a duplicate of this bug. ***
*** Bug 131178 has been marked as a duplicate of this bug. ***
This bug is a violation of the UE spec, and as such qualifies for mail3. Adding
keyword.
Keywords: mail3
*** Bug 133143 has been marked as a duplicate of this bug. ***
*** Bug 132909 has been marked as a duplicate of this bug. ***
*** Bug 133485 has been marked as a duplicate of this bug. ***
*** Bug 143724 has been marked as a duplicate of this bug. ***
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
*** Bug 154869 has been marked as a duplicate of this bug. ***
Blocks: 158464
*** Bug 159333 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1- → nsbeta1
Whiteboard: [ue1]
Blocks: 160730
+'ing for investigation.  Still may not be possible.
Keywords: nsbeta1 → nsbeta1+
when thinking about this one, also look at the discussion in bug 91662
Suppose that I implemented the ability for IFRAMEs to size to fit their
contained documents. That would make this easy to fix, right?
Robert, I believe that would make this problem very easy to solve. I believe I
had discussions with evaughan a year or two ago and we kept coming to that as
the big log jam. 

Here's the comment I wrote down after meeting with him (see Bug #56825):

evaughan and I aren't sure it's technicall possible to get an iframe to scroll
within a xul box without making core layout depend on XUL. Even then iframes
just don't work in a way where they know things about their parent.

If you can solve that problem then the scrolling part becomes trivial. 
It doesn't seem too hard to make IFRAMEs be able to size themselves
intrinsically based on the size of their content document. This would not need
to create a dependency on XUL. I'll have a look at it.
QA Contact: olgam → laurel
nsbeta1-. If the work needed to implement comments 57 and 58 gets done, then
this would definitely be reconsidered.
Keywords: nsbeta1+ → nsbeta1-
I agree with comment #42: "Please, just including all headers in the plain text
will be much better than the current solution!" Kmail (Linux) can show 4 levels
of header detail including all, and NS 4.x also would show all. I appreciate
being able to adjust settings to do this. Putting headers in a separate
expandable box may look more sophisticated, but it doesn't seem more useful,
especially when the header box (frame?) hogs the screen instead of scrolling out
of sight.
Blocks: 176238
user_pref("mail.mime_xul_output", false); (comment 7) fails to turn off XUL mail
headers. Is there some other pref that gives us back Netscape 4 functionality?

A picture is worth a thousand words.  And don't even think about telling
me to turn off the display of full headers.
I see this issue has been around forever. It's always bothered me.

My vote would be for mail headers in the message pane, but with the window
initially scrolled to the start of the body whenever you select a new message.
Twisties and/or preferences would be useful to select how much of the headers
are shown.

A comparable solution for printing would be helpful too.
I recommend that the severity of this bug be upgraded to major.  I am
occasionally receiving emails which have sufficient headers as to overflow a
1024x768 display.  Without scrolling I am forced to export the email and open it
in a text editor to view the headers.  This is unacceptable, and I suggest
warrants a higher severity rating than 'minor'.
I agree, even normal doesn't seems enough to me.
Well, major seems a little too much to me, after all you can always "view
source" from the program.
... or you can use plain text viewer to view the file holding mail messages.
Of course, there is always way to get what you need. 
However, that is not the way a mail-client should work.
"Always view source" is rather much, considering how easy it was in Netscape 4
and prior, not requiring one to open an additional window for each message. 
*** Bug 222338 has been marked as a duplicate of this bug. ***
This patch introduces a preference "mail.inline_headers". When set to "true",
the headers are not displayed in the separate window anymore, but inline in the
message body. The formatting is the same as when printing the message.
Nice!

I'd like to see it in release!
:)
Just out of interest... how does this work with attachments?
Hopefully, the same way as Netscape 4, as a link at the bottom of the content,
unless the option to show inline is selected.
Comment on attachment 134126 [details] [diff] [review]
pref-dependent inline headers (attachments nowhere to be seen)

you should not make lines grow past 80 columns.
neil's question and mrmazda's response should be addressed.

neil: afaik headers for inline forwarded emails are still wrong, right?

when we offer this, we really need to address the security concerns of (html)
forged headers.
Attachment #134126 - Attachment description: pref-dependent inline headers → pref-dependent inline headers (attachments nowhere to be seen)
Attachment #134126 - Flags: review-
How does non-scrolling headers vs. scrolling headers affect how Mozilla deals
with forged headers?
perhaps the parens shouldn't have been there.

among the many reasons for using xul instead of html was that it prevented the
real headers form scrolling off the screen and the user seeing html which
_looked_ like the real headers but contained something else.
Dude! You mean I have been living everyday for the last few years with that
damned header thing because someone thought a user might mistake some HTML as
headers? Why is this a concern?
*sigh* s/form/from/ (living in html to long have i?)

dude: read what i wrote. especially qualifiers like 'among'.
Comment on attachment 134126 [details] [diff] [review]
pref-dependent inline headers (attachments nowhere to be seen)

innocent as I was, I thought to share some stuff which I started (but never
finished - I should have put a "beta" label on it, shouldn't I?) a year or so
ago, and it seems it was stiring up a hornet's nest :)

> Just out of interest... how does this work with attachments?
it doesn't :(

Not that I really think I will solve what more competent people spent a lot of
time with, but out of pure interest:

> we really need to address the security concerns of html
forged headers.
ehm - where can I read about this?

> among the many reasons
Where can I read about the n-1 other reasons? :)

> it prevented the
real headers form scrolling off the screen and the user seeing html which
_looked_ like the real headers but contained something else
Hmm, I don't see the problem here (at least none that cannot be solved with
formatting, which may be naive of me :), can you explain this?
Attachment #134126 - Attachment is obsolete: true
re comment #76 : I do not think that this ever was very effective in allowing
users to check the real headers. Since the way headers are shown now is so
limited, most users simply show their messages with the header windows
collapsed. That way, they do not see any headers. 

Also, *if* people want to check, it is easily possible with scrolling headers
too - if there is some kind of seperation line or other graphical indication of
the end of the true headers, any faked HTML-header will immediately spring into
the eye. This is even easier if we allow customization of which headers are
displayed and how they are formatted. One should also note that practically all
"real" headers can be forged. 

Comparing the advantages and disadvantages of scrolling headers vs. the current
implementation, scrolling headers are much more user friendly. If there are so
many other reasons for using XUL it might be good to list them, because only
very view people seem to be aware of them.


needs to be reassigned.
re comment #76: timeless could you comment on the many *other* reasons for XUL
headers and tell us how you think the "security concerns" could be addressed and
what your response to comment #80 is?
Blocks: majorbugs
Hi,

Feel free to ignore this, but.. if the message body is HTML, why can't a style
sheet be used to 1) mark headers as different to body and 2) implement an
expand/contract thingy as many web sites do? Surely the twisty is not the only
way to show/hide content? You could even have the attachment box as a bit of
HTML - with HTML 4 you could have it float across the body as the user scrolls.
Is that too crazy?

PS: Huge thanks to everyone who works on Mozilla - just because we users
complain doesn't mean we don't like you, it just shows how much we want your
product to be perfect :)
> why can't a style sheet be used to 1) mark headers as different to body

Because the headers need to have chrome rights to be able to offer special
features like adding to addressbook, showing AIM icon, create filter from msg etc..


UI spec: <http://www.mozilla.org/mailnews/specs/threepane/#Envelope>
"The envelope area should scroll with the message body."


Bug 80713 and/or bug 184155 may be blockers.
*** Bug 241527 has been marked as a duplicate of this bug. ***
*** Bug 242434 has been marked as a duplicate of this bug. ***
*** Bug 244308 has been marked as a duplicate of this bug. ***
I use thhis idea - fixes most of my issues except that the header window is a
fixed size..

Thanks to Bill McCartney.

---

#  How to scroll the full message header in Mozilla Mail

In your Mozilla Profile chrome/userChrome.css file, add the following:

/* Limits View Headers (All) lists and adds scrollbars for overflow. */
#msgHeaderView { max-height: 8em !important; overflow: auto !important; }

Credit: Bill McCartney, Mozilla user.
Blocks: 17623
No longer blocks: 176238
(In reply to comment #88)
> I use thhis idea - fixes most of my issues except that the header window is a
> fixed size..


ste-ve@freenet.co.uk : Please don't change dependencies w/o any comments. 
Why have you removed the dependency with bug 176238 and replaced it with the
imho irrelevant dependency to bug 17623?
Dependencies correction: 17623 -> 176238
Blocks: 176238
No longer blocks: 17623
> /* Limits View Headers (All) lists and adds scrollbars for overflow. */
> #msgHeaderView { max-height: 8em !important; overflow: auto !important; }

Yes, I ended up with a similar version, but IIRC that scrolls only the header
pane on its own, not together with the body, so is only an inferiour fix (but
maybe still an improvement over the current state).
No longer blocks: 158464, 160730, majorbugs, 176238
Blocks: 158464, 160730, majorbugs, 176238
(In reply to comment #89)


> (In reply to comment #88)
> > I use thhis idea - fixes most of my issues except that the header window is a
> > fixed size..
> 
> 
> ste-ve@freenet.co.uk : Please don't change dependencies w/o any comments. 
> Why have you removed the dependency with bug 176238 and replaced it with the
> imho irrelevant dependency to bug 17623?

Apologies if I did do this but unless I inadvertantly hit the del key at the
wrong moment I have no idea how it happened!
I have a rudimentary version of this working! (yay)

I asked bz what needed to be done in Layout to do this properly, and he said
it's definitely more than 1-2 weeks of work (for him), so that was out (for me).

I don't remember correctly, but I think it was Neil Rashbrook who had the idea
to assign the actual inner content height to the XUL element height. That's what
I tried, and finally succeeded. It's basically:
<browser onoverflow="browser.style.height = browser.contentDocument.height + 'px';">
I need to figure out how to do underflow, the same statement there causes a
loop. Apart from this, the bug seems fixed.

Bug 247833 still exists, though, causing msgs with long email addresses to have
a horizontal scrollbar (incl. body). But fixing this bug would be a huge
improvement for that bug, because the msg bodies are currently completely cut
off, without scrollbar.
Assignee: mscott → ben.bucksch
Status: REOPENED → NEW
Priority: P3 → P1
Target Milestone: --- → mozilla1.8alpha2
With your fix, what is the behavior when the envelope is scrolled out of 
visibility and then user does a tab-key cycle around until the focus lands back 
on a field in the envelope (e.g. Subject)?  Rescroll the pane to the top, or 
keep the focused widget scrolled out-of-view?
Attached patch Fix (obsolete) — — Splinter Review 
mscott or seth, please review
This fixes bug 56825 - Ability to scroll long address list in To: or CC: fields
in header pane
Blocks: 56825
Comment on attachment 157371 [details] [diff] [review]
Fix

> +  dump("resizeBodyPane\n");

Please remove/ignore that
Attachment #157371 - Flags: review?(mscott)
Attachment #157371 - Flags: review?(mscott) → review?(sspitzer)
Target Milestone: mozilla1.8alpha2 → mozilla1.8alpha4
I just tested the attached patch a bit, because I'm really looking forward
seeing this bug fixed. :-)

I used a Linux Gtk1 trunk build from today.


Unfortunaly I spotted some severe problems with it (see screenshots):

- The Message Pane doesn't seem to flex vertically anymore. So when you are
viewing a shorter message, you see see background color of the message only in
the area where the message text is. Below that you see the mozilla standard
background color.

- When you make the MailNews window smaller, horizontal scroll bars appear
below the displayed message.

- For longer messages a second vertical scrollbar appears when you make the
MailNews window smaller (See second screenshot I'm going to attach in a
minute).

- The stand-alone message window should also be fixed for consistency (ok,
that's not a problem with the current patch, but something that is just
missing)

Hopefully these issues won't be hard to fix.
This shows the vertical scrollbar issue.
That's not what I'm seeing, but will try to reproduce and fix when I have time.
Attached patch Fix, version 4 (obsolete) — — Splinter Review 
I think I know the reason for at least the latter screenshot. I actually saw
this, too, IIRC, and didn't know where the scrollbar comes from and I had to
use a very ugly hack to make it go away, namely adding 40px to the desired
height. I determined that number experimentially :-(. Because Stefan said that
the scrollbar scrolls only maybe 5px, I used 50px now. If somebody can tell me
what's going on and how to fix it properly, that would be appreciated. See
mailWindow.js::resizeBodyPane().

I am attaching a new patch with a few smaller fixes, incl. a fix for the
standalone msg window.

There are 2 problems let, none of which I consider critical:

> - The Message Pane doesn't seem to flex vertically anymore. So when you are
> viewing a shorter message, you see see background color of the message only
in
> the area where the message text is. Below that you see the mozilla standard
> background color.

Yes, I had to removed the flex, because the body frame height now doesn't have
a relation to the window layout, but is dependent on its content and the frame
scrolls.
I can see 2 alternative fixes:
- Make the background behind the body match the color of the background of the
body pane. If you view an HTML mail (in Original HTML mode) with green
background color, though (*urgs*), there will still be a white part.
- If the inner height of the body frame is smaller than the visible area, set
the height to the visible. But: I don't know how to get the visible area (my
attempt didn't work), you need to get it right *exactly*, and it will be hard
to get it right exactly how and forever, because you'll probably need to use
some kind of workaround.
I don't see how to do that properly. I'd probably just set a white background
color for now.

The other remaining problem is that the header pane doesn't shrink to minimal
size. If you view a msg with only one recipient, the To part is 1 line high. If
you view one with 10 recipients, it's 3 lines high (the rest only after
expansion). If you then view the first msg again, it stays 3 lines high, it
doesn't go back to 1 line. Because it never goes more than 3 lines (2 empty
ones), I don't consider that critical.
Attachment #157371 - Attachment is obsolete: true
I suggested in the last comment:
> - Make the background behind the body match the color of the background of
the
> body pane. If you view an HTML mail (in Original HTML mode) with green
> background color, though (*urgs*), there will still be a white part.

That's what this patch does.

> The other remaining problem is that the header pane doesn't shrink to
> minimal size.

That's probably part of bug 247833, actually.
Attachment #157996 - Flags: review?(sspitzer)
Attachment #157996 - Flags: review?(Stefan.Borggraefe)
Comment on attachment 157996 [details] [diff] [review]
Fix, version 4

Patch still no good. Testing with real-life msgs, I see that I need to adjust
the horizontal space of the body as well, in case the msg has very long lines
which don't wrap (broken plaintext forwarded as HTML by a broken mailer).
Currently, I get a horizontal scrollbar inside the scrolling pane, so the
horizontal scrollbar scrolls out of view vertically. I tried to use the same
trick that I used for the height, but gBody.contentDocument.height seems to
have the wrong value (namely that of the viewport, not the document).

*sigh*
Attachment #157996 - Flags: review?(sspitzer)
Attachment #157996 - Flags: review?(Stefan.Borggraefe)
Is it possible to just add a scrollbar for the headers pane?
sure, but it's very ugly.
Attachment #157371 - Flags: review?(sspitzer)
(In reply to comment #105)
> sure, but it's very ugly.

I don't think so...
At least, it would not be as ugly as the solution of the patch. (2 scrollbars
beside each other...)
(In reply to comment #106)
> (In reply to comment #105)
> > sure, but it's very ugly.
> 
> I don't think so...
> At least, it would not be as ugly as the solution of the patch. (2 scrollbars
> beside each other...)

See comment #88

Regards 
Steve
(In reply to comment #107)
> 
> See comment #88
> 
> Regards 
> Steve

Thank you!
Sorry for the pollution...
Mozilla is wonderfull ;-)
Product: Browser → Seamonkey
Improved patch. Against CVS trunk.

- Also adjusts the width (i.e. fixing the problem mentioned in comment 103),
  not just the height. Text breaks at viewport border, as desired.
- I moved the attachments bar at the end of the msg (not next to the headers),
  to prevent it from being scrolled away, and it's probably nicer anyways
  (compare Thunderbird).
- I think I fixed a few bugs with wrong sizes.

Bugs:
- Collapsed headers cause pointless scrollbars, no idea why.
- Ugly reflow, but inherent to workaround
Attachment #157996 - Attachment is obsolete: true
Attachment #157999 - Attachment is obsolete: true
Attached image Screenshot of fix v4 — 
FYI, a screenshot how it's looking for me with the fix. Screenshot is from
state before I moved the attachments box.

Correction:
> to prevent it from being scrolled away

...horizontally
Pretty much the same patch as v5, but against Mozilla 1.7.6. I am quite
displeased with how v5 works, but maybe it's just this backport that's broken.
The fix in bug 80713 might make this fixable in a very elegant way.
Depends on: 80713
That would be oh so great, but I need the width, too.
I would specifc a desired width, where things would wrap if they can. Things
that can't wrap would go bejond that (and determine the actual width), but no
others. Basically what HTML display in the browser does.
No longer blocks: majorbugs
(In reply to comment #112)
> The fix in bug 80713 might make this fixable in a very elegant way.

too bad 80713 patch is lacking a review


This bug should block bug 315312.
In reply to comment #104)
> Is it possible to just add a scrollbar for the headers pane?
> 

That is what bug 223132 is about. Actually, one can fix it now just
using the version 2.0 of headerScroll extension [*]. 

So, what is particular on this bug to not mark it as a duplicate of bug 223132 ?

[*] http://www.cweiske.de/misc_extensions.htm#headerScroll
Because that would result in two scroll bars for the message, one for the headers, and one for the message.  Fixing this bug would fix the other bug, fixing the other bug would not make a jot of difference in fixing this bug, where a block of headers permanently occupies screen real estate.
(In reply to comment #118)
> Because that would result in two scroll bars for the message, one for the
> headers, and one for the message.  Fixing this bug would fix the other bug,
> fixing the other bug would not make a jot of difference in fixing this bug,
> where a block of headers permanently occupies screen real estate.
> 

Now I see what you mean. However, that is kind of a taste issue. It seems to me that currently the headers pane and the message text pane are different IU elements, so it make sense that they have their own scroll bars. Anyway, you are right, either solution will fix bug 223132. 

Does the patch here work for mozilla thunderbird?
> However, that is kind of a taste issue. It seems to me
> that currently the headers pane and the message text pane are different IU
> elements, so it make sense that they have their own scroll bars. 

NAICT, this bug is about 4xp parity. It's silly to have a separate XUL space for the same message header information that's in the headers pane stealing space from the most important part of the mailnews window, the message body. On those rare occasions there's something in the headers you want to see that isn't in the headers pane, it's not a big deal to scroll back to the top of the message pane.



Is there a Thunderbird bug for this, or should this bug be changed to "Core"?
Is it soo difficult to add a simple scrollbar the the header frame ?

I just saw that thunderbird also writes the header over the statusbar! That looks very bad!

It's very annoying that this old bug (Opened: 1999-07-15 13:30 PDT) is still not fixed.. :(
(In reply to comment #122)
> Is it soo difficult to add a simple scrollbar the the header frame ?

See comments #118 - #120. The second scrollbar (for the header UI element) would (apart from looking ugly) be quite small and hence not easily accessible.

Header is part of a message and should be displayed together. This way it would get scaled in the same manner as the message text when changing font size.

(In reply to comment #123)
> (In reply to comment #122)
> > Is it soo difficult to add a simple scrollbar the the header frame ?
> 
> See comments #118 - #120. The second scrollbar (for the header UI element)
> would (apart from looking ugly) be quite small and hence not easily accessible.
> 
> Header is part of a message and should be displayed together. This way it would
> get scaled in the same manner as the message text when changing font size.
> 
I fully agree that the headers should be shown as part of the message. 
However, this modification seems to be so complicated that nobody can fix it.

So, as long as that fix is not going to happen, why not show a scroll bar if the header pane occupies a significant portion of the space, e.g. more than 1/4th or more than 4 lines or whatever? 
That would make sure that:
  - the scrollbar is not shown if only short headers are shown -- or in other words, the scrollbar would only be shown if it is large enought to be actually useful.
  - the current bug where the whole message text area is hidden by an enormous header pane cannot happen any more. This is such an ugly and embarrassing bug that some *quick* workaround should be better than endlessly waiting for the perfect fix.
"This is such an ugly and embarrassing bug
that some *quick* workaround should be better than endlessly waiting for the
perfect fix."

Full acknowledge!  Why do poeple always try to make things *perfect* ? :)
How about that patch from last year? Anywone tried that? How come it wasn't up for review?
(In reply to comment #122)
> Is it soo difficult to add a simple scrollbar the the header frame ?
> 
> I just saw that thunderbird also writes the header over the statusbar! That
> looks very bad!
> 
> It's very annoying that this old bug (Opened: 1999-07-15 13:30 PDT) is still
> not fixed.. :(
> 

See comment #88

It seems to be just a bug in the default chrome. You can easily add a scrollbar in the headers pane.

This should be more known. Please spread it :

>>>
#  How to scroll the full message header in Mozilla Mail

In your Mozilla Profile chrome/userChrome.css file, add the following:

/* Limits View Headers (All) lists and adds scrollbars for overflow. */
#msgHeaderView { max-height: 8em !important; overflow: auto !important; }

Credit: Bill McCartney, Mozilla user. 
<<<
Yes!  This works.  Thanks!
*** Bug 337805 has been marked as a duplicate of this bug. ***
Hey, guys, I want an option for the headers to appear as a *part* of the
message, so that when you do a "Show All Headers" and then a "Select All",
the headers are included, a la Netscape 4.x. This makes it *extremely* easy
to report net abuse:

1. Show All Headers
2. Select All
3. Copy
4. New Message
5. Paste
6. To: abuse@whatever.com
7. Add comments above pasted message.

Thanx,
Jim H. (aka CuriousJ)
Having read all the other messages in this bug, if I recall correctly Netscape
4.x used to show attachments as icons with captions at the far right of the
header section, e.g., a WinZip icon, and underneath, "Attachment: filename.zip"
(underlined, I think, like a hyperlink). Text-type attachments could be
displayed inline, but I can't remember if there was a separator or not.
Something like:

-------------------------------- Attachment --------------------------------

would be nice.

Thanx,
Jim H. (aka CuriousJ)

(In reply to comment #130)
> ... option for the headers to appear as a *part* of the
> message, so that when you do a "Show All Headers" and then a "Select All",
> the headers are included, ... This makes it *extremely* easy
> to report net abuse:
...

Funny, in Thunderbird, it prints the headers no matter what, even when NOT wanted!
(In reply to comment #130)

Eyal Rozenberg contacted me and asked me to open a separate bug about comment
#130. That's how this started. See Bug #337805. It got marked as a dupe of Bug
#159333, which cascaded into a dupe of this Bug.

Thanx,
Jim H. (aka CuriousJ)

(In reply to comment #132)
> 
> Funny, in Thunderbird, it prints the headers no matter what, even when NOT
> wanted!
> 
The point isn't whether they *print* or not, it's whether they can be
*selected*, *copied*, *forwarded*, etc.

Jim H. (aka CuriousJ)

I'm not sure how this got onto my list of bugs, but the simple workaround for those who want header info to print, forward, etc is to open the msg source window and copy or print from there. I recall the header info shown inline in Netscape 3. It was a reason why I switched from whatever MS had at the time. But the simplest way to access full headers for various purposes is the source window. It might help to put that tip into the help info if it's not there already.

John T : Perhaps you could read the bug history and you will see why you have missed the point, why it is needed and the workaround you suggest is insufficient.  Perhaps you could reassign this to the right person, as it's been in the queue for years, literally, and you might have mentioned sooner that it's not your bug. ;-)

One of the most really annoying things about Mozilla mail and Thunderbird is that to forward an email with full headers (usually to report spam/other abuse) necessitates doing a "View -> Headers -> All" then forwarding.  Then to forward an email without the headers, to a colleague or a family member for example, needs it turned back off again.  OK, different bug, but if there was a "send with full headers" sub-button on the Send button, then full headers would not be needed and one reason for this bug to exist would be gone.

Furthermore, if "view headers all" is turned on and you click on the + sign on a large list of recipents, the headers can take over the preview pane and because the headers don't scroll with the message, the message is obscured by the headers with no way to see the message without collapsing the headers again.  In some cases, with view-all-headers, you don't even need to expand a header for this obscuring to happen.

Brian.


Further Note:

Forward as attachment isn't the answer either as some abuse ISPs ditch emails with attachments (although some don't).  In any case, you have to turn it on to send, then back off again for "normal" people to be able to read your forwarded emails seamlessly, and since it's buried away in preferences rather than on a menu, it takes too long.

:-)

Message > Forward As > Attachment (notwithstanding your first point though).
Wow... 8 years since this bug was opened.

I only noticed this bug today: I received an email with 30+ lines of headers, and because my mail window wasn't large enough, I couldn't see any part of the message body.  Because there was no scroll bar, the intuitive action (scroll down) was not possible.

The solution was either: stop viewing full headers, click on the '[-]' by the topmost header, move the divider, or expand the window.  I can see that if I had a message with 60 lines of headers, I would not be able to read the last lines of the header unless I used 'view source'.

On a further note, when I shrank the window, the headers were written into the status bar!  That was a surprise.

So, I hope you're having a good day, and maybe someday this will be fixed.  :-)
Oh, and the header lines (especially received lines) are not wrapping, so anything that goes past the edge of the window is not visible.  Did I mention there are no scroll bars?

The cut-and-paste of headers is a little warped as well; you can only copy one header at a time, and only the part to the right of the colon.  'View source' to the rescue again!

Thunderbird 2.0.0.4 (20070604)

Thanks!
I still think the correct solution, from a UI point of view, is to make the headers part of the main view. This is what everybody here seems to want, and usually makes more sense, and allows you to copy parts of all of the headers. 

There is a solid technical difficulty, the security problem that the header section needs to be able to do chrome stuff like add to address book. I can see how that would be tricky. However, as a user I think that exposes a limitation in the design, not that it's a reason to drop the idea.

BTW, I do imagine that if this ever happens, there may be a list of people grumbling that now the headers scroll with the message! They are not speaking up now because things are as they expect...
Noticed this today. AAMOF, the "headers" subpane filled the entire message body pane (and also beyond that).

Either scrollbars on the "headers" subpane or "headers scroll with message" is fine by me, but not the current "if header too wide: too bad, won't show" and "if too many headers: too bad, will neither show more or show message body".

Priority is set at P1. That's rather major isn't it? Do bugs even get sorted by priority in any view? Severity, OTOH, is set at normal. I'd say it's major...

/F
 
"View all headers" does not allow resizing the header part, leaving very little real estate for the message.

However, "view source" (or Ctrl-U) is an alternate way to view the full headers, even if they exceed the screen height. Now let's see what is said above:
- In this view, the headers scroll with the message.
- Headers wrap and scroll with the "text" (well, the source -- more on that later).
- They can be cut-and-pasted in the exact format in which they were sent (e.g. for reporting abuse).
- If you want to forward the mail itself, don't use View Source but rather, "Message -> Forward as" and then either "Inline" or "As Attachment". No change to the prefs. "As Attachment" includes full headers. Or else, paste the headers from the View Source page.
- See also userChrome.css fix in comment #127.

Now, the minus points of this "view source" solution:
- it doesn't render HTML
- it doesn't interpret base64
- it doesn't display images

These can be seen as plus-points too, depending on your POV. For instance, malicious content has in the past been hidden in some HTML tags -- <IMG> which weren't just pictures, not to talk of javascript (and the reason why both images and javascript can be blocked in mailnews). When I'm in doubt about whether a given email is spam or not, HTML is suspicious, and text-as-base64 is a giveaway. No need to unobfuscate.

If you still want to see the rendered text, you can (in the ordinary "preview pane" or "message window", with "standard" headers which can even be collapsed to just the Subject.

For all these reasons, if it depended only on me, I would close this bug WONTFIX; but I don't have that power (if someone on the CC list has it, please say yes or no).

Ben: are you still willing to try and fix this bug? If you are, I suppose your first task will be to bring it up-to-date to current trunk (maybe after a little wait to make sure it doesn't get WONTFIXed from on high). If you aren't, then I guess this bug should be reassigned to nobody@mozilla.org .
QA Contact: laurel → mail
wontfix is reserved for peers and module owners and I am neither. Also, I long ago gave up on seeing this get fixed - it just bounces from one comment to another. 
Another minus on the view source is that simple stuff that at least I think should be possible will require view source.  If I receive a mail that has:

From: John Doe <john.doe@somewhere.org>

I simply can not copy "John Doe" by marking that text.  Marking text is not even available.  All I can do is copy john.doe@somewhere.org with the popup menu.  This is not very good IMHO.  But the main point it that headers take up too much real estate.

But I don't think this bug will get fixed, we are stuck with this it seems.
This bug depends on bug 80713. That's why it stalls.
(In reply to comment #145)
> But the main point it that headers take up
> too much real estate.

This bug is not about view source. Headers take up 0 space once you scroll in N4. The reason this bug was filed is to permit scrolling the message body so that the headers automatically leave the field of view, leaving the message content itself to occupy 100% of the view pane.

In reply to comment #145:
In the View Source window I can select anything, then Ctrl-C (or Edit -> Copy) will move it to the clipboard.

In reply to comment #147:
In the Message window, near top left, just left of the Subject, there is a little widget which, depending on the theme, is either a triangle pointing downwards or a [-] box. Click it, the widget changes aspect, and the header is collapsed, showing Subject and Sender on a single line and leaving all the rest below it for the message body, which occupies then not 100% but perhaps 97% of the message window. In the preview pane, the same collapse/expand action is possible. Since that pane is not as tall as the Message window, that single header line admittedly takes a higher percentage of the total, but you can modulate that since the boundary between list pane and preview pane can be dragged higher or lower.

In reply to comment #146:
Well, I see that the latest patch in bug 80713 (three years old) has r- sr- so I guess more work is needed there too. I also see you've "resuscitated" that bug too so I suppose things will get going one way or another.
(In reply to comment #148)
> In reply to comment #147:
> In the Message window, near top left, just left of the Subject, there is a
> little widget which....

Yes, I know what that twisty is. When used it does reduce the space wastage to about one line, a line which repeats information directly (or usually within several lines) above it, and occupied by the window's titlebar. I fail to see a compelling reason to reduce message body view space by repeating the subject a third time, or the sender and timestamp a second time, or making that second/third copy look like part of the application's UI instead of like the message content that it is.
Suggesting to view source is like saying:
"My car doesn't have a rev meter." "Oh, then simply open the bonnet and measure the RPMs with a handheld meter"
In other words, it's giving up on making rhe application work for common cases.

Of course, I DO actually use this as an extremely annoying workaround, but thats not to say its an actual solution.
> if it depended only on me, I would close this bug WONTFIX;
> but I don't have that power (if someone on the CC list has it, please
> say yes or no).

As assignee, I say no. View source is not an adequate workaround at all.
As said, I am waiting for the Mozilla framework feature. iframe resizing to content is a necessary precondition for this bug (and other things).
Please no discussion about alternative, intermediate workarounds or implementation strategies, thanks.
See bug 449691 for the kind of design that we're heading towards to implement this feature.
Blocks: 449691
...when I want to see the full headers (like those shown by attachment 116330 [details]) I use View Source (Ctrl+U)
(In reply to comment #153)
> Created an attachment (id=333333) [details]
> screenshot showing why this is not really needed

That shows no such thing. N4 behavior, which is essentially what comment 0 describes/wishes for, is that approximately the headers shown in attachment 333333 [details] show by default for each message, except that they scroll away as the message is scrolled, automatically leaving a much larger content viewing pane, instead of the clumsy M$OE emulation of chrome headers locked in place except by extra clicks to turn them on & off (show/hide).
(In reply to comment #154)
> (In reply to comment #153)
> > Created an attachment (id=333333) [details] [details]
> > screenshot showing why this is not really needed
> 
> That shows no such thing. N4 behavior, which is essentially what comment 0
> describes/wishes for, is that approximately the headers shown in attachment
> 333333 [details] show by default for each message, except that they scroll away as the
> message is scrolled, automatically leaving a much larger content viewing pane,
> instead of the clumsy M$OE emulation of chrome headers locked in place except
> by extra clicks to turn them on & off (show/hide).
> 

Why scroll them away? I prefer them always there, which IMHO is no clumsy emulation but the right way to do it -- see also bug 449691 comment #7 sqq. If the headers scroll away, then if I want to see them I have to scroll back and by doing that I lose my place in the message.

Let's hope I'll be able to disable this (IMHO stupid) scrolling behaviour if ever it gets implemented.
Attached image MS Word with 1000 Toolbars (obsolete) — 
> Why scroll them away? I prefer them always there

Please: Your point has already been made and answered in this bug's comments; repetition = noise.

(And if a picture is really needed, then here it is. "The man with 1000 toolbars", from http://www.hcooh.ch/home/matafac/public/index.php?pid=0005.)
(In reply to comment #155)
> Why scroll them away?

Because most are right there in your own attachment 333333 [details] in the pane directly above, and most people really shouldn't have a use for that duplication. If they scrolled away as this bug requests, they would still be right there in plain sight.

> I prefer them always there, which IMHO is no clumsy
> emulation but the right way to do it -- see also bug 449691 comment #7 sqq. If
> the headers scroll away, then if I want to see them I have to scroll back and
> by doing that I lose my place in the message.
 
But you should have no need to scroll back to see the most important of them. I find being able to see more message at once infinitely more useful than having a second copy of headers wasting message view real estate. Unlike you, there simply isn't that much room for that waste here. I need all text to be about twice the size of the mousetype you use.
Attachment #333344 - Attachment is obsolete: true
Attachment #333344 - Attachment description: screenshot showing why this is really needed → MS Word with 1000 Toolbars
Attachment #333333 - Attachment is obsolete: true
QA Contact: mail → message-display
Can someone please remove the outdated target milestone?
Sorry, forget that stupid remark ...
(In reply to comment #158)
> Can someone please remove the outdated target milestone?
(In reply to comment #159)
> Sorry, forget that stupid remark ...

Why stupid? "Mozilla1.8alpha4" _is_ outdated now that SeaMonkey 1.0 (based Mozilla1.8.0 code) is obsolete and that there won't be a SeaMonkey 1.2 (the next major release after the current 1.1.x will be 2.0, based on 1.9.1 core code)
View - Headers - All creates a scrollbar in the header pane in SM2 now. So severity is down to Enhancement.

UI suggestion: New menu item View - Headers - INLINE
Severity: normal → enhancement
Priority: P1 → --
Target Milestone: mozilla1.8alpha4 → ---
What happens to this bug now that bug 474523 was imposed? Or is Seamonkey luckily not affected? (I use Thunderbird, so I don't know)

https://bugzilla.mozilla.org/show_bug.cgi?id=474523
remove reply, reply all, forward, delete, junk, and forward/back buttons from default mail toolbar [and put them in the header pane]
The dilemma.
The atrocity implemented by bug 474523 will not get in into SeaMonkey.
If we'd decide to put buttons there, we'd put an optional, customizable toolbar there.
Flags: blocking-seamonkey2.0.8?
No new features on branches.
Flags: blocking-seamonkey2.0.8? → blocking-seamonkey2.0.8-
A. This is not really a new feature, but a bug fix.

B. This is labeled as "Trunk".

The message reader is being largely rebuilt for version 115. So this issue is will not be fixed for the current version 102.

When 115 becomes available in July please file a new bug if the problem exists in version 115. You can also evalute the changes in 3-4 weeks by trying a beta build.

Status: NEW → RESOLVED
Closed: 24 years ago → 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: