21471 - [DOGFOOD] Crash when scrolling in address field

Status: VERIFIED FIXED

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

Description

[ppandit]

Using release build from 12/10/99 on Windows NT

1) Start messenger
2) Select a message
3) Do a REPLAY ALL - notice that only one recepient is listed in address field.
There should have been three.
4) Start scrolling using the scrollbar in the address field to look for other
recepients.
5) Crash - Unhandled exception in mozilla.exe 0xC00001D Illegal instruction

Able to reproduce.

Comment 1

[lchiang]

I think that alec may have a bug on this.  Reported by karen, I think. Par, can
you do a search for scroll and address book to see what you come up with?
Thanks.

Comment 2

[ppandit]

Lisa - the bug you are talking about is 20508. But in that bug, the scrolling
problem occurs with the IMAP folders pane. This bug is with the Compose address
field scrollbar.

Comment 3

[lchiang]

ok, I have many bugs mixed up.  assign to alec for now.

Comment 4

[Alec Flett]

There have been alot of general problems with scrollbars in the last day or two.
I'm going to hold off looking at this until the general problems are fixed.

Comment 5

[Phil Peterson]

Nominate for dogfood

Comment 6

[Alec Flett]

bet you a dollar this is already fixed.

Comment 7

[leger]

Putting on PDT+ radar.

Comment 8

[Alec Flett]

yup, sure enough, the focus/event problems with the scrollbar that were fixed
this weekend fixed this bug too.

Comment 9

[Alec Flett]

I should add that I scrolled this thing up and down many times with 5
receipients, using both the thumb and the arrow keys, and it never crashed.

Comment 10

[ppandit]

I installed 12/13 release build.
Selected a message, did a REPLY ALL, got all three recepients this time,
and then started to scroll =>
CRASH: Unhandled exception in mozilla.exe 0xC0000005 Access Violation

Reopening bug until get a release build that does not crash
Making ppandit as the QA Contact

Comment 11

[Alec Flett]

argh. that's exactly what I did.
Ok, I'll try again
Par, can you try this on Linux too?
I'm wondering if it's a windows-only thing

Comment 12

[Alec Flett]

can I get a stack trace too?

Comment 13

[ppandit]

I tried it on Linux using 12/13 build and it crashes (actually no error
message, application just dies).

I am building a debug version and will get you trace when it is ready.

Comment 14

[lchiang]

I got this to reproduce on my Linux system as well.

You have to grab the slider bar and move it up and down a few times.  That's
what I did.  Par or I can show you, Alec.

Comment 15

[Jean-Francois Ducarroz]

*** Bug 20978 has been marked as a duplicate of this bug. ***

Comment 16

[Jean-Francois Ducarroz]

From my comment in bug 20978:

I was able to reproduce the crash on Windows with a debug build from this
morning:

1) New Message
2) type: A <return> B <return> C <return>
3) scroll down once
4) scroll up twice
5) ==> crash

it crash in nsGenericElement::GetParent() when trying to addref mParent because
mParent isn't null but contains invalid data (__vfptr = 0xdddddddd).

