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

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[David Härdeman]

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 
proportinally. 
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 
resized.

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

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

Comment 2

[David Härdeman]

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? :-)

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

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.

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

I believe I completely misunderstood you.  You are talking about the resizer
bouncing back at us, correct?

Comment 5

[David Härdeman]

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 
cause)

Comment 6

[David Härdeman]

Attachment: First I'm reading mail in a window...notice that the folder pane is (manually) sized so that all folders full names are shown

Comment 7

[David Härdeman]

Attachment: Then I decide I want some fullscreen MailNews....notice how the folders pane becomes huge and wastes lots of space.

Comment 8

[David Härdeman]

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)

Comment 9

[Ninoschka Baca]

I agree that making the folder pane wider than the widest foldername is a waste
of space. 

Comment 10

[Ninoschka Baca]

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

Comment 11

[scottputterman]

marking nsbeta1-

Comment 12

[Peter Lairo]

info from bug 172859:

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

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

Actual:
- folder (left) pane is reduced in size

Expected:
- message (right panes) should reduce in size

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

----------------------------------
Applicable Keywords: 
4xp, mozilla1.3, mozilla1.0.2, nsbeta1, nsbranch, nsCatFood, regression, ui

Comment 13

[Ian Brandt]

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.

Comment 14

[Peter Lairo]

Attachment: Screenshot showing this BUG

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.

Comment 15

[Peter Lairo]

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

Comment 16

[R.K.Aa.]

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

Comment 17

[R.K.Aa.]

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

Comment 18

[R.K.Aa.]

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

Comment 19

[Jay Knight]

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.

Comment 20

[R.K.Aa.]

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

Comment 21

[Peter Lairo]

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 :-\ )

Comment 22

[Russell]

yes please on blocking for 1.4
- this is the most annoying thing for me in mozilla at the moment

Russell

Comment 23

[Russell]

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?

Russell

Comment 24

[Eduardo Trápani]

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 <[e-mail]> has denied Eduardo Trápani
<[e-mail]>'s request for blocking1.4:

Bug 63654: Folder pane shouldn't be resized when mail window is resized
http://bugzilla.mozilla.org/show_bug.cgi?id=63654
----------

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.

Comment 25

[Eduardo Trápani]

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

Comment 26

[Russell]

As far as I can tell, this bug is infact a 'feature' that was introduced fairly
recently.

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

Russell

Comment 27

[Stefan Borggraefe]

Attachment: Patch

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.

Comment 28

[Stefan Borggraefe]

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

What do you think, Neil?

Comment 29

[Stefan Borggraefe]

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

Comment 30

[Stefan Borggraefe]

Note: This bug is already fixed in TB.

Comment 31

[[e-mail]]

Yeah, and I'm still waiting review of that fix ported to Mozilla :-(

Comment 32

[Stefan Borggraefe]

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! ;-)

Comment 33

[Ben Bucksch (:BenB)]

The fix for this bug also works around part of the "jiggle" bug, see bug 91622
comment 316.

Comment 34

[Ben Bucksch (:BenB)]

ops, meant bug 91662 comment 316, sorry.

Comment 35

[Stefan Borggraefe]

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

Scott, could you review this patch? See explanation in comment 27. Thanks! :-)

Comment 36

[Ben Bucksch (:BenB)]

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

as mentioned above, this patch is great. r=BenB.

Comment 37

[Stefan Borggraefe]

Attachment: Patch V1.1

I overlooked that there was a default size for the messenger window specified
in the default localstore.rdf.

Comment 38

[[e-mail]]

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

[Scott MacGregor]

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.

Comment 40

[Stefan Borggraefe]

Fix checked in. Thanks for the reviews! :-)

Comment 41

[Stefan Borggraefe]

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

Comment 42

[chris hofmann]

let's let this bake on the trunk for awhile and evalute...

Comment 43

[Asa Dotzler [:asa]]

Comment on attachment 147885 [details] [diff] [review]
Patch V1.1

a=asa (on behalf of drivers) for checkin to 1.7

Comment 44

[Karen Huang]

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