Closed Bug 63654 Opened 24 years ago Closed 20 years ago

Folder pane shouldn't be resized when mail window is resized


(SeaMonkey :: MailNews: Message Display, defect)

Not set


(Not tracked)



(Reporter: david, Assigned: Stefan.Borggraefe)



(Keywords: verified1.7)


(4 files, 1 obsolete file)

Whenever I launch MailNews the first thing I do is carefully align the size of 
the folder pane so that it matches the width of the widest folder name (this is 
how I believe most people want it, at least the few ones I've asked). However, 
as soon as the MailNews main window is resized the folder pane is also resized 
If you increase the size of MailNews this means that space is wasted (folder 
pane with lots of whitespace) and if you decrease it the folders quickly become 
unreadable. I suggest that the folder pane size be fixed when entire window is 
Question: what if you had numerous filters setup, and this folder list was for
multiple accounts?  You could end up having long folder names.  What we do now
(this may be broken, currently), is show a tooltip when you hover/select the
folder name.  I don't think we want a fixed folder pane at all, at least I
wouldn't.  Users on all platforms have very different resolutions.

Bringing in some opinions...
Well, I still believe that the one to make the best judgement about which size
the folder pane should be is the user himself, if someone specifically moves the
separator so that the pane is some size it should mean that he/she wants it to
be that size. Note though that I'm mostly annoyed by Moz making the folder pane
wider than the width of the widest folder name, can we at least agree that
making the folders pane wider than the widest foldername is a waste of space? :-)
We are persisting the state/width of the folder pane though (not very reliable),
even upon restart of Mozilla.  Actually, I just saw the Folder Pane resizer
"bounce" at me. Accepting bug.
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
I believe I completely misunderstood you.  You are talking about the resizer
bouncing back at us, correct?
QA Contact: esther → nbaca
Well now I'm confused...what I was thinking about when I first entered the bug 
was that resizing the MailNews window would also resize the folders pane (in a 
somewhat unpredictable way). [Other things like the folder width not being saved 
between sessions (so it seems, I might be wrong) and Mozilla happily increasing 
the size of the folder pane, when mailnews window is increased, even though it's 
already wide enough to hold the entire name of all folders make things even 
worse]. Have we misunderstood each other? Should you or I elaborate even more?
(english isn't really my native language so I'm sorry for any confusion I might 
Hope screenshots makes my point somewhat clearer. I see two solutions:

1) Never resize folders pane when MailNews window is resized
2) Never increase size of folders pane beyond size of widest folder

(sorry for all the spam)
I agree that making the folder pane wider than the widest foldername is a waste
of space. 
Marking nsbeta1 because this would help users maximize the thread pane.

The problem occurs in the alternate-3pane window. The default 3pane window
resizes without making the folder pane larger (which is good).
Keywords: nsbeta1
marking nsbeta1-
Keywords: nsbeta1nsbeta1-
Summary: Folder pane shouldn't be resized → Folder pane shouldn't be resized when mail window is resized
info from bug 172859:

Horizontal Resize from right reduces folders pane size only (should reduce
message pane)

1. in main mail window, grab right edge of window
2. drag to left

- folder (left) pane is reduced in size

- message (right panes) should reduce in size

