21342 - UI: Thread pane resizes proportionally with window

Status: NEW

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Peter Trudelle]

I like to size my thread pane so that it shows about a half-dozen headers,
leaving the remaining space for displaying message content (the primary purpose
of the window).  However, if I then resize the window vertically, to accomodate
a long message, both panes are adjusted proportionally, requiring another
readjustment to get the thread pane back to the size I want.

Note that the
sidebar gets this right, so that expanding the web pane to
accomodate a wide
page does not interfere with my sizing of the sidebar.

This may be intended
behavior, but it differs from 4.x (and I don't like it!).

Comment 1

[Phil Peterson]

Paul, can you see what we're doing differently from sidebar?

Comment 2

[Peter Trudelle]

This behavior is actually worse when shrinking the window - the thread pane can
disappear.

Comment 3

[hangas]

Easy fix.  Once I have a chance to checkin I will take care of this.  Marking
asap (personal whiteboard status).

Comment 4

[selmer (gone)]

Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.

Comment 5

[selmer (gone)]

Not beta2 stopper.  Marking M18.  Please let me know if you disagree.

Comment 6

[hangas]

Mass move mailnews bugs to Putterman.  Ouch.

Comment 7

[scottputterman]

moving to future milestone.

Comment 8

[timeless]

Hangas could you give a hint about how to do this? Thanks

Comment 9

[scottputterman]

reassigning to ssu

Comment 10

[[e-mail]]

Attachment: Proposed patch

Comment 11

[Stefan Borggraefe]

Attachment: Another Patch

This patch fixes the bug. Basically in order to fix the splitter at its
position, there needs to be the same "amount of flex" above and below it. In
this case this is a little bit problematic to achieve, because the two areas in
question are both inside a vbox that has flex="1" together with a third element
"searchBox". The solution to this problem is to set a ridiculously high flex
value for both areas, so the effect of the flex="1" of the surrounding vbox on
the searchBox is compensated.

I mark Neil's old patch obsolete, because I tested it and it doesn't work
anymore.

Comment 12

[[e-mail]]

<mumble at="mscott">just give me r+ on the port of the tb 3pane</mumble>

Comment 13

[Stefan Borggraefe]

(In reply to comment #12)
> <mumble at="mscott">just give me r+ on the port of the tb 3pane</mumble>

heh :-) 

But I think that wouldn't help in this case, because TB also has this bug.

Comment 14

[[e-mail]]

Oh sorry, I confused this with the folder pane bug...

Comment 15

[Stefan Borggraefe]

I tested the attached patch for a while now and found no negative effects. It
just fixes this bug. Nevertheless I feel a bit uncomfortable because of the high
flex value. What regressions could this cause if any? Or is this save?

Comment 16

[Stefan Borggraefe]

Comment on attachment 148495 [details] [diff] [review]
Another Patch

This patch doesn't work anymore (even after fixing the bitrot).

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to comment #2)
> This behavior is actually worse when shrinking the window - the thread pane can
> disappear.

no longer true given an enforced min height.
given that change, don't see how this bug is accessibility related.

Comment 18

[Tony Mechelynck [:tonymec]]

I suppose some "UI god" will have to make a decision on this bug. What is "the proper behaviour" when resizing the 3-pane window with Message List and Preview Pane both open? There are at least the following possibilities:
1) keep the list pane a fixed size (the behaviour this RFE wants)
2) resize list and preview panes proportionally (the current behaviour)
3) keep the preview pane a fixed size (which I would perhaps prefer if I didn't keep the preview pane closed)
4) any of the above at the user's choice with an about:config pref
5) same as (4) above, plus a radiobutton or drop-down on some Preferences pane ("Appearance" maybe, or "Mail&News"; note that both of these have already been migrated to the Toolkit backend).
Neil, what do you think?

Comment 19

[Tony Mechelynck [:tonymec]]

Addendum to comment #18
2 bis) resize proportionally, but with a minimum "preview pane" size and/or a minimum "list pane" size; revert to proportional when shrinking below (minPP + minLP).