Current view all headers mode is impractical for real useage, keeping you from actually reading the message contents. I've always wanted (and did at one point) to get rid of it all together, but to many people protested :). Ben had the following suggestion: 1) Get rid of the View all headers mode 2) Make the menu item bring up a dialog with a nicely formatted listbox showing all the headers for the current selected message. One counter argument, view source does that same thing already and you can select a bunch of headers from the view source dialog. But it doesn't look as nice as a header only dialog would.

I've changed my mind on this. I'm now leaning towards supporting customizeable headers and getting rid of view all headers all together. Ditch view all headers. Add support for a user to check the set of headers he wants to see in the message pane.

Sounds like Mnenhy. ;-) Actually, my (proposed, locally working) approach for bug 236954 includes a backend interface for this. I could repriorize that bug in my queue if you feel it'd be useful...

When I use "View All Headers" mode, all I'm missing is a scroll bar to let me scroll down through the headers and ultimately to the message itself. Currently, scroll bars don't display and if there are a LOT of mail headers, it can be challenging to see them all. Peace...

(In reply to comment #3) > When I use "View All Headers" mode, all I'm missing is a scroll bar to let me > scroll down through the headers and ultimately to the message itself. > Currently, scroll bars don't display and if there are a LOT of mail headers, it > can be challenging to see them all. > > Peace... > howdy Tom, lookee ... - need a scrollbar on the envelope panel (view all headers / long addr lists) https://bugzilla.mozilla.org/show_bug.cgi?id=223132 take care, lee

> Ditch view all headers. Bad idea. When I subscribe to a mail list, I need to be able to see what headers it is using so I can figure out a rule. View Source does “work” but the header view is better. > Add support for a user to check the set of headers he wants to see in the message pane. That could be applies to the “Normal” view, or even a third “custom”

Scott, did you want to leave this bug open, now that you've implemented the alternate scheme per comment 1?

Patch adds scrollbars when in 'view all headers' mode. Work sponsored by Linspire. Can someone review?

Comment on attachment 267008 [details] [diff] [review] viewHeadersScroll.patch this could be a stop gap if and until we allow customization

Comment on attachment 267008 [details] [diff] [review] viewHeadersScroll.patch >+ expandHeader.setAttribute("style", "overflow: auto;"); and... >+ expandHeader.removeAttribute("style"); Should this "expandHeader" ever have inline style applied to it, via an extension, theme (via an overlay), or any other future code, internal or JS, it will override any and all style rules. Perhaps this could be done another way? (disclaimer: I am *not* an official reviewer of this code, and in-fact have never reviewed this code, if mscott is ok with this, then my word means nothing :-) )

Massey, can you attach a screen shot?

Screenshot of view all headers scrolled.

massey, does your patch basically address bug 223132? Mike in comment #6 > Scott, did you want to leave this bug open, now that you've implemented the > alternate scheme per comment 1? where is this implemented? not saying this a bad idea, but is the only reason for adding this complexity to avoid the admittedly unattractive look of header scrolling?

>massey, does your patch basically address bug 223132? It looks like it does address the same basic issue, almost in the same way:) It would be nice to see this issue resolved, one way or the other.

(In reply to comment #12) > [...] > where is this implemented? I believe I was referring to the preference mailnews.headers.extraExpandedHeaders Mine is set to x-bugzilla-reason List-Post and when I view messages with those headers, the headers are shown in the envelope panel. I don't remember which bug implemented that, but it was fixed around the time of comment 6. > not saying this a bad idea, but is the only reason for adding this > complexity to avoid the admittedly unattractive look of header > scrolling? There are also some minor issues; the behavior of View All/View Normal is inconsistent compared to collapsed ("brief") headers; and see bug 326347.

Comment on attachment 267008 [details] [diff] [review] viewHeadersScroll.patch Not like that, no. The patches on the various other bugs about adding a scrollbar are more straightforward.

Not entirely sure which approach this bug is about now, but whichever one it is, it isn't a blocker.