nsGenericElement::GetParent(nsIContent * & 0x00000000) line 721 + 24 bytes
AnonymousElement::GetParent(const AnonymousElement * const 0x0316213c,
nsIContent * & 0x00000000) line 74 + 18 bytes
nsCSSFrameConstructor::FindPrimaryFrameFor(nsCSSFrameConstructor * const
0x02d3cee0, nsIPresContext * 0x02d3b5b0, nsIFrameManager * 0x02d3c720,
nsIContent * 0x0316213c, nsIFrame * * 0x0012f5e4) line 8110
StyleSetImpl::FindPrimaryFrameFor(StyleSetImpl * const 0x02d3cf80,
nsIPresContext * 0x02d3b5b0, nsIFrameManager * 0x02d3c720, nsIContent *
0x0316213c, nsIFrame * * 0x0012f5e4) line 1057
FrameManager::GetPrimaryFrameFor(FrameManager * const 0x02d3c720, nsIContent *
0x0316213c, nsIFrame * * 0x0012f5e4) line 420
PresShell::GetPrimaryFrameFor(const PresShell * const 0x02d3cc60, nsIContent *
0x0316213c, nsIFrame * * 0x0012f5e4) line 2396 + 32 bytes
nsCSSFrameConstructor::ContentStatesChanged(nsCSSFrameConstructor * const
0x02d3cee0, nsIPresContext * 0x02d3b5b0, nsIContent * 0x03162f8c, nsIContent *
0x0316213c) line 7071
StyleSetImpl::ContentStatesChanged(StyleSetImpl * const 0x02d3cf80,
nsIPresContext * 0x02d3b5b0, nsIContent * 0x03162f8c, nsIContent * 0x0316213c)
line 984
PresShell::ContentStatesChanged(PresShell * const 0x02d3cc68, nsIDocument *
0x02d3aa90, nsIContent * 0x03162f8c, nsIContent * 0x0316213c) line 2209 + 46
bytes
nsXULDocument::ContentStatesChanged(nsXULDocument * const 0x02d3aa90, nsIContent
* 0x03162f8c, nsIContent * 0x0316213c) line 1283
nsEventStateManager::SetContentState(nsEventStateManager * const 0x02f094d0,
nsIContent * 0x03162f8c, int 0x00000004) line 1887
nsEventStateManager::GenerateMouseEnterExit(nsIPresContext * 0x02d3b5b0,
nsGUIEvent * 0x0012fb68) line 1044
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x02f094d0,
nsIPresContext * 0x02d3b5b0, nsGUIEvent * 0x0012fb68, nsIFrame * 0x00dd0130,
nsEventStatus * 0x0012fa74, nsIView * 0x03161390) line 188
PresShell::HandleEvent(PresShell * const 0x02d3cc64, nsIView * 0x03161390,
nsGUIEvent * 0x0012fb68, nsEventStatus * 0x0012fa74) line 2587 + 43 bytes
nsView::HandleEvent(nsView * const 0x03161390, nsGUIEvent * 0x0012fb68, unsigned
int 0x00000008, nsEventStatus * 0x0012fa74, int & 0x00000000) line 841
nsView::HandleEvent(nsView * const 0x02d3b220, nsGUIEvent * 0x0012fb68, unsigned
int 0x0000001c, nsEventStatus * 0x0012fa74, int & 0x00000000) line 826
nsViewManager::DispatchEvent(nsViewManager * const 0x02d3b440, nsGUIEvent *
0x0012fb68, nsEventStatus * 0x0012fa74) line 1678
HandleEvent(nsGUIEvent * 0x0012fb68) line 69
nsWindow::DispatchEvent(nsWindow * const 0x02d3b0f4, nsGUIEvent * 0x0012fb68,
nsEventStatus & nsEventStatus_eIgnore) line 421 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fb68) line 442
nsWindow::DispatchMouseEvent(unsigned int 0x0000012c, nsPoint * 0x00000000
{x=??? y=???}) line 3332 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 0x0000012c, nsPoint * 0x00000000
{x=??? y=???}) line 3550
nsWindow::ProcessMessage(unsigned int 0x00000200, unsigned int 0x00000000, long
0x006c0220, long * 0x0012fdc8) line 2620 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x00140300, unsigned int 0x00000200, unsigned int
0x00000000, long 0x006c0220) line 608 + 27 bytes
USER32! 77e71820()

the element which lead to the crash is a scrollbarbutton, that's what say its
tag.

Comment 17

[Jean-Francois Ducarroz]

Add Waterson and Hyatt to the cc list in case they have any clue about this
problem.

Comment 18

[Jean-Francois Ducarroz]

some time I get another crash:

nsBoxFrame::FlowChildAt(nsIFrame * 0x00dd57e0, nsIPresContext * 0x0291d1b0,
nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int &
0x00000000, nsCalculatedBoxInfo & {...}, int & 0x7ffdf0c4, nsString & {"To get
pref size"}) line 1125

Comment 19

[Jean-Francois Ducarroz]

Attachment: very simple test case to reproduce the crash

Comment 20

[Jean-Francois Ducarroz]

Using the crash21471.xul test case file, you can reproduce the crash doing this:

1) load into the browser the file crash21471.xul
2) select the first edit field and type something (like "a")
3) scroll down once
4) scroll up once
5) ==> CRASH

Comment 21

[Chris Waterson]

i'm gonna steal this from alecf.

Comment 22

[Jean-Francois Ducarroz]

Thanks Waterson. Let me now if I can help you on this.

Comment 23

[Alec Flett]

