144709 - Deleting html attachment while replying to email crash mozilla

Status: VERIFIED DUPLICATE of bug 141054

(MailNews Core :: Attachments, defect)

Description

[Esben Mose Hansen]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
BuildID:    20020510009 (mozilla 1.0 rc2)

Selecting and deleting an html attachment while replying to a email message
(which obviously would contain one such) crashes mozilla. This happens in both
rc1 and rc2, but not in mozilla 0.98. My CVS build does not appear to be up to
the task of displaying the message at all, so I don't know if this is a branch
or trunk thing. Or, and the problem happens for both POP and IMAP, if that's
relevant at all. I'll attach a email message in .eml in a moment.

Reproducible: Always
Steps to Reproduce:
1.Compose an email message an attach a html file. 
2.Send the email to yourself :)
3.Press get messages and reply to the message just send
4.While composing, select the entire html part (below the divider.. I suppose
you have to have "display attachment inline for this to work)
5.Press delete.

Actual Results:  Browser crashed.

Expected Results:  Delete the attachment.

Here's two talkback IDs.

TB6299716 + TB6299696

I'll try with the classic theme in a moment. Forgot about it :)

Comment 1

[Esben Mose Hansen]

Attachment: A message that crashes instructions are followed

This is an email that demostrates the bug. But really, it's easier to create
your own :O)

Comment 2

[Esben Mose Hansen]

Just tried in the classic theme. Some results.

Comment 3

[Cameron Kellough]

Here is the first few lines of a linux stack dump from a debug build
that I did on April 8 after downloading the source.  The stack dump
is from GDB right after it caught the segfault.

#0  0x41e87559 in nsStyleBorder::GetBorderStyle (this=0x0, aSide=0 '\000')
    at ../../../../../../dist/include/content/nsStyleStruct.h:386
#1  0x41dead44 in nsStyleBorder::IsBorderSideVisible (this=0x0, aSide=0 '\000')
    at nsStyleStruct.cpp:494
#2  0x41c5f6f3 in nsInlineFrame::IsEmpty (this=0x9140f2c, aIsQuirkMode=1, 
    aIsPre=0, aResult=0xbfffbdd4) at nsInlineFrame.cpp:178
#3  0x41c62ad6 in nsLineBox::IsEmpty (this=0x916f354, aIsQuirkMode=1, 
    aParentIsPre=0, aResult=0xbfffbdd4) at nsLineBox.cpp:294
#4  0x41c263c7 in nsBlockReflowState::ReconstructMarginAbove (this=0xbfffc158, 
    aLine={mCurrent = 0x916f354, mListLink = 0x912e14c})
    at nsBlockReflowState.cpp:493
#5  0x41c1a127 in nsBlockFrame::ReflowDirtyLines (this=0x912e110, 
    aState=@0xbfffc158) at nsBlockFrame.cpp:2307
#6  0x41c16f37 in nsBlockFrame::Reflow (this=0x912e110, 
    aPresContext=0x8f2fc68, aMetrics=@0xbfffc79c, aReflowState=@0xbfffc4f4, 
    aStatus=@0xbfffc674) at nsBlockFrame.cpp:844
#7  0x41c24eb8 in nsBlockReflowContext::DoReflowBlock (this=0xbfffc754, 
    aReflowState=@0xbfffc4f4, aReason=eReflowReason_Dirty, aFrame=0x912e110, 
    aSpace=@0xbfffc680, aApplyTopMargin=1, aPrevBottomMargin=@0xbfffcc98, 
    aIsAdjacentWithTop=0, aComputedOffsets=@0xbfffc690, 
    aFrameReflowStatus=@0xbfffc674) at nsBlockReflowContext.cpp:580
#8  0x41c248b1 in nsBlockReflowContext::ReflowBlock (this=0xbfffc754, 
    aFrame=0x912e110, aSpace=@0xbfffc680, aApplyTopMargin=1, 
    aPrevBottomMargin=@0xbfffcc98, aIsAdjacentWithTop=0, 

Comment 4

[Antonio.Xu]

who can reproduce this bug on solaris or win2000 using RC2,i can not reproduce 
this bug on solaris or win2000.

Comment 5

[Cameron Kellough]

On Linux Build 2002052309, I can no longer reproduce this bug.

Comment 6

[Henry Jia]

This bug doesn't exist now. I tested on win2k, linux and solaris with RC3.
Change the status to WFM.

Comment 7

[Esben Mose Hansen]

Just for information, RC3 still crashes, both linux and windowns (me)
I'll check again when 1.0 comes out, and reopen it if the bug is still there.

Comment 8

[Henry Jia]

I can reproduce with trunk and RC3. Reopen this bug.

Comment 9

[Henry Jia]

Attachment: patch for trunk

Patch for trunk. Do some checks of pointer before using it.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This seems like a duplicate of bug 141054.  We shouldn't need to null-check
these things (and I'm surprised we're checking rv on the ones in
nsBlockFrame.cpp, since it's meaningless).

Comment 11

[Henry Jia]

Comment on attachment 87183 [details] [diff] [review]
patch for trunk

dup of bug 141054 which has a perfect solution than this patch.
Also tested with the test case, attachment #83694 [details].

Comment 12

[Henry Jia]

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

Comment 13

[Trix Supremo]

verifying dupe