This is an annoying defect (not only because it makes testing message wrapping

Applicable Keywords: 
4xp, mozilla1.3, mozilla1.0.2, nsbeta1, nsbranch, nsCatFood, regression, ui
I agree that the folder pane should remain fixed at whatever size the user sets
it too, regardless of whether the width of the window is increased or decreased.
 The header pane (and message pane if the default layout is chosen) should be
resized instead.
This screenshot how the folder pane is made narrow when either 

A. one or more of the addresses in the message's header are longer than the
message body pane is wide, and/or 

B. the attachment window plus an address are are longer than the message body
panae is wide.
Actually, the previous screenshot shows a third cause for this annoying bug...

C. the Attachment Window plus the Subject Line are longer than the message body
pane is wide.

Damn, this bug is hard to test/repro accurately because of bug 172859. :(
*** Bug 195266 has been marked as a duplicate of this bug. ***
*** Bug 174474 has been marked as a duplicate of this bug. ***
*** Bug 181375 has been marked as a duplicate of this bug. ***
I'd say Bug 172859 is a dupe of this... If not, then Bug 195266 is a dupe of Bug
172859 and not this bug.
*** Bug 197033 has been marked as a duplicate of this bug. ***
This bug really **** me off today when i had to do a lot of selecting of mails
with attachments. The jittering of the folder pane size made me want to smash my
monitor! :( (i think i'm in the wrong bug :-\ )
Flags: blocking1.4?
yes please on blocking for 1.4
- this is the most annoying thing for me in mozilla at the moment

BTW: what's the procedure for the blocking elections?
Am i allowed to request that by using the blocking 1.4 drop down box, or is
there someone in charge that has the authority to do that?

Flags: blocking1.4? → blocking1.4-
About blocking for 1.4, just select the question mark in the drop down box and
that's it.  I did it and got this answer (no additional information):

Asa Dotzler <> has denied Eduardo Trápani
<>'s request for blocking1.4:

Bug 63654: Folder pane shouldn't be resized when mail window is resized

And I agree with you, it is extremely annoying, so much so that I will have to
consider another mail program for a while.  The pane flickers even while the
message is being loaded, that's way too uncomfortable to work with.

Maybe if we all asked for blocking 1.4 and if we all vote for this bug we will
get the developers attention.
Is this bug found in the Linux builds too?  I see it in Windows and MacOSX but
fail to recreate the problem in Linux (ppc).

(By the way, I didn't mean to whine about the resolution, just tried to answer
Russel about the idea of blocking 1.4.)
As far as I can tell, this bug is infact a 'feature' that was introduced fairly

My guess is that it wasn't 'implemented' in the PPC linux version.

Attached patch Patch (obsolete) — Splinter Review
This patch does the following:
 - removes the flex from the folderpane so it isn't resized when
   the main window is resized.
 - adds a default width to the folderpane, so it has a decent default
   size in a fresh profile even now that the flex is removed. The default
   size is specified in em, so you can see equally long account names
   with different font sizes.
 - the default size of the window is now specified in em, too. This way
   the folderpane isn't to large/small in comparison to the main window size
   when very large/small fonts are used.
 - removes the deprecated autostretch attribute from the folderPaneBox.
 - removes a style="height: 100px" which doesn't have any effect.

The last two items are not really related to this bug, but just some cleanup.
Assignee: sspitzer → borggraefe
Comment on attachment 140596 [details] [diff] [review]

What do you think, Neil?
Attachment #140596 - Flags: review?(
*** Bug 172859 has been marked as a duplicate of this bug. ***
Note: This bug is already fixed in TB.
Yeah, and I'm still waiting review of that fix ported to Mozilla :-(
Neil: Could you reconsider reviewing this simple patch (comment #27 should be
helpful)? I think this would be nice to have for 1.7 and your larger patch in
bug 105542 is most likely to complex for this release now.

Thanks and sorry for poking! ;-)
The fix for this bug also works around part of the "jiggle" bug, see bug 91622
comment 316.
ops, meant bug 91662 comment 316, sorry.
Comment on attachment 140596 [details] [diff] [review]

Scott, could you review this patch? See explanation in comment 27. Thanks! :-)
Attachment #140596 - Flags: review?( → review?(mscott)
Comment on attachment 140596 [details] [diff] [review]

as mentioned above, this patch is great. r=BenB.
Attachment #140596 - Flags: review?(mscott) → review+
Attachment #140596 - Flags: superreview?(mscott)
Attached patch Patch V1.1Splinter Review
I overlooked that there was a default size for the messenger window specified
in the default localstore.rdf.
Attachment #140596 - Attachment is obsolete: true
Attachment #140596 - Flags: superreview?(mscott)
Attachment #147885 - Flags: review?(ben.bucksch)
Attachment #147885 - Flags: review?(ben.bucksch) → review+
Attachment #147885 - Flags: superreview?(mscott)
(In reply to comment #37)
>I overlooked that there was a default size for the messenger window specified
>in the default localstore.rdf.
Yes, there's lots of cruft in localstore.rdf that can go by setting the
attributes correctly in the XUL.
Comment on attachment 147885 [details] [diff] [review]
Patch V1.1

note to self:

I need to see how these changes will interact with the different dynamic 3-pane
views in tbird before porting the fix to tbird.
Attachment #147885 - Flags: superreview?(mscott) → superreview+
Fix checked in. Thanks for the reviews! :-)
Closed: 20 years ago
Resolution: --- → FIXED
Comment on attachment 147885 [details] [diff] [review]
Patch V1.1

Asking for approval. This is low-risk and a nice UI-enhancement at the same
Attachment #147885 - Flags: approval1.7?
let's let this bake on the trunk for awhile and evalute...
Comment on attachment 147885 [details] [diff] [review]
Patch V1.1

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #147885 - Flags: approval1.7? → approval1.7+
Keywords: fixed1.7
Verified as fix on latest 1.7 branch 06-23 builds.
Changing keywords from fixed1.7 to verified1.7.
Leave this bug status "as is" until this bug be verified on trunk again...
Keywords: fixed1.7verified1.7
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.