in the bug that was just marked as a dupe of this one, the stack trace is almost
exactly the same as in my other PDT+ bug 20508

That problem is due to the scrollbar going away before the mouseup though...or
so I thought.

Comment 24

[Alec Flett]

ducarroz's test case makes it sound like maybe it's something like the focused
edit field frame is getting destroyed.

However, that tree is not lazily instantiated, so I'm not sure the frames are
getting destroyed & recreated.

Comment 25

[Chris Waterson]

What appears to be happening is that an event is dispatched to an anonymous
content node after its parent is destroyed. An anonymous content node has a
weak reference to its parent, but the parent is oblivious of the anonymous
child. So, when the parent dies, the anonymous content can live on with a
dangling back-pointer to the parent.

I'm experimenting with nulling-out the anonymous content node's back pointer
when the frame is destroyed.

Comment 26

[David Hyatt]

Talked with alecf.  I believe if we call nsPresShell's ClearFrameRefs method
prior to destroying the scrollbar that we will take care of all these crashers
like this.

Comment 27

[Chris Waterson]

alecf: can you try that and let me know if it works for this test case?

Comment 28

[Alec Flett]

I'm working on this right now.. the anonymous node is the scrollbar in the
content frame.
I'm attaching a patch that I believe should work, but I accidentally updated too
much of my tree, so I'm having to rebuild half the world.

This should prevent the event from even hitting the first content node.

Comment 29

[Alec Flett]

Attachment: Clears frames that are going away from the event state manager

Comment 30

[Chris Waterson]

it's all you baby.

Comment 31

[Alec Flett]

ok, this is and isn't the problem
The real problem is like waterson said: weak referenced parents.

here's what's really going on: The scrollbar, a nsXULElement, has a number of
anonymous child contents. One of these anonymous children is holding a weak
reference to the scrollbar element.

If the scrollbar element ever goes away, there's no way that the children would
ever know.
This is bad of course... however it only manifests itself because the event
state manager is holding a strong reference to the anonymous button element as
mHoverContent, because it the event state manager wants to take it out of the
hover state at some point.

I'm going to try making the anonymous content get notified when it's parent goes
away, using the nsXULDocument... this will allow us to set the parent to null.
There may be further crashes beyond that however. I'll have to catch those too.

Comment 32

[Alec Flett]

waterson wanted to hear more:
when the anonymous content node is created, it adds itself as a document
observer. When ContentRemoved comes in, it checks to see if the parent is equal
to the content being removed.... if this happens, it calls SetParent(nsnull)

I just haven't figured out where to release itself as a document observer...
maybe the destructor..

The reason I have to do this is that the parent of anonymous content is only
connected to it's anonymous content via it's frame
(i.e. presshell.FrameFor(content).childFrames.frame[i].content is the only path
from a content node to it's anonymous content in the given pres shell)

this means that the parent never knows when it's being severed from it's
anonymous content.

Comment 33

[Chris Waterson]

Ooh, that's sexy. I like it. Why don't you just remove yourself at the same
time you detect that your parent is null. You ain't comin' back after that, are
you?

Comment 34

[Alec Flett]

So that solution should work (and boy is it sexy, as waterson points out), and I
got as far as implementing it before I realized how heavyweight it is.

Turns out, a simple tweak to my patch did exactly what I really wanted - setting
the parent to null when the scrollbar's frames go away. I didn't think about the
facts that:
a) we're killing the frames manually, so we know they're going away
b) we can actually get to all the child frames of the scrollbar (as opposed to
just mScrollbar)

So I'm attaching a new patch, no document observers needed.

Comment 35

[Alec Flett]

Attachment: Also clear child frame's

Comment 36

[Alec Flett]

With the fix to #20508, I'm getting a new crash if I scroll around alot, it
takes longer to occur, but it looks like it might be an uninitialized
variable...

Comment 37

[Alec Flett]

ugh, this new crash is REALLY scary, but happens exactly the same way every
time.
I need an expert in frame creation/destruction. Adding nisheeth because I think
the new crash is a side effect of some of the frame state work he did.

Here are the details on what's happening. First a stack trace:
(only pasting the top 20 or so frames because it's a 92-frame stack)
#0  0x408d0d81 in nsBlockFrame::nsIFrameDebug virtual table ()
#1  0x407792d9 in nsCSSFrameConstructor::GetFloaterContainingBlock (
    this=0x85a7e30, aPresContext=0x8582368, aFrame=0x884d160)
    at nsCSSFrameConstructor.cpp:5403
