Closed Bug 24454 Opened 25 years ago Closed 24 years ago

Crash scrolling in thread pane after resize

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: paulmac, Assigned: eric)

References

(
URL
)

Details

(Keywords: crash) 

I am getting a semi-reproducible crash in mail when scrolling the message pane.
I can reproduce it about 5% or 10% of the time when doing the following steps:

1. Make sure you are in a mail folder with enough messages so that you need a
scroll bar.
2. Scroll down and select the last message.
3. Resize the message pane a little larger.
4. Select the scroll bar as if to grab it and scroll up.

Results: I crashed about 4 out 50 times when following these steps.

I am using 1/19 win98 commercial build.

Link to talkback trace is shown below, but it contains no useful data that I can
see.

http://cyclone.mcom.com/reports/incidenttemplate.CFM?reportID=1007&style=0&tc=3&
cp=1&ck1=STrigger+event+reason&cd1=isNotNull&ck2=SBuild+ID&cd2=2000011909&bbid=4
146201
5 or 10%? Ugh. Sure would be nice to have a stack trace. Lisa, can you take this
and find the reproducible case? Thanks.
Assignee: phil → lchiang
I continue to see this on 1/20 build, let me know if you need help reproducing.
I will give this to Laurel, master bug reproducer, to try to find some 
reproducible steps :-) Laurel - can you try?
Paul, in step 4 when you say you grab the scroll bar, you're referring to the
message pane's scroll bar and not the thread pane's, correct?
QA Contact: lchiang → laurel
Thread pane, and also I mean thread pane when I say message pane in 3.  I had my 
mail lingo mixed up.

This is assuming thread pane refers to list of messages and message pane refers 
to content of selected message.
Summary: Crash scrolling in message pane after resize → Crash scrolling in thread pane after resize
Tried about 15-20 times or so to no avail.  Will keep trying and report back.


I'm still not seeing this problem with the steps given... Paul, do you have any
special type messages selected when you notice this? Maybe there's a clue in
what you were doing prior to selecting in the folder or did you have a compose
window open or something?


Okay, I tried for 15 minutes today and couldn't reproduce. Perhaps it got fixed 
by some other changes. You can mark it worksforme or whatever you do with this 
type of bug, and I will re-open if I keep seeing. 
OK, thanks for the help, Paul. I'll keep an eye out for it, but will mark it
worksforme at this point.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Marking verified (worksforme).
Status: RESOLVED → VERIFIED
okay I finally got a good stack trace, using m13 candidate builds, same steps to 
reproduce, though still hard to reproduce

   
   HandleEvent 
                                       
[d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 69]
     
   nsWindow::DispatchEvent 
                                       
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 506]
     
   nsWindow::DispatchWindowEvent 
                                       
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 523]
     
   nsWindow::DispatchMouseEvent 
                                       
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3467]
     
   ChildWindow::DispatchMouseEvent 
                                       
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3683]
     
   nsWindow::ProcessMessage 
                                       
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2769]
     
   nsWindow::WindowProc 
                                       
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 690]

Link to talkback report is in URL field.
URL: http://cyclone.mcom.com/reports/incid...
Status: VERIFIED → REOPENED
Giving back to phil, since there is a stack trace.
Assignee: lchiang → phil
Status: REOPENED → NEW
clearing resolution
Resolution: WORKSFORME → ---
I think rods has done most of the work in nsWindow, but I'm not sure he's the
current owner. cc'ing rickg just in case.
Assignee: phil → rods
scrolling is an evaughan issue.
Assignee: rods → evaughan
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
targeting
Status: NEW → ASSIGNED
Target Milestone: M14
*** Bug 23060 has been marked as a duplicate of this bug. ***
targeting
Target Milestone: M14 → M15
Note to QA: try the case mentioned in the duplicate bug when this bug is marked 
fixed.
Severity: normal → critical
Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.
Target Milestone: M15 → M16
Mass-moving all M16 non-feature bugs to M17, which we now consider to be part 
of beta2.
Target Milestone: M16 → M17
I spent 15 minutes trying to reproduce this crash (using the steps for this 
bug report and for duplicate bug #23060) but could not get a crash. 

However, using the steps to reproduce on bug #23060, I could certainly put 
the mailnews into an unusable and unpredictable UI state.

Lowering severity and moving out to M18, per trudelle.
Severity: critical → major
Target Milestone: M17 → M18
jrgm - the other dup bug is a bug which causes mail to get in an unstable state 
which you can reproduce and is marked a duplicate of this bug. You don't think 
that bug is severe enough?  
I was thinking (with blinders on) about these bug, and do they crash. Sorry.

After revisiting  bug #23060, and looking at how easy it is to wind up with 
an unusable UI by clicking on the splitter grippy, yes, I agree that this needs
to be fixed for nsbeta2.

However, this bug was for a crash, and I'd close this one as WORKSFORME if the 
initial reports didn't indicate that it was hard to reproduce.

I suggest that you reopen 23060, and nominate it for nsbeta2. The basic problem 
is that splitters seem to be behaving non-deterministically (and I have some 
simple test cases to attach).
I will reopen bug 23060 and nominate for nsbeta2 as you suggest.  I will leave 
this bug for you or evaughan to mark worksforme.  Thanks.
ok marking worksforme.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME
Marking verified (worksforme)
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.