Turn on full headers or long To: list and there is no scroll bar

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5
Build Identifier: thuderbird 20031013

sometimes a mail header has a lot of lines, many more than can fit into the window currently
showing the mail headers (when you do a view all headers).
the problem is there is no way to scroll down the headers to see them all, and sometimes even
maximizing the window doesn't show them all.
can you add a scrollbar to this area?

Reproducible: Always

Steps to Reproduce:
1. find an email with a lot of headers
2. view all headers
3. you can't see them all

Expected Results:
put a scroll bar there

workaround is to view message source

I was just about to files this as a bug. The other problem is, when you view
all headers on a massive email, you can't see the body of the message either.
There is no way to scroll down to see either the rest of the headers or the message.

This is not limited to OSX (Windows build 20040113)

Well, it also happens in Linux, I think it is safe to say that it happens in all
platforms.

Same behavior with
Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.6) Gecko/20040113

Workaround: Export message to text-file and open it with another editor...

i would also appreciate an option for the headers to scroll with the page like
netscape 4.7.

Can somebody change the 'Hardware' field to 'All' on this bug?

This bug is either a dupe of bug 56825 or bug 9942

see bug 216605 for more info...

Created an attachment (id=153241)
UserChrome.CSS file adding scrollbars to header window

This file, when placed in Thunderbird's Chrome directory (in Windows XP it's
C:\Documents and Settings\<Name>\Application
Data\Thunderbird\Profiles]default\*.slt\chrome\) this will add scroll bars to
the header window when Headers are set to Full. This works with Netscape 7.x,
Mozilla 1.x, and Thunderbird 0.7.2. However in Thunderbird, when the headers
are scrolled, horizontal lines will appear on top of the headers that were
below the bottom of the header window. Clicking anywhere in the header window
makes those lines dissappear, but if the headers are scrolled up and down again
afterwards, the lines will reappear. The text for the file was originally
posted to one of the Netscape newsgroups a year or two ago.

This file did not work with Mozilla 1.6 and 1.7 for Linux though.

See the CSS tweak in bug 240313. Works OK in TB as well as Moz, but it's not
perfect.

*** Bug 242063 has been marked as a duplicate of this bug. ***

*** Bug 241463 has been marked as a duplicate of this bug. ***

That dupe (bug 241463) notes that if the window is not tall enough, the message
pane pushes down to obscure the status bar, and also the bottom of the folder
pane in some layouts, potentially making some folders inaccessible.

See the work that is going on in bug 9942 towards this same problem in the
Seamonkey mail/news program.

*** Bug 261322 has been marked as a duplicate of this bug. ***

*** Bug 247163 has been marked as a duplicate of this bug. ***

*** Bug 265452 has been marked as a duplicate of this bug. ***

*** Bug 269088 has been marked as a duplicate of this bug. ***

*** Bug 269780 has been marked as a duplicate of this bug. ***

As a different solution to the problem, it would be great if the headers
appeared "inline" with the message, a la evolution.

(In reply to comment #19)
> As a different solution to the problem, it would be great if the headers
> appeared "inline" with the message, a la evolution.

I believe it was stated in a dupe of this bug that you can press ctrl + U and
view the "source" of the message ala Firefox. This works like you describe.

*** Bug 271721 has been marked as a duplicate of this bug. ***

As a variant on the userChrome.css tweak to put scrolls on the entire panel, I
tried creating one that put scrolls only on the expanded address lists:

#expandedtoBox, #expandedccBox {
  overflow: auto !important;
  max-height: 14em !important;
}

However, as with my test on applying the same thing to the attachments list
(bug 242531), this doesn't work as expected -- in this case, the expanded
list(s) never gets larger than one line, and no scrollbars are shown.

*** Bug 274878 has been marked as a duplicate of this bug. ***