#2  0x4077d62a in nsCSSFrameConstructor::ContentChanged (this=0x85a7e30,
    aPresContext=0x8582368, aContent=0x884b3a4, aSubContent=0x0)
    at nsCSSFrameConstructor.cpp:6985
#3  0x40848a8f in StyleSetImpl::ContentChanged (this=0x8512970,
    aPresContext=0x8582368, aContent=0x884b3a4, aSubContent=0x0)
    at nsStyleSet.cpp:975
#4  0x40694ba1 in PresShell::ContentChanged (this=0x85a3798,
    aDocument=0x8659bf0, aContent=0x884b3a4, aSubContent=0x0)
    at nsPresShell.cpp:2237
#5  0x40dbe2e0 in ?? ()
   from /home1/alecf/seamonkey/mozilla/dist/bin/components/librdf.so
#6  0x40824592 in nsGenericDOMDataNode::SetText (this=0x884b3b0,
    aBuffer=0xbfffb5f8, aLength=31, aNotify=1) at nsGenericDOMDataNode.cpp:991
#7  0x4084a0c5 in nsTextNode::SetText (this=0x884b398, aBuffer=0xbfffb5f8,
    aLength=31, aNotify=1) at nsTextNode.cpp:73
#8  0x4074a22c in nsGfxTextControlFrame::Reflow (this=0x8844688,
    aPresContext=0x8582368, aDesiredSize=@0xbfffb90c,
    aReflowState=@0xbfffb7c4, aStatus=@0xbfffb8e4)
    at nsGfxTextControlFrame.cpp:1796
#9  0x407df961 in nsBoxFrame::FlowChildAt (this=0x8844648,
    childFrame=0x8844688, aPresContext=0x8582368, desiredSize=@0xbfffb90c,
    aReflowState=@0xbfffbb34, aStatus=@0xbfffb8e4, aInfo=@0x88c9510,
    aRedraw=@0xbfffb8e8, aReason=@0xbfffb8f4) at nsBoxFrame.cpp:1133
#10 0x407dea39 in nsBoxFrame::GetChildBoxInfo (this=0x8844648,
    aPresContext=0x8582368, aReflowState=@0xbfffbb34, aFrame=0x8844688,
    aSize=@0x88c9510) at nsBoxFrame.cpp:434
#11 0x407e04f5 in nsBoxFrame::GetBoxInfo (this=0x8844648,
    aPresContext=0x8582368, aReflowState=@0xbfffbb34, aSize=@0xbfffba14)
    at nsBoxFrame.cpp:1630
#12 0x407debb8 in nsBoxFrame::Reflow (this=0x8844648, aPresContext=0x8582368,
    aDesiredSize=@0xbfffbbd4, aReflowState=@0xbfffbb34, aStatus=@0xbfffce44)
    at nsBoxFrame.cpp:528
#13 0x4066afea in nsContainerFrame::ReflowChild (this=0x88445d8,
    aKidFrame=0x8844648, aPresContext=0x8582368, aDesiredSize=@0xbfffbbd4,
    aReflowState=@0xbfffbb34, aX=30, aY=0, aFlags=0, aStatus=@0xbfffce44)
    at nsContainerFrame.cpp:621
#14 0x407b8214 in nsTableCellFrame::Reflow (this=0x88445d8,
    aPresContext=0x8582368, aDesiredSize=@0xbfffbda8,
    aReflowState=@0xbfffbd08, aStatus=@0xbfffce44) at nsTableCellFrame.cpp:663
#15 0x407f4770 in nsTreeCellFrame::Reflow (this=0x88445d8,
    aPresContext=0x8582368, aDesiredSize=@0xbfffbda8,
    aReflowState=@0xbfffbd08, aStatus=@0xbfffce44) at nsTreeCellFrame.cpp:150
#16 0x4066afea in nsContainerFrame::ReflowChild (this=0x88229a8,
    aKidFrame=0x88445d8, aPresContext=0x8582368, aDesiredSize=@0xbfffbda8,
    aReflowState=@0xbfffbd08, aX=6520, aY=0, aFlags=0, aStatus=@0xbfffce44)
    at nsContainerFrame.cpp:621
