Closed Bug 223132 Opened 21 years ago Closed 13 years ago

need a scrollbar on the envelope panel (view all headers / long address lists)

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 3.0b1

People

(Reporter: lists, Assigned: philor)

References

Details

Attachments

(4 files, 4 obsolete files)

UserChrome.CSS file adding scrollbars to header window
1.28 KB, text/css
Details
Screenshot of CSS from comment 92, in TB 1.5
8.11 KB, image/png
Details
A sample message that makes this bug easy to reproduce.
24.81 KB, text/plain
Details
Fix
1.04 KB, patch
mkmelin
: review+
Details | Diff | Splinter Review 
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)
OS: MacOS X → All
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?
Hardware: Macintosh → All
This bug is either a dupe of bug 56825 or bug 9942

see bug 216605 for more info...
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. ***
Summary: need a scrollbar on the 'view all' mail headers → need a scrollbar on the envelope panel (view all headers / long addr lists)
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 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.
Flags: blocking-aviary1.1+
*** 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.
Flags: blocking-aviary1.5+ → blocking-aviary1.5-
*** 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
Flags: blocking-aviary2?
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 **** 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.
Flags: blocking-firefox2? → blocking-thunderbird2?
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?
(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.
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. ***
we'd consider a patch for this.
Flags: blocking-thunderbird2? → blocking-thunderbird2-
*** Bug 307054 has been marked as a duplicate of this bug. ***
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.
Attachment #243516 - Attachment mime type: application/octet-stream → text/plain
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.

Can someone please request a review so this patch can get applied and this bug will be fixed?
Attached file Patch (obsolete) — 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch (obsolete)
        — 
          — Splinter Review
      

    


  
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.
Assignee: mscott → taken.spc
Status: NEW → ASSIGNED

        Attachment #256306 -
        Flags: review?(mscott)

        Attachment #256305 -
        Attachment is obsolete: true

    
    

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

    
  
QA Contact: front-end

    
    

    
  
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


    
  
Flags: blocking-thunderbird3?

    
  
Blocks: 287731

    
  
Blocks: 234078

    
    

    
  
(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;
}



    
    

    
  
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.
Flags: blocking-thunderbird3? → wanted-thunderbird3+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v2 (obsolete)
        — 
          — Splinter Review
      

    


  
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.

        Attachment #324904 -
        Flags: superreview?(dmose)

        Attachment #324904 -
        Flags: review?(dmose)

    
    

    
  
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.


        Attachment #256306 -
        Flags: review?(mscott) → review?(philringnalda)

    
    

    
  
Comment on attachment 324904 [details] [diff] [review]
Patch v2

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.

        Attachment #324904 -
        Flags: superreview?(dmose)

        Attachment #324904 -
        Flags: review?(philringnalda)

        Attachment #324904 -
        Flags: review?(dmose)

    
  
No longer blocks: 234078

    
    

    
  
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)





    
    

    
  
(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?

    
    

    
  
Comment on attachment 256306 [details] [diff] [review]
Patch

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.

        Attachment #256306 -
        Attachment is obsolete: true

        Attachment #256306 -
        Flags: review?(philringnalda)

    
    

    
  
Comment on attachment 324904 [details] [diff] [review]
Patch v2

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.

        Attachment #324904 -
        Attachment is obsolete: true

        Attachment #324904 -
        Flags: review?(philringnalda)
Assignee: taken.spc → nobody
Status: ASSIGNED → NEW

    
    

    
  
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 is also because they have wiped other products off the market.

Quoting myself: "Negating reality only leads to frustration and despair."

http://kontact.kde.org/kmail/
http://www.novell.com/products/desktop/features/evolution.html
http://sylpheed.sraoss.jp/en/
http://www.claws-mail.org/

I only mention a few that are software libre, because non-libre ones do not meet my cost/benefit minimum. Perhaps your cost/benefit is different.

I won't continue this off-topic discussion. Apologies to the rest of subscribers.

    
    

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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Fix
        — 
          — Splinter Review
      

    


  
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.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED

        Attachment #344790 -
        Flags: review?(mkmelin+mozilla)
No longer blocks: 287731

        Attachment #344790 -
        Flags: review?(mkmelin+mozilla) → review+

    
    

    
  
Comment on attachment 344790 [details] [diff] [review]
Fix

Pretty nice! r=mkmelin

    
    

    
  
http://hg.mozilla.org/comm-central/rev/72321e7bc355
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b1
Version: unspecified → Trunk

    
    

    
  
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.
Status: RESOLVED → VERIFIED
Depends on: 464499

    
    

    
  
"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.
Summary: need a scrollbar on the envelope panel (view all headers / long addr lists) → need a scrollbar on the envelope panel (view all headers / long address lists)

    
    

    
  

      
      
      
      

        Attached image
          
        Screenshot of missing scrollbar (obsolete)
        — 
      

    


  
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.

    
  
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Please file a new bug.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 13 years ago
Resolution: --- → FIXED

    
    

    
  
Comment on attachment 580669 [details]
Screenshot of missing scrollbar

This is now bug 709515.

        Attachment #580669 -
        Attachment is obsolete: true

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: