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

VERIFIED FIXED

Status

SeaMonkey
MailNews: Message Display
P3
major
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: laurel, Assigned: Eric Vaughan)

Tracking

({pp})

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+] Fixed awaiting checkin)

Attachments

(5 attachments)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Created attachment 3962 [details]
call stack from tb incident 3608129
(Reporter)

Comment 2

18 years ago
Created attachment 3963 [details]
call stack from tb incident 3608789
(Reporter)

Updated

18 years ago
QA Contact: lchiang → laurel
(Reporter)

Comment 3

18 years ago
Created attachment 3964 [details]
macsbug report

Comment 4

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

Updated

18 years ago
Keywords: pp

Comment 5

18 years ago
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.
Assignee: phil → evaughan
(Assignee)

Comment 6

18 years ago
Targeting
Status: NEW → ASSIGNED
Target Milestone: M14

Updated

18 years ago
Summary: [PP] Combo resizing panes and hiding msg pane gets into a state... → Combo resizing panes and hiding msg pane gets into a state...
(Reporter)

Comment 7

18 years ago
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.
(Assignee)

Comment 8

18 years ago
targeting
Target Milestone: M14 → M15
(Assignee)

Comment 9

18 years ago
dup

*** This bug has been marked as a duplicate of 24454 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 10

18 years ago
verified dup.  Made note in other bug to try this case.
Status: RESOLVED → VERIFIED

Comment 11

18 years ago
Per jrgm@netscape.com, reopening since this case still exists, but bug 24454 
does not.  jrgm@netscape.com will attach some simple test cases to this bug 
report.
Severity: normal → major
Status: VERIFIED → REOPENED
Keywords: nsbeta2
Resolution: DUPLICATE → ---
Target Milestone: M15 → ---

Comment 12

18 years ago
Created attachment 8416 [details]
testcase; nested boxes with flex and splitter collapse="after"

Comment 13

18 years ago
Created attachment 8417 [details]
testcase; nested boxes with no flex and splitter collapse="after"

Comment 14

18 years ago
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

18 years ago
[nsbeta2+] Laurel, does this still crash?
Whiteboard: [nsbeta2+]
(Reporter)

Comment 16

18 years ago
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.

Updated

18 years ago
Blocks: 40158
(Assignee)

Updated

18 years ago
Whiteboard: [nsbeta2+] → [nsbeta2+] Fixed awaiting checkin
(Assignee)

Comment 17

18 years ago
fixed
Status: REOPENED → ASSIGNED

Comment 18

18 years ago
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)).
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 19

18 years ago
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.)
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.