#17 0x407c6db0 in nsTableRowFrame::InitialReflow (this=0x88229a8,
    aPresContext=0x8582368, aDesiredSize=@0xbfffc080,
    aReflowState=@0xbfffbef8, aStatus=@0xbfffce44, aStartFrame=0x0,
    aDoSiblings=1) at nsTableRowFrame.cpp:997
#18 0x407c77ef in nsTableRowFrame::Reflow (this=0x88229a8,
    aPresContext=0x8582368, aDesiredSize=@0xbfffc080,
    aReflowState=@0xbfffbfe0, aStatus=@0xbfffce44) at nsTableRowFrame.cpp:1390
#19 0x407f5e57 in nsTreeRowFrame::Reflow (this=0x88229a8,
    aPresContext=0x8582368, aDesiredSize=@0xbfffc080,
    aReflowState=@0xbfffbfe0, aStatus=@0xbfffce44) at nsTreeRowFrame.cpp:209
#20 0x4066afea in nsContainerFrame::ReflowChild (this=0x882291c,
    aKidFrame=0x88229a8, aPresContext=0x8582368, aDesiredSize=@0xbfffc080,
    aReflowState=@0xbfffbfe0, aX=0, aY=0, aFlags=0, aStatus=@0xbfffce44)
    at nsContainerFrame.cpp:621
#21 0x407c8a15 in nsTableRowGroupFrame::ReflowMappedChildren (this=0x882291c,
    aPresContext=0x8582368, aDesiredSize=@0xbfffc2b0,
    aReflowState=@0xbfffc140, aStatus=@0xbfffce44, aStartFrame=0x0,
    aReason=eReflowReason_Resize, aDoSiblings=1, aDirtyOnly=0)
    at nsTableRowGroupFrame.cpp:463
#22 0x407c9bf2 in nsTableRowGroupFrame::Reflow (this=0x882291c,
    aPresContext=0x8582368, aDesiredSize=@0xbfffc2b0,
    aReflowState=@0xbfffc210, aStatus=@0xbfffce44)
    at nsTableRowGroupFrame.cpp:1060

Comment 38

[Jean-Francois Ducarroz]

*** Bug 21843 has been marked as a duplicate of this bug. ***

Comment 39

[Alec Flett]

ok, so the reason that the top frame is in nsFrame::nsIFrameDebug is that the
frame we're calling containingBlock->GetStyleData() in frame 1, but
containingBlock is a deleted frame, as passed to GetFloaterContainingBlock() in
that frame..

The frame is coming from line 6956 of nsCSSFrameConstructor:
  shell->GetPrimaryFrameFor(aContent, &frame);

aContent is the text node for the HTML element... somehow the frame manager for
the shell doesn't know that the node has gone away.... I don't know enough about
PresShell and the frame manager to understand how the frame manager is supposed
to know that that node went away...

my guess is that mFrameConstructor->RemoveMappingsForFrameSubtree is not
clearing out the primary frame for the content contained in the html:input.

Nisheeth? Any thoughts?

Comment 40

[Alec Flett]

ok, I have two potential workarounds here.
I noticed that in nsGfxTextControlFrame::Reflow() we're doing a
nsTextFrame::SetText() and then later creating the frame for this text, and
setting the primary frame to this text node.

My first workaround was to only set notify to true when mDisplayContent was not
null but I realized that was lame, and it still crashed, just in a slightly
different place.

Instead, I'm going to try explicitly setting the primary frame for the text to
nsnull before calling SetText. What I'm wondering is if we can just set aNotify
to PR_FALSE, since we're recreating the text frame at this point anyway.

I'm adding buster to the CC so he can take a look at this too.
buster, see frames 8 and 7 above, specifically this line:
              mDisplayContent->SetText(initialText, len, PR_TRUE);
I'm wondering if PR_TRUE is the correct notification here anyway (and see that
later we're unconditionally recreating the frames)

Comment 41

[Alec Flett]

yes! So by setting the primary frameforcontent to nsnull right before calling
SetText, the crash goes away!
I'll attach a patch, just so buster can see what I'm doing (it's hacky, I will
clean up before submitting for final review)

But it would be nice to know about the notify issue, because that might clean it
up anyway.
I'm going to try it with notify set to PR_FALSE to see if that breaks anything
else.

Comment 42

[Alec Flett]

Attachment: clear the primary frame before setting the text (hack that works)

Comment 43

