23060 - Combo resizing panes and hiding msg pane gets into a state...

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[laurel]

Using 2000-01-04-08 on NT 4.0
Using 2000-01-04-08 on mac 0s 8.5.1
Can't yet reproduce on linux 6.0

Maybe machine/speed dependent

I'm able to fairly quickly get into a state where I can crash, hang the app, or
cause extreme delays in thread pane click response when exercising the resizing
of the message/thread pane via dragging the split bar in combination with
toggling the hide/show state of the message pane. When doing this while
selecting messages or selecting different folders to cause a refresh of thread
and/or message panes, it is fairly certain to result in a crash.

The most common case I saw was on NT 4.0, where I got into a state where there
was no horizontal split bar/grabber between message and thread panes. Inbox
(happened in both IMAP and POP) thread pane was displayed (large message list:
500+ messages), message pane hidden and no split bar grabber was shown (hidden
down under status bar?). When in this state and I selected a different message
in the thread pane, I crashed.

An extreme set of steps to create (repeat these kinds of things a few times
fairly quickly):

1.  Select/open a large folder in restored window mode, so that there are more
than one thread pane's list of messages listed.
2.  Drag thread pane slider to bottom of list.
3.  Drag thread/message pane horizontal split bar/grabber upward to the very top
of the thread pane, no message headers are able to be seen from thread pane.
4.  Click the split bar grabber a few times quickly to toggle the hidden state
of the message pane.  Select a (different) message in the thread pane and
immediately hide the message pane and select a different folder.

The above steps will most often result in a weird state for the mail window.

I have a couple crash reports, which I'll attach for the NT crash: incidents
3608789, 3608128.

Comment 1

[laurel]

Attachment: call stack from tb incident 3608129

Comment 2

[laurel]

Attachment: call stack from tb incident 3608789

Comment 3

[laurel]

Attachment: macsbug report

Comment 4

[Phil Peterson]

I can't reproduce this. Laurel, could you show me?

Comment 5

[Phil Peterson]

THe Mac stack trace shows splitters and boxes in the stack. Reassigning to
evaughan. Eric, you'll probably have to ask Laurel to show this to you. It's
pretty bizarre.

Comment 6

[Eric Vaughan]

Targeting

Comment 7

[laurel]

Using 2000-03-06-14 commercial build on NT 4.0:
This has gotten a lot worse... seems a lot easier to do now and completely blots
out the mail/news window thread pane.  All goes grey in the thread/message panes
and must exit/relaunch to correct.

1.  Open a large inbox. Close message pane.
2.  Scroll or use slider to meander through thread pane, select a message.
3.  Click grabber to snap the message pane open.
4.  Move the grabber upward to resize the message pane.
5.  Snap the message pane shut again and repeat scrolling through the thread
pane, making a couple subsequent selections (clicking ahead -- you'll see the
selection/highlight process is slooow).
6.  Snap the message pane open again.  Message and thread panes will be greyed
out, scrollbar incomplete, can't open message pane via snapping the grabber or
dragging it to resize -- unresponsive.  Minimize/maximize or seleting another
folder doesn't refresh.  Must exit.

Comment 8

[Eric Vaughan]

targeting

Comment 9

[Eric Vaughan]

dup

*** This bug has been marked as a duplicate of 24454 ***

Comment 10

[lchiang]

verified dup.  Made note in other bug to try this case.

Comment 11

[lchiang]

Per [e-mail], reopening since this case still exists, but bug 24454 
does not.  [e-mail] will attach some simple test cases to this bug 
report.

Comment 12

[John Morrison]

Attachment: testcase; nested boxes with flex and splitter collapse="after"

Comment 13

[John Morrison]

Attachment: testcase; nested boxes with no flex and splitter collapse="after"

Comment 14

[John Morrison]

Those testcases aren't really anymore than the basic case for 
using collapse="after|before" with the splitter and boxes. 

In the first one, clicking on the grippy can result in 
  1) after is collapsed/restored (correct)
  2) before is collapsed (incorrect) or restore (semi-correct)
  3) nothing happens (incorrect)
  4) the splitter and most of the boxes disappear (yikes!)

In the second one, pretty much all the time, the splitter and
boxes will disappear on the first click of the grippy

Comment 15

[Peter Trudelle]

[nsbeta2+] Laurel, does this still crash?

Comment 16

[laurel]

I'm not sure if it still crashes or not, since the hide/show gripper mechanism
isn't working very well (another bug logged about it).  I can't get it to crash
using today's m16 build -- 2000-05-16-09 on NT 4.0, but then again I can't get
it to the original bug state either in today's build.

Comment 17

[Eric Vaughan]

fixed

Comment 18

[John Morrison]

setting to fixed (as evaughan meant). Laurel -- is this still a problem. 
It seem to be working for me, but I wasn't absolutely sure what I was looking 
for.

[I did, though, notice a little oddity -- when you pull the splitter to the 
top (covering all of the thread pane), the treeheader of the thread pane 
appears above the contents of the message pane. It should be hidden. Do you 
have a bug for that already, or should I file it (ugh)).

Comment 19

[laurel]

The initial problem I reported is indeed fixed. I cannot get into that state
after trying repeatedly in either window layout.

The problem mentioned by John Morrison about the column headings appearing over
the splitter is indeed a problem, since it sometimes prevents the gripping of
the splitter.  I don't believe that's logged as a bug, will do so. (New bug
logged as bug #41032.)