(In reply to comment #20)
>> As a different solution to the problem, it would be great if the headers
>> appeared "inline" with the message, a la evolution.
> I believe it was stated in a dupe of this bug that you can press ctrl + U and
> view the "source" of the message ala Firefox. This works like you describe.

And what if names of people are not in ASCII? e.g. utf-8? - you will see e-mails,
but not names. So this is not 100% workaround.

I'd recommend inlining - simple solution to all freaky problems.

Netscape Messenger 4.x did right: headers and attachments were inline. I do not
remember how it dealt with many attachments, but solution I've seen is to present
user with dialog where he/she can select attachments to save and where to save them.

This problem is really annoying - I like to check how SpamAssassin is behaving,
and not being able to view all headers without having to pop up a new window
with Ctrl-U almost made me decide to drop Thunderbird. Please add a scrollbar to
the "all headers" section. (The userContent.css workaround doesn't seem to work
for me - I'm using TB 1.0 on Win 2K.)

Well, apparently one can't put in votes for mail front-end bugs, but consider
this comment my vote...! This is pretty frustrating for me; yeah, I can view
the source to do it, but really, that's a kludge. It makes the user leave the
UI to do what they're trying to do... bad juju. Not minor, afaic.

I too vote for fixing this annoying bug. We need both vertical scrollbars to
see all the header lines and the message body as well as horizontal scrollbars
to see the end of the really long header lines like the Received lines. View
source is not a fix. Consider this my vote and the votes of all the people I've
switched to Thunderbird. I am of course running the latest greatest.

*** Bug 278364 has been marked as a duplicate of this bug. ***

*** Bug 279262 has been marked as a duplicate of this bug. ***

*** Bug 276294 has been marked as a duplicate of this bug. ***

Since bug 279262 was marked a dupe of this bug, would it make sense to mention
"attachment box/pane" in the summary?

(In reply to comment #32)
> Since bug 279262 was marked a dupe of this bug, would it make sense to mention
> "attachment box/pane" in the summary?

That bug was duped to the wrong one. This bug is not about the TB attachment
panel.

*** Bug 212717 has been marked as a duplicate of this bug. ***

Still a case with Thunderbird 1.0, Starting to become a bit annoying.

(In reply to comment #35)
> Still a case with Thunderbird 1.0, Starting to become a bit annoying.

same here. Make this feature useless.

*** Bug 275505 has been marked as a duplicate of this bug. ***

*** Bug 274145 has been marked as a duplicate of this bug. ***

Please add your votes to this bug so that the developers will know that this is
something we all want fixed.

Click on "Vote for this bug" at the top, then select the checkbox corresponding
to this bug.

Yes, although I'm using a linux distribution version of thunderbird (so I
probably will benefit for this fixing only on the next update of the
distribution), I believe that fixing this bug will give thunderbird a more
friendly behavior.

*** Bug 287731 has been marked as a duplicate of this bug. ***

*** Bug 288084 has been marked as a duplicate of this bug. ***

*** Bug 288065 has been marked as a duplicate of this bug. ***

*** Bug 288863 has been marked as a duplicate of this bug. ***

I think also that this bug is a big problem. It is the first thing we see when
displaying headers. It makes Thunderbird does not look as a finite product

Still in Thunderbird 1.0.2

Well, it seems developers do not understand that this bug is blocker.

I know many people who will point into that and say 'Bue-e-e, Outlook is better'.

This one is *MUST* for corporate users. Do not freak out. Check how it is done
in Mac OS's Mail.app, check how it was done Netscape Messenger and do the same.
From my pov, it is even easier to implement.

*** Bug 286413 has been marked as a duplicate of this bug. ***

This is a serious problem with much-needed and simple fix. Note the same
problem occurs with the attachment list -- it's particularly bad in the preview
pane. Having these panes expand to block out the entire message body (as it is
now) is unacceptable.

I would recommend either combining headers and attachments into the message
body pane as some have suggested, or keep them separate and add scroll bars.
If the latter, I would suggest that neither pane should ever auto-size to
anything larger than 1/3 of the available space.

One fix would be to set the "maxheight" attribute of the "msgHeaderView" hbox to
100 (or 33% or whatever), and its "style" property to "overflow:auto". That
automatically adds scroll bars to it when the content is larger.
BUT there is a big problem: Due to rendering issues (?), the whole box gets
distorted and black when scrolling, and even when pressing the "-" to hide the
headers. So this isn't a real fix (but were, if everything worked).

I made a small extension which fixes this:
http://www.cweiske.de/misc_extensions.htm#headerScroll

(In reply to comment #51)
> I made a small extension which fixes this

Wonderful! Could you describe what your extension does? Are there any problems
or limitations? Is it "the whole box gets distorted and black when scrolling"?
If so, how about creating a bug on that issue and making this bug dependent on it?

If it works well (or even if not), how about submitting a patch to this bug?

(In reply to comment #52)
> Wonderful! Could you describe what your extension does?
I use the method described in comment #50 - maxheight=200 and style="overflow:
auto". But.. see next paragraph.

> Are there any problems
> or limitations? Is it "the whole box gets distorted and black when scrolling"?
That seemed only to come in thunderbird 1.1a 200506XX (don't know which exactly)
 which I used to test my other extensions. Today I noted that the "distorted"
thing doesn't happen in tb 1.0.2.
The main problem is that if you set "overflow:auto", the scrollbar appears even
if it doesn't overflow - it seems as if the border at the bottom of the header
view isn't counted, and so the scrollbar occurs just enable scrolling one single
pixel down. To prevent this, the extension checks if normal or all headers are
shown when a message is being loaded, and switched the overlay-style on and off,
depending on the setting.

> If it works well (or even if not), how about submitting a patch to this bug?
IMO that's too quirky to see it as a fix to this bug - it's merely a workaround
which even doesn't work if you start thunderbird with all headers enabled.

IF the overflow bug is fixed, the only thing would be to set the CSS, which
could be very easily done by default. But as there are plenty of overflow bugs,
it will take some time I fear.

*** Bug 303322 has been marked as a duplicate of this bug. ***

*** Bug 307929 has been marked as a duplicate of this bug. ***

(In reply to comment #55)
> *** Bug 307929 has been marked as a duplicate of this bug. ***

I wonder whether this is actually the same thing, but I suppose you guys know
what to do with it.

*** Bug 270876 has been marked as a duplicate of this bug. ***

*** Bug 314312 has been marked as a duplicate of this bug. ***

I've installed TB recently and almost return to Netscape 4.7 for this Bug.
But there's something more, there is no use (for me) to display a list of hundreds of names and email if you cant search it !!!
To do so, I have to do "ctrl" + U and then browse.
This is not very efficient...
I receive 50 to 60 mails every day.
Some of them are sent to hundreds of people.
I need to check if some peolple that have to know about that mail received it or not.
Netscape 4.7 include the destinatary list with the body of the mail and allow to search for a name just as for something in the body of the messenge.

Sorry to say that it's, up to me, much more efficient.
Hope this probleme to be solved quickly.
Thanks

(In reply to comment #51)
> I made a small extension which fixes this:
> http://www.cweiske.de/misc_extensions.htm#headerScroll

I've tried to install it on TB 1.0.6 (20050716).
I see no sroll bar....

Ok seriously now, this bug has been around for over 2 years now and still isn't fixed? I just installed thunderbird 1.5 RC 1 and it still has this problem. How hard is it to just give that pane a scroll bar, and maybe even make it resizeable?

Phillip, if its that easy, please feel free to contribute the fix to the code-base.

Have anyone of reporters knew how to fix that, I think, the bug would CLOSED long time ago. As I see even people how thought they knew how to address the problem - have triggered some other bugs - see comment #50 & comment #53.

This is real shame. For corporate suits this is must: meeting notifications are sent this way and list of attendants can run into tens sometime hundreds people.

I have escaped the problem by switching such conversations to GMail - it has no problems with long headers.

(In reply to comment #59)
> I've installed TB recently and almost return to Netscape 4.7 for this Bug.
> But there's something more, there is no use (for me) to display a list of
> hundreds of names and email if you cant search it !!!

Not part of this bug - what you are looking for is Bug 235908, Bug 310359

In reply to comment 64.

I think that I'm in the right bug.

You have to be able to scroll, AND to search within all the names and eMails.

Netscape 4.7 was just perfect for this particular point.
Is it posible to implement the same behaviour?
Thanks

*** Bug 318848 has been marked as a duplicate of this bug. ***

Okay, I guess it's up to me to be the total asshole once again, and state the
painfully obvious:

It is *way* past the point where this bug is merely an embarassment for those
of us who would like to recommend thunderbird as the best mail/news client on
the planet.

No, a mere embarrassment could be tolerated. This is complete humiliation,
a disgrace to the open-source community -- even Micro$oft could have fixed
this by now!

I challenge you, Scott MacGregor, to take responsiblity for this stupid and
embarrassing bug and get it fixed! Every other email client I've tried (and
there have been many!) has got this right. Only TB can't seem to get the
display of headers correct.

As I stated long ago: if the technical details of implementing a solution
seem overwhelming, then go back to the drawing board and question the basic
design! This header problem has persisted through many attempted fixes, and
yet it plagues us. Go back and fix the basic design, which is certainly bad,
if the implementation is so difficult.

I criticize as a loving parent criticizes his own child -- I want thunderbird
to be the best! Please accept my bitching in this context, and don't get all
defensive. You know this is a problem. Please fix it!

Thanks for listening.

Very well said, Walter, excellent post. This bug should definitely be a blocker for either the 1.5 or 2.0 release. It is such a basic problem that it should've been addressed before 1.0, but obviously that didn't happen. At least Control-U works as a workaround; that is the only saving grace for me.

Extension header scroll extension - Thunderbird Extension

header scroll extension 0.2.1, by Christian Weiske, released on September 18, 2005 this does't work with new Tbird versions.

I just tried evolution yesterday for a few to see if a problem I was having was the server or thunderbird. It seems that evolution does not show the headers in a seperate pane from the body of the message, so when you scroll the message, the headers scroll with it. I think I prefer that behavior, and it certainly eliminates the need for a new scroll bar that seems so hard to implement.

Currently thunderbird has a nice +/- widget that you can click on to expand/shrink the headers. Why not just eliminate the seperate frame and place the headers and message body in the same frame, with one scroll bar, and the +/- widget to toggle between full and normal headers?

To comment #70: that was proposed dozen times already. And it was unanimously (so to say) ignored to death by developers. Apparently this problem bothers only users...

Most people (and devels) get attracted to Ff. Tb is sort'a bastard child of Mozilla Messenger. There is not much developers are working on it really.

To this day, I'm still using the CSS tweak I attached to this bug report back in July 2004. It works with both Thunderbird 1.5 and the SeaMonkey nightlies (both Linux and Windows builds).

(In reply to comment #72)
> To this day, I'm still using the CSS tweak I attached to this bug report back
> in July 2004...

A big improvement. The horiz scroll works perfectly, but the vert scroll causes
a problem for me: the re-sizing bar disappears and so I can't adjust the height
of the header pane. This is important because the header pane almost vanishes
entirely when I use the +/- widget to display abbreviated headers.

(In reply to comment #73)
> ...This is important because the header pane almost vanishes
> entirely when I use the +/- widget to display abbreviated headers.

Aha! I just realized that this problem occurs because the horizontal scrollbar
covers up most of the header pane. Therefore you would only see this problem if
you have a header long enough to trigger a horiz scrollbar, which is uncommon.

If this one problem could be solved then I agree that this would be the perfect
solution for this bug. Thanks!

I do not have headers wide enough to trigger the horizontal bar, but still can not resize the header pane. It appears to be because the pane has a border size of 0, so there is no border to grab.

(In reply to comment #75)
> I do not have headers wide enough to trigger the horizontal bar, but still can
> not resize the header pane. It appears to be because the pane has a border
> size of 0, so there is no border to grab.

You can force a horiz scrollbar just by narrowing the entire TB window until it
can't display the entire 'From' header. I think it would be nice to resize the
header pane if it is expanded to show 'all headers', but I'd still be satisfied
even if I couldn't. The horiz scrollbar problem would need to be fixed, though.

The one thing I've noticed about this CSS tweak is that it doesn't seem to do the right thing for horizontal scrolling of long "Received:" headers. They can be individually scrolled per-line by selecting the line and dragging, but they don't cause a horizontal scrollbar to show up - it only shows up if you shrink the window to be smaller than one of the other headers. Anyone have any idea what's up with that?

The difference is whether you want the header to be 'clickable' (To: and From:)
or 'selectable' for copy/paste purposes. If you want to copy a very long header
it would be difficult to do if you have to worry about moving a scrollbar and
selecting text at the same time. This is one of the reasons the basic design
of the header pane grew so complex that nobody wants to touch it anymore. And
the headers still aren't searchable, either <sigh>.

With this CSS tweak, I see a horizontal scrollbar that runs the entire width of the window, it cannot be moved left or right very much, maybe 1/16".

The Received: lines generally run off the right side of the window and as the person in Comment #77 indicated, if the line is grabbed and dragged, I will be able to see the remainder of the selected line.

It would be nice to get rid of that horizontal scrollbar in this CSS tweak, if possible, but I have no idea what line or lines to change/remove.

The horiz scrollbar should disappear if you make the header pane wider. If the
window is already maximized you can't make it wider, but you can de-maximize it
and then actually stretch the horizontal size so it's *wider* than your screen
by moving the left edge of the window off the left side of the screen (just as
a test, not to really use TB that way).

Is your horiz scrollbar at the top or the bottom of the header pane? Does it
obscure part of the header pane when you display minimal headers?

I'm using the Linux release of SeaMonkey right now (build 2006011707) and am not able to create what is described in the first statement in Comment # 80.

In regards to the position of the horizontal scrollbar, it is at the bottom of the header window and when the small "-" is selected to minimize the headers, the horizontal scrollbar indeed obscures part of the header pane, if the Subject: line, including the word "Subject" were in all lower-case letters, you would not be able to see anything when the pane is minimized. All that can be seen when minimized is part of the box with the "-" in it, and the tops of the capitalized and tall letters.

Hm. The horiz scrollbar is completely non-functional in Seamonkey, but works
pretty well in TB.

In SeaMonkey, I see a horizontal scrollbar, but in Thunderbird 1.5, the horizontal scrollbar is not present, only a vertical.

I would have gone back to Netscape Communicator 4.79. I like the way it displayed headers in the same field as the rest of the message.

I've noticed this bug for more than a couple of years and just bumped into this bug report while searching for solutions to this issue of not having scroll bars for the recipient list (when expanded). Since the developers have not given any priority to this, I can only hope that there are more votes to have this fixed. I remember Netscape Communicator had a better UI in this aspect.

Please fix this soon!

*** Bug 328021 has been marked as a duplicate of this bug. ***

Version 2.0 of headerScroll [*] works in Thunderbird 1.5 and seems to fix this issue. Could I ask what is the drawback? Thanks.

[*] http://www.cweiske.de/misc_extensions.htm#headerScroll

(In reply to comment #87)
> Version 2.0 of headerScroll [*] works in Thunderbird 1.5 and seems to fix this
> issue. Could I ask what is the drawback? Thanks.
>
> [*] http://www.cweiske.de/misc_extensions.htm#headerScroll
>

I've tried the headerScroll extension and it works well. The only "drawback" (or rather, a feature request) is that the scrolling should be available for "View->Headers->Normal" too. Right now the extension works only if "Headers" is set to "All". My issue with TB not having a scroll bar here is that when the recipient list is long and it's expanded using the "flippy triangle", the recipient list is also truncated to the size of the window and there's no way to read the recipient list or the message!

If the headerScroll extension is modified to allow the user to have a scroll bar with normal headers, it would be helpful to scroll through a long list of recipients. Then we wouldn't have to wait for a fix in TB for this issue. Maybe you could provide an option to enable the scroll bars on:
1. Full headers
2. Full and Normal headers
3. None

Thanks!

> If the headerScroll extension is modified to allow the user to have a scroll
> bar with normal headers, it would be helpful to scroll through a long list of
> recipients. Then we wouldn't have to wait for a fix in TB for this issue.

I really hope you don't need to wait other three years to get what you wish.

Perhaps mozilla should setup bounties for fixing bugs instead of running ads in NYT? Ah, I don't know!

Whatever, good luck!

> Perhaps mozilla should setup bounties for
> fixing bugs instead of running ads in NYT? Ah, I don't know!
Bounties are given by private persons or companies that want to have certain bugs fixed, not by the programmers themselves.

I'm having this problem too, especailly with list-mail (winxp, seamonkey 1.0). i got one from full-disclosure and i couldn't even see the end of the header pane, much less the window menu. i had to click the little toolbar minimizers on the left just to see 1 line of the actual message. maybe consider putting less blank space in between the header lines to fit more in until scrollbars are added? also, maybe put in some condition that the mail pane has to be at least 25% of the window so that the entire window isn't just headers? also i don't think this is a "minor" bug, as it makes the message you're trying to read unusuable. should be at least a normal bug. can also someone assign a priority to this one so it doesn't get lost in the database?

Before I get cracking on custom headers for the message pane instead of view all headers, there's some code cleanup I want to do.

Created an attachment (id=216481)
use a deck to toggle between the collapsed and expanded view

(From update of attachment 216481)
use a deck to control the collapsed and expanded header view. The deck does most of the work for us that we were doing in JS.

Created an attachment (id=216484)
start removing obsolete "keyword" stuff

this starts to rip out the keyword stuff which was added for Netscape back in 2002 so they could add extra UI stuff.

Created an attachment (id=216576)
remove netscape instant messenger buddy icon code

I'm not adverse to support images in the message header pane (x-face, etc.), but we won't do it by looking for netscape instant messaging file screen name paths in your profile since we don't use netscape instant messenger anymore.

Created an attachment (id=216578)
remove functionality for collecting e-mail addresses when you read the message

we turned this functionality off a long time ago, it made it too easy to get spam addresses into your address book. This just removes the code that looks at the pref all together.

the keyword patch broke message header display on the 2.0 branch due to a bad merge. I just fixed that so tomorrow's builds should be all better.

Did this cause Bugzilla Bug 332267 header + not working?

So far, it seems better with version 2 alpha 1 (20060331)

(In reply to comment #50)
> One fix would be to set the "maxheight" attribute of the "msgHeaderView" hbox
> to
> 100 (or 33% or whatever), and its "style" property to "overflow:auto". That
> automatically adds scroll bars to it when the content is larger.
> BUT there is a big problem: Due to rendering issues (?), the whole box gets
> distorted and black when scrolling, and even when pressing the "-" to hide the
> headers. So this isn't a real fix (but were, if everything worked).
>
Using expandedHeaderView instead of msgHeaderView seems to fix the rendering issues when scrolling. For example:
/* Header Scroll userChrome.css Hack */
#expandedHeaderView {
  max-height: 20em !important;
  overflow: auto !important;
}

(In reply to comment #88)
> I've tried the headerScroll extension and it works well. The only "drawback"
> (or rather, a feature request) is that the scrolling should be available for
> "View->Headers->Normal" too. Right now the extension works only if "Headers" is
> set to "All". My issue with TB not having a scroll bar here is that when the
> recipient list is long and it's expanded using the "flippy triangle", the
> recipient list is also truncated to the size of the window and there's no way
> to read the recipient list or the message!

Yeah, that is bug 56825 (which should be a duplicate of or blocked by this one).
Perhaps you could contact the author of the extension, Christian Weiske[*], about that idea. Maybe if everybody here sends him a postcard, he will do it. That would be at least 61 postcards! ;)

I think it is a pretty intelligent thing to have the scrollbar whenever the headers overflow the headers pane and not only for full headers. That would fix this and bug 56825 and perhaps 9942. I don't think anybody is going to complain about that solution and you don't need any additional options.

[*] http://www.cweiske.de/misc_extensions.htm

With that extension I see many dark gray horizontal lines in the pane when scrolling (fixed by replacing msgHeaderView by expandedHeaderView in headerscroll_overlay.js).

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 sad, that this old bug is still not fixed.. :(

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060421 Thunderbird/2.0a1 ID:2006042108

I was looking at the Evolution email client and they seem to have a radically different approach. They have one scroll bar window which controls a window which contains the message and the headers and maybe even the attachments list.

-Joe Baker

To comment #96: That's the approach of all sane gui MUAs since the dawn of internet. e.g. good ol' Netscape Messenger. But apparently it's considered to be old and uncool. For example Outlook doesn't use it, Thunderbird doesn't use it.

P.S. Thanks to Google Mail, the problem isn't that crucial to me anymore. Thou in office I have had couple of problematic e-mails.

P.P.S. Seems developers really do not care about that bug. Could it be they went to Google Mail too? ;)

(In reply to comment #95)
> Is it soo difficult to add a simple scrollbar the the header frame ?

> It's sad, that this old bug is still not fixed.. :(

Andreas and Ihar 'Philips' Filipau,

I guess your help is welcome and you may start by testing the UserChrome.CSS file that is attached to the bug report. You may report if you see the issues described in comment #92 and comment #94, test the fix proposed there and report again.

Thanks for your contribution.

I tested that UserChrome.css file. It works! It added a scrollbar.

But the background of the header-panel looks bad... it has trouble if I scroll up and down... there are some annoying lines.

see here:

http://img208.imageshack.us/my.php?image=headerpane3hn.gif

So hurry up guys and fix that 3 year old bug :=)

and this:

/* Header Scroll userChrome.css Hack */
#expandedHeaderView {
  max-height: 20em !important;
  overflow: auto !important;
}

fixes the background redraw problem. Now all is fine! Great!

So please do not wait any longer and integrate that code into thunderbird.
People will thank you :)

I see the same problem like depicted in comment #99.

To be frank, I do not need such workarounds (sorry, the userchrome.css doesn't contribute fix - but only workaround). What I want is a proper fix. Or shall I say regression to the level of functionality of Netscape 4.x. The old Messenger did the right thing. Evolution, FoxMail, Mail.app, other all do the right thing.

I want Thunderbird also to do the same right thing: header, attachments all inlined in the same view pane as message body. Nothing more. That automatically fixes the aforementioned problem, it allows to search in header, it allows to search in attachment list, it allows to display full sender info as it was properly done in Netscape, it provides a place to display signature/encryption info, it allows to provide user with option for any of that info being folded or unfolded - depending on what user expects. From POV of extensions it allows to add any info user might want to the message view. In non-obtrusive way. And so on.

I still cannot understand people who changed the way message is displayed in SeaMonkey... Tb got that problem from the later SeaMokeys.

(In reply to comment #101)
>
> I still cannot understand people who changed the way message is displayed in
> SeaMonkey... Tb got that problem from the later SeaMokeys.
>

I don't know either why or who changed that. However, I do realise that few people seem to be really bothered by this issue. It seems most TB users are satisfied with the current status, or with the headerScroll extension [1] or with the UserChrome.CSS workaround given here. Otherwise, someone would have contributed a patch or paid someone to develop one or nobody would be using Thunderbird. As it says in mozilla.org[2]:

"Is there some bug that really bothers you? Instead of just reporting it, feel free to fix it as well."

And by the way, this discussion hasn't got us nearer to fix the bug. So let us (me included) stop these *pointless comments* [3]. This only drives developers away from this bug. Thanks.

[1] http://www.cweiske.de/misc_extensions.htm#headerScroll
[2] http://www.mozilla.org/contribute/
[3] https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

(In reply to comment #100)
> and this:
>
> /* Header Scroll userChrome.css Hack */
> #expandedHeaderView {
> max-height: 20em !important;
> overflow: auto !important;
> }
>
> fixes the background redraw problem. Now all is fine! Great!
>
> So please do not wait any longer and integrate that code into thunderbird.
> People will thank you :)
>

It will be nice to see this patch land. Thanks.

Created an attachment (id=223346)
Screenshot of CSS from comment 92, in TB 1.5

I haven't been able to reproduce the "horizontal lines" problem with any build.

Applying that styling to #expandedHeaderView works better than using
#msgHeaderView, for 2a1/3a1 nightlies. For 1.5, what I'm seeing is much worse
-- the envelope panel is drawn as tall as needed for *all* the headers, but the #msgHeaderView element is given the expected height and a scrollbar, resulting in a large, blank area of the envelope between the scrollbar and the message body (this is seen in the attached screenshot).

In fact, the 2a1/3a1 builds behave better even if using #msgHeaderView.
See bug 240313 comment 12.

(In reply to comment #101)
...
> I want Thunderbird also to do the same right thing: header, attachments all
> inlined in the same view pane as message body.

The following comes very close to doing this, but I can't get the messagepane object (a browser object, not a box) to vary in height, that is the only issue.

/* Attempted new hack */
#messagepanebox {
  overflow: -moz-scrollbars-vertical;
}
#msgHeaderView {
  overflow: -moz-scrollbars-none;
}
#messagepane {
  min-height: 50em;
}

This bug report has become something of a chat room,
so I thought I'd toss this rumor in the pot ;o)

https://bugzilla.mozilla.org/show_bug.cgi?id=331924

*** Bug 343094 has been marked as a duplicate of this bug. ***

*** Bug 344746 has been marked as a duplicate of this bug. ***

I didn't have any more open items for this.

we'd consider a patch for this.

*** Bug 307054 has been marked as a duplicate of this bug. ***

Created an attachment (id=243516)
A sample message that makes this bug easy to reproduce.

This is a sample message with many, many recipients that makes this bug quite easy to reproduce. If you click the disclosure triangle (Mac) or plus sign (Win) to show all the To: recipients, the recipients fill the entire screen, with no scroll bars. The body of the message cannot be viewed while showing all the recipients.

Still extant in
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7

> Severity: minor

This isn't minor. It's not like it's some cosmetic problem. You can't get at
the data (whichever addresses don't fit and aren't visible)!

Daniel

After all this time, I'm continuing to use the UserChrome.CSS file with both Windows and Linux, to eliminate this problem.

(In reply to comment #112)
> Still extant in
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211
> SeaMonkey/1.0.7
>
> > Severity: minor
>
> This isn't minor. It's not like it's some cosmetic problem. You can't get at
> the data (whichever addresses don't fit and aren't visible)!
>
> Daniel
>
In that case, it also needs the dataloss key word.

I'd say even more. AFAIR (I am using the extension to fix the problem) with many headers you can't see message text because headers pane take all the space

When headers are long and I use View->Headers-All I can not see the complete headers because no vertical scroll bar appears with 1.5.0.9. One work around is to save the entire message to an ascii file and then use vi to review the headers. Having the ability via a scroll bar to see all of the headers and the message would save time and be the right thing to do. Perhaps version 2.0 coming out soon will fix this. One can always hope.

Cheers,
Bob

(In reply to comment #103)
> (In reply to comment #100)
...
> It will be nice to see this patch land. Thanks.

(In reply to comment #109)
> we'd consider a patch for this.
>

??? What became of this and the other patch?

(In reply to comment #106)
...
> so I thought I'd toss this rumor in the pot ;o)
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=331924

That was fixed on trunk. This is on "unspecified". Can we get that "unspecified" changed to either branch, trunk, or all (both?)?

Thanks.

We just discussed this on mozillazine:
  http://forums.mozillazine.org/viewtopic.php?p=2746466

So there is already an extension to resolve this:
  http://cweiske.de/misc_extensions.htm#headerScroll

But, honestly, it's a BUG - and it's a bit strange people can not get this bug fixed after FOUR DAMN YEARS !

I read the Mozillazine thread. What was discussed, does the same thing as the attachment I submitted for this bug on July 14, 2004. Both the fix discussed in the thread and the attachment listed above, also adds a horizontal scroll bar which essentially does nothing since it cannot be moved much at all.

*** Bug 370652 has been marked as a duplicate of this bug. ***

Can someone please request a review so this patch can get applied and this bug will be fixed?

*** Bug 371366 has been marked as a duplicate of this bug. ***

Created an attachment (id=256305)
Patch

Created an attachment (id=256306)
Patch

Patch.

View->Headers->All
* set maxHeight to expandedHeader.
* set minHeight to messagepanebox.

View->Headers->All -> View->Headers->Normal
* remove maxHeight from expandedHeader.
* set default minHeight to messagepanebox.

So, If the height of messagepanebox is lower than maxHeight, messagepanebox will disappear.

I don't see the point of setting the max height programmatically?

*** Bug 373957 has been marked as a duplicate of this bug. ***

*** Bug 374769 has been marked as a duplicate of this bug. ***

*** Bug 378223 has been marked as a duplicate of this bug. ***

I just installed Thunderbird 2.0.0.0 - and the bug IS STILL THERE.
Dozens of people have made dozens of comments on this in several dozen months, among them several solutions.
This is becoming a really sad example of an open source quality management failure.

Yes, you have my full acknolage!

Mozilla Thunderbird is a shame for the hole open source community.

Please could you refrain from posting non-technical comments here, as they are off-topic for a bug tracker. Yes, this bug is quite annoying, but whining about here will not cause it to be fixed it any faster--only a working patch will do that.

To that end, has anyone tried the patch in comment #124? Did it work and/or cause any other problems?

Just wanted to add that when I installed Thunderbird 2, there is no scroll bar
on the right side of the window. I cant scroll up or down to view my mail
messages, I have to use the arrow keys.

Lonnie J

*** Bug 381327 has been marked as a duplicate of this bug. ***

(In reply to comment #131)
> To that end, has anyone tried the patch in comment #124? Did it work and/or
> cause any other problems?
>
I use SeaMonkey. Is it possible that SeaMonkey and Thunderbird react differently to the CSS patch? (Sorry, I haven't completely read all the comments.) In SeaMonkey, I get a horizontal scroll bar in addition to the vertical scroll bar when the header is set to view all. If I collapse the header, however, it collapses so that none of the header is visible, only the horizontal scroll bar.

This CSS works for me in SeaMonkey 2.0a.

#msgHeaderView {
 max-height: 16em !important;
 overflow-x: hidden !important;
 overflow-y: auto !important;
}

Can we get this bug fixed on branch also? I did a bug for branch, but it was duped to this one. Thanks.

*** Bug 418898 has been marked as a duplicate of this bug. ***

I can confirm this bug still exists in tbird version 2.0.0.12 (20080226) in openSuSE 10.3

for a current screenshot see:

http://www.3111skyline.com/download/screenshot/moz/lightning-view_all_headers_error.jpg

This also occurs when you double-click a message to open the message in its own window. There is no way to navigate down to see the message contents. See:

http://www.3111skyline.com/download/screenshot/moz/lightning-view_all_headers_error_fullwindow.jpg

Let me know if I can send any additional information.

Related to this bug: Long mail headers are printer over the status bar in small windows or in case of very long headers, as can also be seen in the screenshot of David Rankin.

I don't think this blocks, but this seems a reasonable request.

If someone could check whether this patch needs to be updated for trunk, we can look at driving it in a shredder alpha.

Created an attachment (id=324904)
Patch v2

The change suggested on m.d.a.thunderbird has less of a hit and only involves changing theme CSS; attached is a patch for that change, but in the relevant theme files instead of userChrome.css. This works on Thunderbird trunk as of 2008-06-13 22:00 UTC.

This solution is also the one given in bug 240313, so these bugs should probably be linked in some way. The discussion on that bug points out a number of issues with this approach as of January 2007. I'll have a look into them to see if they're still relevant, but I think that this is such a usability gap that any fix is better than none.

This bug is clearly a program malfunction and not a "usability gap". How many percent of TB users are willing and capable to fiddle around with stylesheets?
"Any fix is better than none" is certainly true wisdom in this case - after almost 5 years.

(In reply to comment #139)

Note that this fix adds a vertical scrollbar where necessary, but not a horizontal one in the event of long lines.

(From update of attachment 324904)
My CSS fu is not yet strong, and Phil has volunteered to have a look at this, so redirecting review request to him. No sr necessary, since mail/ doesn't require any.

*** Bug 234078 has been marked as a duplicate of this bug. ***

*** Bug 439345 has been marked as a duplicate of this bug. ***

Devs,

    Great news, I saw the patch being floated. Question - Is there anywhere in my install on openSuSE 10.3 tb install I can test it? I see it applies to cvsroot/...../messageHeader.css, but that file doesn't exist in the rpm install on openSuSE. Is there a similar style-sheet included that I could hack to test it?

Thanks for your great work.

The hack applys to the default Theme. Found in Tb program folder/Chrome/... On Windows platform it is contained in the classic.jar file that needs to be un-archived with an unzip tool. Find the *.css file and apply the hack. Reverse back to the *.jar and test on restart of Tb.

(In reply to comment #147)
> The hack applys to the default Theme. Found in Tb program folder/Chrome/... On
> Windows platform it is contained in the classic.jar file that needs to be
> un-archived with an unzip tool. Find the *.css file and apply the hack.
> Reverse back to the *.jar and test on restart of Tb.
>

On openSuSE 10.3, I just put it in userChrome.css and restarted. Works like a champ. One question though,

     "Why the use of separate windows and scroll bars for the header window and body window?"

Nothing wrong with it, it's just the first time I've seen it done like that. Thanks for the fix!

I can't believe this.
After almost 5 years, 147 comments in this thread, we are still discussing about patches, workaround, hacks, and still having the problem in the standard release.
A very simple problem though: any window or subwindow should have a scroll bar if the text needs more space than available.

This issue is really not a good example of the efficiency of open source development. :-(

(P.S. replies like "why not joining the development team yourself" please abstain...)

> A very simple problem though

If you have read comments above, you would have understood that message pane is total mess of a code nobody want to touch.

There are some politicking behind the scene too. Much superior message pane of Netscape Messenger 4.x was replaced by the dysfunctional silliness we have now in Tb (inhereted from SeaMonkey). My bug about returning back back Messenger 4.x message pane (or good recent implementation found in e.g. Mac OS X Mail.app (random screen shot from net: http://www.theappleblog.com/wp-content/uploads/mailstd.png )) was dupped to this bug.

Having any fix here is already helpful. But the kind of fix we have here means that still nobody wants to touch the message pane. So Tb is doomed to have it for some time.

(In reply to comment #148)

> On openSuSE 10.3, I just put it in userChrome.css and restarted. Works like a
> champ. One question though,
>
> "Why the use of separate windows and scroll bars for the header window and
> body window?"
>
> Nothing wrong with it, it's just the first time I've seen it done like that.
> Thanks for the fix!

Should the patch itself be saved AS the userChrome.css file in the /chrome directory?

If so, it does not work with SeaMonkey. It had the same effect as having no such file, the more headers they are, the less space for the actual e-mail message - no scroll bars.

I already had a userChrome.css file (consisting of the attachment I added almost four years ago, first one in the attachment list above), which provides both horizontal and vertical scroll bars, but the horizontal scroll bar doesn't move much. The attachment was provided via a newsgroup back then.

If the patch (Patch v2) should be applied in a different manner, please advise.

Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.8.1.16pre) Gecko/20080614 SeaMonkey/1.1.10pre (Mandriva Linux 2008 Spring)

*** Bug 240313 has been marked as a duplicate of this bug. ***

(In reply to comment #140)
> This solution is also the one given in bug 240313, so these bugs should
> probably be linked in some way. The discussion on that bug points out a
> number of issues with this approach as of January 2007.

This is causing me peevishness, but rather than comment extensively, I'll simply point out that the CSS at that bug's patch is arguably superior to the CSS in this bug's patch.

> +#expandedHeaderView {
> + max-height: 14em;
> + overflow: auto;
> +}
> +

isn't "ch" available on trunk as a height unit?

Since em is the equivalent of font-size, while ch is the equivalent of the width of the 0 character, what would that buy us (other than the all-important CHee-factor, of course)? A shorter pane for people using a font that's narrower than average?

And since I don't think we should ignore the problem addressed by Kurosawa-san's patch, that if you trigger All Headers while you have the height of the message pane smaller than the max-height we give to expandedHeaderView, it will still spill over the statusbar, we only need to argue about appropriate units if someone has an idea for setting minHeight on the message pane in a way other than through .minHeight.

(Oh, and I'm not *just* ignoring my review duties here: because Pinstripe sets some margin and padding in the header pane, rather than just ramming the longest header label up against the left side like Qute does, just setting overflow-y on expandedHeaderView isn't a pretty solution, so unless someone else with a Mac wants to work on it, we'll have to wait while I figure out how to manage the last couple of pixels of unnecessary but still present horizontal drag-scrolling.)

Could a fix for Qute be checked in and a fix for Pinstripe checked in later?

(From update of attachment 256306)
The resizing is undeniably cute, but as mentioned elsewhere, Pinstripe needs more than just overflow, and we don't ever want to get into the state of scrolling horizontally.

(From update of attachment 324904)
And, while we can take a patch to just Qute if we need to, the redesign to make headers scroll with the message, so we won't need to, is building some momentum.

Not fixed on TB 3a3:

Just tested the latest alpha3 release of Thunderbird3 - the bug is still not fixed. Folks, this thing is really getting funny ...

(In reply to comment #160)
> Not fixed on TB 3a3:

What made you think it would be?

> Just tested the latest alpha3 release of Thunderbird3 - the bug is still not
> fixed. Folks, this thing is really getting funny ...

Please, do read: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Especially: No pointless comments and No obligation.

I would like to see this bug fixed as much as you but since I cannot contribute anything (money, code, technical advice...), I don't think I have a right to complain about it.

(In reply to comment #161)
> Please, do read: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
>
> Especially: No pointless comments and No obligation.

For this special case - a 5 year old bug - I consider it appropriate to remind "folks" to finish the issue.

And it seems you also considered it fair to disobey the etiquette in this (meta-) case ...

>>but since I cannot contribute
anything (money, code, technical advice...), I don't think I have a right to
complain about it.

Pardon me if I do not agree with you, but IMHO open source developers do not have only the rights to work for the fun of it, but they also have duties.
Let me explain: when a commercial developers put a product on the market and get money for it, we consider as normal that they offer some waranty that the product will work as advertised, and that bugs will be corrected.
When some other developers put an equivalent product on the market for free, they simply kill other commercial products.
In that sense, I say that open source developers do not only take some other commercial product's market, they should also assume the responsability of providing the same kind of service.
Open source developers do not contribute by altruism, they do it because first they have fun, secondly they have the time to do it.
And if people like you and me use their product, it is not just to thank them because they are nice enough to give away their work.
It is also because they have wiped other products off the market.

Ok, so now several folks are deviating into "irrelevant" territory. The comment about open source developers wiping out products, in the context of Thunderbird, is quite funny, though.

Please stop: adding random comments on this bug makes it _less_ likely to get addressed.

(In reply to comment #164)
> Please stop: adding random comments on this bug makes it _less_ likely to get
> addressed.

Prawda? So Mozilla quality management means:
"You may only complain if you can improve, otherwise you might upset the real workers."
Can't quite believe this is true ...

(In reply to comment #162)
> For this special case - a 5 year old bug - I consider it appropriate to remind
> "folks" to finish the issue.

Precisely that it is 5 years-old shows that this isn't special. It may be for you but obviously not special enough to have deserved the effort from your side (you, me or anyone else) to fix it nor to find a replacement for Thunderbird.

> And it seems you also considered it fair to disobey the etiquette in this
> (meta-) case ...

I sent a reminder of the etiquette after a violation of it. But if you feel better thinking that you are vindicated if my reminder also broke etiquette rules...

As for this this (possibly) pointless comment, I am writing it because, like you and many, I was frustrated of long-standing bugs and I know the feeling. Then I started to contribute to a software libre project and had to deal with bug reports and I understood. If the above message can make understand at least one person, it would have been worth it.

(In reply to comment #163)
> >>but since I cannot contribute
> anything (money, code, technical advice...), I don't think I have a right to
> complain about it.
>
> Pardon me if I do not agree with you, but IMHO open source developers do not
> have only the rights to work for the fun of it, but they also have duties.

This is not a matter of opinions but a matter of facts. They do not have the duty to fix bugs. Period. You are wrong and negating reality only leads to frustration and despair.

(I was also wrong for a while. It is a common misconception.)

> Let me explain: when a commercial developers put a product on the market and
> get money for it, we consider as normal that they offer some waranty that the
> product will work as advertised, and that bugs will be corrected.

I don't see Outlook's open bugzilla, do you? Nevertheless, they get money for selling their software, not for fixing bugs. Fixing bugs may help or may not help sell the software, depending on the bug. Some bugs may help sell a later version of the software.

> In that sense, I say that open source developers do not only take some other
> commercial product's market, they should also assume the responsability of
> providing the same kind of service.

You are free to believe whatever you fancy. Reality is that they do not have such responsibility. They may have a desire to provide a good product but it is up to them and/or their employers and/or contractors to define what that means.

> Open source developers do not contribute by altruism, they do it because first
> they have fun, secondly they have the time to do it.

There are many reasons to work on open-source software: being paid, fixing a bug, implementing a desired feature, altruism, ethical ideas, friendship... How many thunderbird developers have you sampled to reach your conclusion?

> And if people like you and me use their product, it is not just to thank them
> because they are nice enough to give away their work.

People like you and me use their product because we judge that it maximises a cost/benefit ratio, where cost may include economical and ethical costs and benefit includes an assessment of the features versus the bugs.

> It ...

(In reply to comment #165)
> "You may only complain if you can improve, otherwise you might upset the real
> workers."

I doubt anyone gets upset that easily. But people can't keep up with the useful stuff - at all - if the noise factor is to high. (We already know what we need about this!)

(In reply to comment #167)
> We already know ...
Yes, as mentioned before (i.e. #147), solutions are there, I tested one and it worked, others are reported to work as well.
Now what's funny is that a solution is still not included in the public release.
This seems to be less a problem of missing enthusiams by capable developers but an organizational phenomenon. It is by my experience often better in these kind of cases to reduce the number of people directly involved, including oneself.
And yes, I believe it does help the organizers to be reminded that there are people out there who care.

>>This seems to be less a problem of missing enthusiams by capable developers but an organizational phenomenon.

Yeah, unless it is a problem of missing capability by enthusiatic developers ;-)

(In reply to comment #165)
> Prawda? So Mozilla quality management means:
> "You may only complain if you can improve, otherwise you might upset the real
> workers."
> Can't quite believe this is true ...

Haven't you heard "Shut up and show us a code" yet? I think this is the right time to tell it to you.
http://slashdot.org/features/98/10/13/1423253.shtml

(In reply to comment #170)
> .. Shut up and show us a code ..

Read #118 and #139 and look here:
http://www.juergen-ernst.de/addons/headerscroll.html

As long as the perfect (Qute) solution is in the works, this should be a resonable step.
Sorry if I stepped on feet and thanks for all the good work :-)

(In reply to comment #164)

> Please stop: adding random comments on this bug makes it _less_ likely to get
> addressed.

Random comments:

Comments like the above quote made me decide to stop reporting bugs to this organization.

A bug like this should have been fixed LONG AGO. If no one wants to fix it, fine, it only makes your product look bad.

>>Comments like the above quote made me decide to stop reporting bugs to this
organization.

This, plus the amazing complexity and inefficiency of the search engine to make sure a bug has not been reported yet.

>>A bug like this should have been fixed LONG AGO.

And you know the best? After five years, this bug has been "Assign To: Nobody" !

Who the heckassigns bug in here ?
If we really must contribute to get bugs fixed, then I'll VOLONTEER to assign bugs!

Please stop commenting on this bug without useful information how to fix this bug. If you want to have a discussion start a thread on Mozillazine but don't spam 105 CC members with a couple of useless comments. THANKS!!

>>don't spam 105 CC members with a couple of useless comments.

Tell me what's wrong sending useless comments in a useless bug report system?

(In reply to comment #173)
[...]
> Who the heckassigns bug in here ?
> If we really must contribute to get bugs fixed, then I'll VOLONTEER to assign
> bugs!

Normally, people only assign bugs to themselves or to nobody, so if you're willing to _work_ on a bug and fix it, rather than just talking, you're welcome to assign the bug to yourself. Beware though, that if you do, everyone will expect *you* to fix the bug.

Created an attachment (id=344790)
Fix

Conveniently enough, messagereader took out the pinstripe margins and padding, so mcow's version works fine for both. Let's land this, and take anything else elsewhere.

(From update of attachment 344790)
Pretty nice! r=mkmelin

http://hg.mozilla.org/comm-central/rev/72321e7bc355

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081027 Shredder/3.0b1pre ID:20081027025100 and on Windows.

*** Bug 479700 has been marked as a duplicate of this bug. ***

*** Bug 479700 has been marked as a duplicate of this bug. ***

*** Bug 483559 has been marked as a duplicate of this bug. ***

"Verified fixed"... - yes, and thanks a lot for that, but...
It looks as if we've jumped out of the frying pan into the fire!

Posted follow-up Bug 511408: Header pane should auto-resize and/or at least be resizable for large content (can't view many to-recipients when expanded, view all headers etc.)

Now we've got a scroll bar, but the header pane doesn't resize an inch any more (as it used to) when we expand long headers (e.g. lots of TO- or CC-recipients), or even view all headers. What is worse, we can't even resize it manually. So the maximum that we get to see at one glance in a "normal" header is 2 lines of addresses, which equivalents to 6 unknown email addresses that can be viewed at a time without scrolling. Which is a nuisance, because when I expand headers or even "view all headers", what I really want is to see more of them... I reckon that's a pretty regular scenario, any birthday invitation and surely lots of business emails can easily have more than 6 recipients, maybe 10, 20, 30? Even worse for "view all headers", all you can see at one glance is a couple of lines out of your total headers which can easily fill half a page or more. Very sad. Way too much inconvenience for the very basics of handling email - still.

*** Bug 526351 has been marked as a duplicate of this bug. ***

Created attachment 580669
Screenshot of missing scrollbar

This bug is back see attached header.

I think it is this bug rather than Bug #511408 which complains about resizing, but thinks the scrollbar is there.

Please file a new bug.

Comment on attachment 580669
Screenshot of missing scrollbar

This is now bug 709515.