[Alec Flett]

Ok, I've got a cleaned up patch that I'm sending to buster for review.
It turns out if I set notify to PR_FALSE, it still crashes somewhere in XUL.

Comment 44

[Alec Flett]

Attachment: Clear the primary frame before setting text (cleaned up)

Comment 45

[Alec Flett]

One other thing - I still can't make it crash on linux with this new patch, and
Jean-Francois tried it and says he can't make it crash on Mac either.

Comment 46

[Jean-Francois Ducarroz]

My test was on Window and not on Mac.

Comment 47

[Alec Flett]

ok, after getting my code reviewed by buster, I have yet another way to fix this
problem, one that is alot cleaner.
I'm waiting to hear back from him. It essentially does the same thing as this
patch, but does it in a more general way, by calling the GfxTextControlFrame's
nsCSSFrameConstructor's RemoveMappingsFromSubtree() which will have the same
effect.

so now the status is I'm waiting for a review from buster and/or troy. (thanks
guys)

Comment 48

[chris hofmann]

final m12 candidates are spinnning now. moving to m13.
if we fall off track and need to respin m12 for some
yet unknown reason we can consider this if you get
a fix in hand.

Comment 49

[Alec Flett]

yeah! After review & discussion with troy/buster, the fix has been checked into
the trunk. This will NOT be in the M12 builds unless they respin.

Comment 50

[chris hofmann]

alecf, if your still around tonight lets go and put these on
SeaMonkey_M12_BRANCH

builds are delayed until first thing Friday morning.

Comment 51

[lchiang]

Par - all ok for you now?

Comment 52

[ppandit]

Using a debug build from 1/3/99 on Windows NT:

I am still getting a crash. The error is
Unhandled exception in mozilla.exe (RDF.DLL) 0xC0000005

Trace:
nsXULDocument::AttributeChanged(nsXULDocument * const 0x040f3230, nsIContent *
0x04854550, int 0, nsIAtom * 0x01cefa30, int -1) line 1421 + 25 bytes
nsXULElement::SetAttribute(nsXULElement * const 0x04854550, int 0, nsIAtom *
0x01cefa30, const nsString & {...}, int 1) line 2235
nsSliderFrame::SetCurrentPosition(nsIContent * 0x04854550, nsIFrame *
0x0420f5f8, int 0) line 687 + 38 bytes
nsSliderFrame::HandleEvent(nsSliderFrame * const 0x0420f59c, nsIPresContext *
0x040f5f10, nsGUIEvent * 0x0012fb68, nsEventStatus * 0x0012fa74) line 542
PresShell::HandleEvent(PresShell * const 0x040f5674, nsIView * 0x04856ad0,
nsGUIEvent * 0x0012fb68, nsEventStatus * 0x0012fa74) line 2737 + 38 bytes
nsView::HandleEvent(nsView * const 0x04856ad0, nsGUIEvent * 0x0012fb68, unsigned
int 28, nsEventStatus * 0x0012fa74, int & 0) line 841
nsViewManager::DispatchEvent(nsViewManager * const 0x040f5e60, nsGUIEvent *
0x0012fb68, nsEventStatus * 0x0012fa74) line 1678
HandleEvent(nsGUIEvent * 0x0012fb68) line 69
nsWindow::DispatchEvent(nsWindow * const 0x040f5bb4, nsGUIEvent * 0x0012fb68,
nsEventStatus & nsEventStatus_eIgnore) line 421 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fb68) line 442
nsWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 3333 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line
3551
nsWindow::ProcessMessage(unsigned int 512, unsigned int 1, long 8192439, long *
0x0012fdc8) line 2620 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x001b0ca6, unsigned int 512, unsigned int 1, long
8192439) line 608 + 27 bytes
USER32! 77e71820()
007d01b7()

Comment 53

[Alec Flett]

Par, please open a new bug, this is a totally different crash

Comment 54

[ppandit]

Using 1/28/00 (today's) M14 release build.

No longer see a crash. Having other problems - recepients and scrollbar not 
visible when I do a Reply All.

I will M13 next.

Comment 55

[ppandit]

Looks okay on 1/25/00 M13 release build. 

Since the M14 problems look different and do not cause a crash, I think this bug  
has been fixed and am verifying it.

Par

Comment 56

[Alec Flett]

(yeah, this had nothing to do with appearance, just the crash)