234707 - Message Pane splitter jumps around when viewing messages

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Scott MacGregor]

It's possible to get into a state where the message pane / thread pane splitter
moves up and down as you view various messages. This happens most often when the
message has enough recipients that the recipients wrap to another line. The
message header area seems to "push up" into the thread pane space.

Comment 1

[Scott MacGregor]

Attachment: the fix, remove flex from the thread pane, use a fixed height, msg pane should be driven by flex only

Comment 2

[Scott MacGregor]

fixed on the m4 branch and the trunk

Comment 3

[Scott MacGregor]

Attachment: supplemental fix

the original patch causes account central to only have a height of 100 pixels.
This secondary fix addresses that issue.

Comment 4

[Scott MacGregor]

Attachment: additional fix needed to fix the wide 3-pane view

Comment 5

[Scott MacGregor]

both supplemental patches are in the trunk and the m4 branch

Comment 6

[[e-mail]]

There were at least two better ways of doing this, of which one could have been
found in attachment 129104 [details] [diff] [review].

Comment 7

[Scott MacGregor]

Hi Neil, can you elaborate more on what those two better solutions where? I took
a look at that attachment and modified a test build to use the box model and
UpdateMailPaneConfig method (which was tigher/cleaner than the JS I'm using
anyway) that you had in that attachment but I still see the splitter jump around
unless I make similar flex changes to what I did in this bug report.

I'm open to suggestions! Thanks.

Comment 8

[[e-mail]]

It wasn't the JS actually, it was the XUL... I have both height and minheight
set on the split elements which makes their size ignores their contents.
Just to be sure, I tried walking through a number of messages using the build
that I keep patched with attachment 129104 [details] [diff] [review] just in case it should get reviewed
and I didn't see any splitter movement.
I think (I haven't tested this alternative) the other way is to put a very large
amount of flex on the message pane box which makes the flex on the thread pane
"near zero" - except when you need to collapse the message pane, of course.

Comment 9

[Scott MacGregor]

sorry if I wasn't clear. in that test build I ported the xul and JS that you had
in  your attachment. And I still see the jumping. I find it easiest to see if
the overall window has a small size (such as the default size if you remove
localstore.rdf).

Then toggle back and forth between a message that has attachments and multiple
recipients in the cc field and one that has neither of these. I can get the
splitter to jump a good inch or two on my screen in that scenario. (Classic view)

I'll try your large flex idea too.

Comment 10

[Scott MacGregor]

Attachment: new way to fix the problem

this patch backs out the hack I was trying to use to fix this and instead adds
a large flex to the message pane box which is something Neil suggested.

I'm not seeing the jiggling on my test case anymore and I'm no longer seeing
all of the various UI regressions the previous approach was causing.

Thanks a lot Neil!

Comment 11

[Max Barry]

My apologies if this comment is going in the wrong place (I'm new here).

I'm experiencing very significant jumping of the Message Pane splitter when
viewing messages in Thunderbird 0.7.1 (20040710) in Vertical View layout on
Gentoo Linux/GNOME. 

Each previewed mail message expands the Message Pane as far horizontally as is
necessary for it to display *in full* every header line that contains an e-mail
address in "Long Name <[e-mail]>" format. (These lines are underlined
in blue.) Other header lines, even if they're "From:" or "To:", do not cause
this behaviour unless they're in that exact format. The behaviour is 100%
consistent and reproducible.

The effect on a 1024x768 display is to cause a great deal of highly distracting
message pane resizing as you move up and down messages with fairly long e-mail
names in them.