18312 - [BLOCK] HTML Reply/quoting of CNN Swedish page containing certain HTML elements leads to infinite loop

Status: VERIFIED WORKSFORME

(MailNews Core :: Composition, defect, P3)

Description

[Katsuhiko Momoi]

** Obseved with 11/8/99 Win32 build (19991108009) **

This bug sounds familiar but just in case there is no outstanding bug
describing this problem, I'll file it.

1. The above Smoketesy.zip file contains 5 msgs.
2. The 3rd msg from top is a JPN message body with an HTML attachment (Netscape
   Home Page which was sent by 4.6 using "Send Page" option).
3. Now display/select this msg on IMAP or POP server. (Note: Observe that
   it displays correctly in body and attachment if you had selected
   Browser's "View | Auto-Detect | Japanese" beforehand. The problem, however,
   occurs whether or not the attachment display is correct.)
4. Now engage Reply / w auto-quoting under HTML mail send option.
5. In the process of assembling this message, Mozilla crashes.

Comment 1

[Katsuhiko Momoi]

So far I tried the following Netscape Home Pages and
CJK pages cause this crash but Latin 1 page (French Home
Page) does not.

1. http://home.netscape.com/ja    (Japan)
2. http://home.netscape.com/zh/cn  (China)
3. http://home.netscape.com/zh.tw  (Taiwan)
4. http://home.netscape.com/fr  (French Home Page)

Comment 2

[Katsuhiko Momoi]

This is one of the basic functionality and so I'm designating it
[Dogfood].

Comment 3

[Katsuhiko Momoi]

Here's what I get on Talkback for one of my crashes:

Trigger Type:  Program Crash
Trigger Reason:  Access violation
Call Stack:    (Signature = 0x00000000 c64f5270) 0x00000000

nsHTMLDivElement::Release
[d:\builds\seamonkey\mozilla\layout\html\content\src\nsHTMLDivElement.cpp, line
110]
nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement
[d:\builds\seamonkey\mozilla\layout\html\content\src\nsGenericHTMLElement.cpp,
line 2401]
nsBodyInner::~nsBodyInner
[d:\builds\seamonkey\mozilla\layout\html\content\src\nsHTMLBodyElement.cpp,
line 146] nsHTMLBodyElement::`scalar deleting destructor'
nsHTMLTableColGroupElement::Release
[d:\builds\seamonkey\mozilla\layout\html\content\src\nsHTMLTableColGroupElement
.cpp, line 119]
nsGenericHTMLContainerElement::~nsGenericHTMLContainerElement
[d:\builds\seamonkey\mozilla\layout\html\content\src\nsGenericHTMLElement.cpp,
line 2401]
nsHTMLHtmlElement::`scalar deleting destructor'
nsHTMLDivElement::Release
[d:\builds\seamonkey\mozilla\layout\html\content\src\nsHTMLDivElement.cpp, line
110]
nsDocument::~nsDocument
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocument.cpp, line 633]
nsHTMLDocument::~nsHTMLDocument
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLDocument.cpp, line
264]
nsDocument::Release
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocument.cpp, line 757]
nsHTMLDocument::Release
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLDocument.cpp, line
300]
nsCOMPtr_base::~nsCOMPtr_base
[d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 45]
DocumentViewerImpl::~DocumentViewerImpl
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 287]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

See below for the full report:

http://cyclone/reports/incidenttemplate.CFM?reportID=1020&style=0&tc=2&cp=1&ck1
=SNub+trigger+event+time&cd1=1999%2F11%2F09&bbid=534149

Comment 4

[Katsuhiko Momoi]

The above crash report was generated when I took
the 3rd msg in the Smoketest file and engaged reply/w auto-quote
button on it under HTML mail send option.

Comment 5

[Jean-Francois Ducarroz]

I did the following test with a windows build from this morning (should be the
same than the official build of the day) on NT 4.0 sp5 english:

1) With 4.7, load http://home.netscape.com/ja
2) Send page

3) With 5.0, Get message,
4) Select the message sent from 4.7
5) >>>CRASH>>> in nsTableCellFrame* nsCellMap::GetCellInfoAt at line 515.

Reassign to rhp for investigation...

Comment 6

[Jean-Francois Ducarroz]

FYI: Today's build on Unix (at least) crash when displaying cnn.com in the browser at the same location I have
reported.

Comment 7

[rhp (gone)]

I haven't been able to get this to happen today with my build...win continue
the investigation.

- rhp

Comment 8

[rhp (gone)]

I will update my tree and retest, but I really don't think this is a quoting
problem. The stack trace is crashing in Layout in table code. Is everyone still
seeing this crash?

- rhp

Comment 9

[Katsuhiko Momoi]

I'm still seeing it on the 2nd Win 32 build of the day. (Build: 1999110911)

Comment 10

[ji]

I'm seeing this on today's linux 1999110911 build too.

Comment 11

[leger]

Putting on PDT+ radar.

Comment 12

[rhp (gone)]

Ok, I know what this specific bug is...its our old friend the META tag with a
charset specified. Basically, quoting HTML with this line will cause that
document reload and cause us to crash. I can prevent the data we generate from
having META tags (I've done that already) but there is no way to prevent
attachments from doing this.

Akkana: Is there a bug on this already...if so, its a dup, if not, then this is
a new one for Ender.

The stack trace looks like this:

nsDocLoaderImpl::GetContentViewerContainer(nsDocLoaderImpl * const 0x016dfa90,
unsigned int 1242164, nsIContentViewerContainer * * 0x0012e670) line 658 + 5
bytes
nsObserverBase::NotifyWebShell(nsObserverBase * const 0x016d8108, unsigned int
1242164, const char * 0x03c38f00, nsCharsetSource kCharsetFromMetaTag, const
char * 0x03c38e90) line 54 + 20 bytes
nsMetaCharsetObserver::Notify(nsMetaCharsetObserver * const 0x016d8100,
unsigned int 1242164, unsigned int 5, const unsigned short * * 0x0012ed34,
const unsigned short * * 0x0012edfc) line 287 + 36 bytes
nsMetaCharsetObserver::Notify(nsMetaCharsetObserver * const 0x016d8100,
unsigned int 1242164, const unsigned short * 0x0012ecb4, unsigned int 5, const
unsigned short * * 0x0012ed34, const unsigned short * * 0x0012edfc) line 166
nsObserverNotifier::operator()(void * 0x016d8100) line 321 + 47 bytes
nsDeque::FirstThat(nsDequeFunctor & {...}) line 348 + 14 bytes
CObserverService::Notify(nsHTMLTag eHTMLTag_meta, nsIParserNode & {...},
unsigned int 1242164, const char * 0x02194094, nsIParser * 0x03c17b60) line 938
CNavDTD::WillHandleStartTag(CToken * 0x02298630, nsHTMLTag eHTMLTag_meta,
nsCParserNode & {...}) line 1065 + 35 bytes
CNavDTD::HandleStartToken(CToken * 0x02298630) line 1258 + 20 bytes
CNavDTD::HandleToken(CNavDTD * const 0x03c26ba0, CToken * 0x02298630, nsIParser
* 0x03c17b60) line 732 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x03c26ba0, nsIParser * 0x03c17b60,
nsITokenizer * 0x03c34d40, nsITokenObserver * 0x00000000, nsIContentSink *
0x03c218f0) line 529 + 20 bytes
nsParser::BuildModel() line 1030 + 34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 956 + 11 bytes
nsParser::Parse(const nsString & {""}, void * 0x0012f434, const nsString &
{"text/html"}, int 0, int 1, eParseMode eParseMode_autodetect) line 837 + 15
bytes
nsParser::ParseFragment(const nsString & {"<!doctype html public "-//w3c//dtd
html 4.0 transitional//en">
<html>
&nbsp;
<br><A HREF="http://people.netscape.com/momoi/"}, void * 0x00000000,
nsITagStack & {...}, unsigned int 0, const nsString & {"text/html"}, eParseMode
eParseMode_autodetect) line 926 + 41 bytes
nsRange::CreateContextualFragment(nsRange * const 0x03c17884, const nsString &
{"<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br><A HREF="http://people.netscape.com/momoi/"}, nsIDOMDocumentFragment * *
0x0012f7f4) line 1845 + 52 bytes
nsHTMLEditor::InsertHTML(nsHTMLEditor * const 0x035fc5a4, const nsString &
{"<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br><A HREF="http://people.netscape.com/momoi/"}) line 1358 + 63 bytes
nsHTMLEditor::InsertAsCitedQuotation(nsHTMLEditor * const 0x035fc5a8, const
nsString & {"<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br><A HREF="http://people.netscape.com/momoi/"}, const nsString & {""}) line
3653 + 20 bytes
nsHTMLEditorLog::InsertAsCitedQuotation(nsHTMLEditorLog * const 0x035fc5a8,
const nsString & {"<!doctype html public "-//w3c//dtd html 4.0
transitional//en">
<html>
&nbsp;
<br><A HREF="http://people.netscape.com/momoi/"}, const nsString & {""}) line
457 + 17 bytes
nsHTMLEditor::InsertAsQuotation(nsHTMLEditor * const 0x035fc5a8, const nsString
& {"<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br><A HREF="http://people.netscape.com/momoi/"}) line 3575 + 23 bytes
nsHTMLEditorLog::InsertAsQuotation(nsHTMLEditorLog * const 0x035fc5a8, const
nsString & {"<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br><A HREF="http://people.netscape.com/momoi/"}) line 421 + 13 bytes
nsEditorShell::InsertAsQuotation(nsEditorShell * const 0x03c26f30, const
unsigned short * 0x036d2d80) line 2135 + 42 bytes
nsMsgCompose::ConvertAndLoadComposeWindow(nsIEditorShell * 0x03c26f30, nsString
{"<br><br>Katsuhiko Momoi wrote:<br><html>"}, nsString {"<!doctype html public
"-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br><A HREF="http://people.netscape.com/momoi/"}, nsString ...) line 140
QuotingOutputStreamListener::OnStopRequest(QuotingOutputStreamListener * const
0x03c34bb0, nsIChannel * 0x03b14090, nsIChannel * 0x03b14090, unsigned int 0,
nsIChannel * 0x03b14090) line 970
nsStreamConverter::OnStopRequest(nsStreamConverter * const 0x03b11d70,
nsIChannel * 0x03b10264, nsISupports * 0x03be46f0, unsigned int 0, const
unsigned short * 0x00000000) line 730
nsMsgProtocol::OnStopRequest(nsMsgProtocol * const 0x03b10260, nsIChannel *
0x03b22a50, nsISupports * 0x03be46f0, unsigned int 0, const unsigned short *
0x00000000) line 199 + 74 bytes
nsMailboxProtocol::OnStopRequest(nsMailboxProtocol * const 0x03b10260,
nsIChannel * 0x03b22a50, nsISupports * 0x03be46f0, unsigned int 0, const
unsigned short * 0x00000000) line 177
nsFileChannel::OnStopRequest(nsFileChannel * const 0x03b22a54, nsIChannel *
0x03b248b0, nsISupports * 0x03be46f0, unsigned int 0, const unsigned short *
0x00000000) line 427 + 45 bytes
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x03b2c850) line
326
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03b29e70) line 173 + 12 bytes
PL_HandleEvent(PLEvent * 0x03b29e70) line 537 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01082c20) line 498 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00870b12, unsigned int 49389, unsigned int 0,
long 17312800) line 972 + 9 bytes
USER32! 77e71268()
01082c20()

Comment 13

[Akkana Peck]

Adding Rick and Vidur to cc list, since this is happening when ParseFragment is
called on a fragment which contains a meta charset tag, which incorrectly
triggers a reload.

Perhaps the parser should ignore meta charset tags when parsing fragments -- or
will that cause problems for people who want to be able to paste html with a
different charset than the one currently in the document?

Comment 14

[rhp (gone)]

Akkana: who do you think this should be assigned to...its a PDT+ bug and the
fix lives in layout.

- rhp

Comment 15

[Akkana Peck]

I really don't know -- I've sent mail to Rick, Vidur and Ftang asking them to
take a look at the bug and venture an opinion.

Comment 16

[rhp (gone)]

Hi Rick,
Since we have a plan for this bug, I figured I would update it and pass it over
to you. Then, when you are done, you can pass it to Akkana for her API updates
and finally back to me for the insert call changes.

After you fix the crash, we should probably take it off of the PDT radar.

Thanks for the help!

- rhp

Here is the plan of attack:


Here's the problem as far as I can tell:

Rich wants to insert an HTML fragment into an existing document for the purpose
of block quoting. The fragment he's inserting contains
a <meta> tag with a charset specifier. (Note: The parsing engine has observers
for tags, and the i18n library ties into this notification
system for the purpose of charset detection). When ParseFragment() is called,
the <meta> tag is observed by the i18n library, which
detects the charset specifier. As a result, the i18n library tells the parser
to stop loading the document, and then it tells the webshell to
reload the document using a different charset.
Since this was a fragment and not a document, we get a crash, though I didn't
check into why we are crashing exactly.

The solution: First, we'll disable <meta> observation on HTML fragments.
Second, we need to extend the ParseFragment() api to
include a charset specifier. Anyone who wants to call this method will need to
determine the charset of the fragment in advance. Frank
Tang has a few i18n library calls to do this: nsIPlatformCharset() and
nsICharsetDetector().

I'll be out the rest of this week, but I'll add a quick hack tonight to disable
notification when ParseFragment() is called. When I return, I'll
extend the API to require a charset specifier. Akkana will need to update her
calls to ParseFragment() to include a charset.

Comment 17

[bobj]

I don't know what an HTML fragment really is, but should it be including
<HEAD> info?  <META> tags are only legal in the HTML head and not in the body.

Comment 18

[leger]

We believe this is fixed. Should not crash anymore.  Please re-test.  Putting on
 PDT-.  Please remove this if crash still occurs.

Comment 19

[rickg]

This has been fixed for some time. BobJ: <META...> should only occur in the
head, but a tremendous amount of HTML on the web has them appearing virtually
anywhere in the document, and it's something we must support. I've broadened the
parseFragment() api, but not provided an implementation as of yet. Reassigning
back to rich.

Comment 20

[rhp (gone)]

Since the crashing nature of this has been fixed, I'm moving to M13 and I will
work on using the new API.

- rhp

Comment 21

[Katsuhiko Momoi]

** Checked with 12/6/99 Win32 build  **

The crash bug does occur if the auto-detction module for Japanese is turned. Without the auto-detection
module tunred off, the crash does not occur. The steps to reproduce this problem are as follows.

1. The above Smoketesy.zip file contains 5 msgs.
2. The 3rd msg from top is a JPN message body with an HTML attachment (Netscape
   Home Page which was sent by 4.6 using "Send Page" option).
3. On the Browser window, select "View | Auto-Detect | Japanese".
4. Now back to Mail, select the 3rd msg on IMAP or POP server.
   occurs whether or not the attachment display is correct.)
5. Now engage Reply / w auto-quoting under HTML mail send option.
6. In the process of assembling this message, Mozilla crashes.

Note: Turn off Japanese auto-detection by choosing "View | Auto-Detect | off". Then follow steps 4 and 5. The
         crash does not occur.

Comment 22

[Katsuhiko Momoi]

Apparently the reason that the crash does not occur when the auto-detection is turned off
is that quoting of Japanese attachment does not occur in that case -- this could be another bug.
Naoki was able to reproduce this problem with non-Japanese page and without
the auto-detect module turned on.

To reproduce with a Swedish page:

1. Using 4.x, send this page to yourself:

   http://cnn.passagen.se/ekonomi/article.jhtml?articleID=556254

2. receive it with Mozilla.
3. Don't have any auto-detect module turned. Then engage reply button.
4. This should lead to a crash.

Here's Naoki's Talkback incident report:

--------------------------------------------------

Trigger Type:  Program Crash

 Trigger Reason:  Access violation

 Call Stack:    (Signature = nsBlockFrame::DoRemoveFrame 0f2762ae)

      nsBlockFrame::DoRemoveFrame

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 4816]

      nsBlockFrame::DeleteChildsNextInFlow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 4833]

      nsBlockReflowContext::ReflowBlock

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 354]

      nsBlockFrame::ReflowBlockFrame

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3260]

      nsBlockFrame::ReflowLine

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2630]

      nsBlockFrame::ReflowDirtyLines

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2437]

      nsBlockFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1491]

      nsBlockReflowContext::ReflowBlock

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 260]

      nsBlockFrame::ReflowBlockFrame

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3260]

      nsBlockFrame::ReflowLine

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2630]

      nsBlockFrame::ReflowDirtyLines

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2437]

      nsBlockFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1491]

      nsAreaFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsAreaFrame.cpp, line 275]

      nsContainerFrame::ReflowChild

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 628]

      RootFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 334]

      nsContainerFrame::ReflowChild

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 628]

      nsScrollPortFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsScrollPortFrame.cpp, line 405]

      nsContainerFrame::ReflowChild

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 628]

      nsGfxScrollFrameInner::ReflowFrame

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1197]

      nsGfxScrollFrameInner::ReflowScrollArea

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1262]

      nsGfxScrollFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 469]

      nsContainerFrame::ReflowChild

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 628]

      ViewportFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 527]

      nsHTMLReflowCommand::Dispatch

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp, line 145]

      PresShell::ProcessReflowCommands

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1706]

      PresShell::ExitReflowLock

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 766]

      PresShell::ContentAppended

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2160]

      nsDocument::ContentAppended
                                                                                        [d:\builds\seamonkey\mozilla\layout\base\src\nsDocument.cpp,
line 1545]

      nsHTMLDocument::ContentAppended

[d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLDocument.cpp, line 1041]

      nsGenericHTMLContainerElement::AppendChildTo

[d:\builds\seamonkey\mozilla\layout\html\content\src\nsGenericHTMLElement.cpp, line 2963]

      nsGenericHTMLContainerElement::InsertBefore

[d:\builds\seamonkey\mozilla\layout\html\content\src\nsGenericHTMLElement.cpp, line 2618]

      nsHTMLTableElement::InsertBefore

[d:\builds\seamonkey\mozilla\layout\html\content\src\nsHTMLTableElement.cpp, line 120]

      InsertElementTxn::Do
                                                                                        [d:\builds\seamonkey\mozilla\editor\base\InsertElementTxn.cpp,
line 106]

      nsTransactionItem::Do

[d:\builds\seamonkey\mozilla\editor\txmgr\src\nsTransactionItem.cpp, line 108]

      nsTransactionManager::BeginTransaction

[d:\builds\seamonkey\mozilla\editor\txmgr\src\nsTransactionManager.cpp, line 1035]

      nsTransactionManager::Do

[d:\builds\seamonkey\mozilla\editor\txmgr\src\nsTransactionManager.cpp, line 124]

      nsEditor::Do
                                                                                        [d:\builds\seamonkey\mozilla\editor\base\nsEditor.cpp, line 393]

      nsEditor::InsertNode
                                                                                        [d:\builds\seamonkey\mozilla\editor\base\nsEditor.cpp, line 980]

      nsHTMLEditor::InsertHTML
                                                                                        [d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditor.cpp,
line 1438]

      nsHTMLEditor::InsertAsCitedQuotation
                                                                                        [d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditor.cpp,
line 3792]

      nsHTMLEditorLog::InsertAsCitedQuotation
                                                                                        [d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditorLog.cpp,
line 463]

      nsHTMLEditor::InsertAsQuotation
                                                                                        [d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditor.cpp,
line 3684]

      nsHTMLEditorLog::InsertAsQuotation
                                                                                        [d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditorLog.cpp,
line 423]

      nsEditorShell::InsertAsQuotation
                                                                                        [d:\builds\seamonkey\mozilla\editor\base\nsEditorShell.cpp, line
1975]

      nsMsgCompose::ConvertAndLoadComposeWindow

[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, line 246]

      QuotingOutputStreamListener::OnStopRequest

[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, line 1172]

      nsStreamConverter::OnStopRequest

[d:\builds\seamonkey\mozilla\mailnews\mime\src\nsStreamConverter.cpp, line 736]

      nsOnStopRequestEvent::HandleEvent

[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 279]

      nsStreamListenerEvent::HandlePLEvent

[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 94]

      PL_HandleEvent
                                                                                        [plevent.c, line 523]

      _md_EventReceiverProc
                                                                                        [plevent.c, line 951]

      USER32.dll + 0x1250 (0x77e71250)

--------------------------------------------------

Comment 23

[bobj]

Is this the same bug?
The Swedish page mentioned above (1) does not have any <META> tags, and
(2)it uses <LAYER> tags...

<LAYER> tags are not supported right now, but they shouldn't shouldn't
cause a crash (if that ***is*** the problem).

Comment 24

[nhottanscp]

Attachment: talkback report of netcenter/ja crasher

Comment 25

[ji]

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

Comment 26

[ji]

With linux 121411-M12 build, the crash still happens when replying in plain text
mode with charset auto detector turned on. When the charset auto detector is
turned off, the crash doesn't happen either in plain text or HTML mode.

Comment 27

[Katsuhiko Momoi]

On 12/14/99 Win32 M12 build (1999121408), I can also reproduce
this problem under plain text send option only  with the Auto-Detect
(Japanese) turned on. When it is off, the attachment does not
get quoted and so apparently avoids this crash.

Comment 28

[bobj]

Do you (ji and momoi) have stack traces for your crashes?  Or, are they the
same as the ones already in the bug report?

Is crashing on quote replies with Japanese auto-detect on, a dogfood problem?
Seems like this is the normal state for users reading/writing Japanese email.
This was demoted when we thought the crashing was fixed, if we need to
reconsider, please clear "[PDT-]" from the Whiteboard and explain why.

Also, I'm confused by the symptom and the analyis. Why would whether Japanese
auto-detect is on or off, affect the pasting of a fragment?  No matter what
was detected, aren't we always going to include a META tag in the pasted
fragment?

Comment 29

[Katsuhiko Momoi]

Here's the dump I got today with 12/14/99 Win32 build using the
steps I described above. Does not look the same as the one before.

-------------------------
Trigger Type:  Program Crash

 Trigger Reason:  Access violation

 Call Stack:    (Signature = nsDocLoaderImpl::GetContentViewerContainer
eec3f3d3)

   nsDocLoaderImpl::GetContentViewerContainer

[d:\builds\seamonkey\mozilla\webshell\src\nsDocLoader.cpp, line 810]

   nsObserverBase::NotifyWebShell

[d:\builds\seamonkey\mozilla\intl\chardet\src\nsObserverBase.cpp, line 60]

   nsMetaCharsetObserver::Notify

[d:\builds\seamonkey\mozilla\intl\chardet\src\nsMetaCharsetObserver.cpp, line
267]

   nsMetaCharsetObserver::Notify

[d:\builds\seamonkey\mozilla\intl\chardet\src\nsMetaCharsetObserver.cpp, line
145]

   nsObserverNotifier::operator()

[d:\builds\seamonkey\mozilla\htmlparser\src\nsDTDUtils.h, line 322]

   nsDeque::FirstThat

[d:\builds\seamonkey\mozilla\xpcom\ds\nsDeque.cpp, line 365]

   CObserverService::Notify

[d:\builds\seamonkey\mozilla\htmlparser\src\nsDTDUtils.cpp, line 928]

   CNavDTD::WillHandleStartTag

[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1101]

   CNavDTD::HandleStartToken

[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1286]

   CNavDTD::HandleToken

[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 764]

   CNavDTD::BuildModel

[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 528]

   nsParser::BuildModel

[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 1044]

   nsParser::ResumeParse

[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 968]

   nsParser::Parse

[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 845]

   ConvertBufToPlainText

[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompUtils.cpp, line 1952]

   QuotingOutputStreamListener::ConvertToPlainText

[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, line 1049]

   QuotingOutputStreamListener::OnStopRequest

[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCompose.cpp, line 1161]

   nsStreamConverter::OnStopRequest

[d:\builds\seamonkey\mozilla\mailnews\mime\src\nsStreamConverter.cpp, line 736]

   nsOnStopRequestEvent::HandleEvent

[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line
279]

   nsStreamListenerEvent::HandlePLEvent

[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line
94]

   PL_HandleEvent
                                                  [plevent.c, line 523]

   _md_EventReceiverProc
                                                  [plevent.c, line 951]

   USER32.dll + 0x1186 (0x77e41186)

----------------------------------------------

Comment 30

[Katsuhiko Momoi]

The crashes we are seeing recently may not be related to
the original bug I reported. If so, we probably should create
another bug for this latetr problem.

Comment 31

[bobj]

Create a new bug please.

Comment 32

[rhp (gone)]

Eventually, we will scan the data to insert for the charset and pass that in to
the insert call. No META tags.

- rhp

Comment 33

[Phil Peterson]

The crashing part of this bug seems like a beta stopper.

Comment 34

[Katsuhiko Momoi]

This bug got too cluttered with 3 different types of crash reports.
So, let me sort these out here as of 12/23/99 Win32 M13 build.

There are 3 types of crashes reported in this bug:

1. The original crash bug whose stack trace shows: nsHTMLDivElement::Release
   as the beginning line.
   This was obtained with HTML send option and no auto-detection modules ON.
   This crash no longer occurs with the above M13 build.

2. The 2nd type of crash was mentioned bv rhp. This involves:

   nsDocLoaderImpl::GetContentViewerContainer

   this still occurs when the 3rd Intl Smoketest msg is replied using
   Plain text option on with the Japanese auto-detection ON.
   This crash will not happen if HTML option used or if
   the auto-detection is OFF. The latter is because wuoting of
   the attachment does not occur under that condition.

   I and also ji recently reported this crash with M12 release build.

3. The 3rd type of crash was originally found by nhotta
   and was reported here by me. ducarroz's example
   also seems to be this one. This one involves:

   nsBlockFrame::DoRemoveFrame

   and ths still occurs with the above M13 build. I have a
   crash report today which looks exactly like the one
   mentioned in my comment on 12/6/99.

I don't think it wise to deal with all these bugs under one
umbrella given the differences in stack traces.

Since the original bug is gone now (type 1 above), I want to
suggest that we keep this bug for Type 2. I'll file a new bug
for Type 3.

Here's a fresh stack trace on this bug produced by attaching the CNN page
to mail and then reply/quoting with Mozilla, and here's how to reproduce
this crash:


1. Using 4.x, send this page to yourself:

   http://cnn.passagen.se/ekonomi/article.jhtml?articleID=556254

2. receive it with Mozilla.
3. Don't have any auto-detect module turned. Then engage reply button.
4. This should lead to a crash.

-----------------------------------------------------

Trigger Type:  Program Crash
Trigger Reason:  Access violation
Call Stack:    (Signature = nsBlockFrame::DoRemoveFrame b3e6130d)
nsBlockFrame::DoRemoveFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\ns  BlockFrame.cpp, line
4809]
nsBlockFrame::DeleteChildsNextInFlow
[d:\builds\seamonkey\mozilla\layout\html\ba  se\src\nsBlockFrame.cpp, line
4826]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\  src\nsBlockReflowContext.cpp,
line 354]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src  \nsBlockFrame.cpp, line
3251]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlo  ckFrame.cpp, line
2621]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\sr  c\nsBlockFrame.cpp, line
2428]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFr  ame.cpp, line
1492]
nsBlockReflowContext::ReflowBlock
[d:\builds\seamonkey\mozilla\layout\html\base\  src\nsBlockReflowContext.cpp,
line 260]
nsBlockFrame::ReflowBlockFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src  \nsBlockFrame.cpp, line
3251]
nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlo  ckFrame.cpp, line
2621]
nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src  \nsBlockFrame.cpp, line
2428]
nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFr  ame.cpp, line
1492]
nsAreaFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsAreaFram  e.cpp, line 275]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\  nsContainerFrame.cpp, line
644]
RootFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.  cpp, line 334]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src  \nsContainerFrame.cpp, line
644]
nsScrollPortFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsSc  rollPortFrame.cpp, line
405]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\  nsContainerFrame.cpp, line
644]
nsGfxScrollFrameInner::ReflowFrame
[d:\builds\seamonkey\mozilla\layout\html\bas  e\src\nsGfxScrollFrame.cpp, line
1254]
nsGfxScrollFrameInner::ReflowScrollArea
[d:\builds\seamonkey\mozilla\layout\htm  l\base\src\nsGfxScrollFrame.cpp, line
1319]
nsGfxScrollFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfx  ScrollFrame.cpp, line
521]
nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\  nsContainerFrame.cpp, line
644]
ViewportFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewpo  rtFrame.cpp, line
527]
nsHTMLReflowCommand::Dispatch
[d:\builds\seamonkey\mozilla\layout\html\base\src\  nsHTMLReflowCommand.cpp,
line 145]
PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\  src\nsPresShell.cpp, line 1842]
PresShell::ExitReflowLock
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsP  resShell.cpp, line 825]
PresShell::ContentAppended
[d:\builds\seamonkey\mozilla\layout\html\base\src\ns  PresShell.cpp, line 2296]
nsDocument::ContentAppended
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocu  ment.cpp, line 1545]
nsHTMLDocument::ContentAppended
[d:\builds\seamonkey\mozilla\layout\html\documen  t\src\nsHTMLDocument.cpp,
line 1110]
nsGenericContainerElement::AppendChildTo
[d:\builds\seamonkey\mozilla\layout\b  ase\src\nsGenericElement.cpp, line 2146]
nsGenericHTMLContainerElement::InsertBefore
[d:\builds\seamonkey\mozilla\layout\
html\content\src\nsGenericHTMLElement.cpp, line 2618]
nsHTMLTableCellElement::InsertBefore
[d:\builds\seamonkey\mozilla\layout\html\c
ontent\src\nsHTMLTableCellElement.cpp]
InsertElementTxn::Do
[d:\builds\seamonkey\mozilla\editor\base\InsertElementTxn.c  pp, line 106]
nsTransactionItem::Do
[d:\builds\seamonkey\mozilla\editor\txmgr\src\nsTransactio  nItem.cpp, line
108]
nsTransactionManager::BeginTransaction
[d:\builds\seamonkey\mozilla\editor\txm  gr\src\nsTransactionManager.cpp, line
1035]
nsTransactionManager::Do
[d:\builds\seamonkey\mozilla\editor\txmgr\src\nsTransa  ctionManager.cpp, line
124]
nsEditor::Do [d:\builds\seamonkey\mozilla\editor\base\nsEditor.cpp, line 395]
  nsEditor::InsertNode  [d:\builds\seamonkey\mozilla\editor\base\nsEditor.cpp,
l  ine 993]
nsHTMLEditor::InsertHTML
[d:\builds\seamonkey\mozilla\editor\base\nsHTMLEditor.c  pp, line 1493]
nsHTMLEditor::InsertAsCitedQuotation
[d:\builds\seamonkey\mozilla\editor\base\ns  HTMLEditor.cpp, line 3864]
nsHTMLEditorLog::InsertAsCitedQuotation
[d:\builds\seamonkey\mozilla\editor\base  \nsHTMLEditorLog.cpp, line 463]
nsHTMLEditor::InsertAsQuotation
[d:\builds\seamonkey\mozilla\editor\base\nsHTML  Editor.cpp, line 3755]
nsHTMLEditorLog::InsertAsQuotation
[d:\builds\seamonkey\mozilla\editor\base\nsH  TMLEditorLog.cpp, line 423]
nsEditorShell::InsertAsQuotation
[d:\builds\seamonkey\mozilla\editor\base\nsEdi  torShell.cpp, line 2002]
nsMsgCompose::ConvertAndLoadComposeWindow
[d:\builds\seamonkey\mozilla\mailnews\  compose\src\nsMsgCompose.cpp, line 246]
QuotingOutputStreamListener::OnStopRequest
[d:\builds\seamonkey\mozilla\mailnews  \compose\src\nsMsgCompose.cpp, line
1172]
nsStreamConverter::OnStopRequest
[d:\builds\seamonkey\mozilla\mailnews\mime\src\  nsStreamConverter.cpp, line
744]
nsOnStopRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src  \nsAsyncStreamListener.cpp, line
279]
nsStreamListenerEvent::HandlePLEvent
[d:\builds\seamonkey\mozilla\netwerk\base\  src\nsAsyncStreamListener.cpp, line
94]
PL_HandleEvent [plevent.c, line 523]
_md_EventReceiverProc [plevent.c, line 951]
USER32.dll + 0x1186 (0x77e41186)
-----------------------------------------------------

Comment 35

[Katsuhiko Momoi]

I'm sorry, what I mean to say above is that we keep this bug
for Type 3 crash - CNN Swedish page bug, and file a new
one for Type 2 as analyzed by Rich. I'll do the latter now.

Comment 36

[Katsuhiko Momoi]

The reason I'm suggesting to keep this bug for type 3 crash is
that both type 3 and the original crash bug seem to have something
to do with parsing HTML elements. This is thus not rhp's bug any more.

The original bug seems to have been fixed. See for example
 -- [e-mail]  1999-12-05 17:25 -- comment.

But a simialr bug crashing bugs still exists as caused by
replying to a msg which contains CNN Swedish page as an
attachment as described in -- [e-mail]  1999-12-25 02:22 --
along with the crash report. (See the updated URL above also.)

I therefore corrected the summary line and now send it to
rickg.

The Type 2 bug under the Plain Text mail send option and reply/quoting
an atatched document which contains an meta charset tag was filed
as Bug 22655 and assigned to rhp.

As this is a crasher, this should be marked [Beta stopper].

Comment 37

[Jim Roskind]

I'll render a preliminary PDT- for the team. This does not appear to be a
pervasive problem that precludes use be dedicated dogfood eaters.  If I'm
underastimating the impact, please delete the PDT annotation, and add a comment
to explain the broader impact.
Thanks,
Jim

Comment 38

[rickg]

Troy -- is the block frame crash below something you can address?  Thanks.

Comment 39

[troy]

Block/inline bug

Comment 40

[buster]

any chance of getting a simpler test case, especially one that doesn't involve
mail?  I've had trouble getting into mail the past few days.  Today, I can't log
on.  No matter what I try, it tells me my password is invalid.

Comment 41

[buster]

assigning to myself

Comment 42

[buster]

I don't see this crash today (winNT, debug build, source pulled 1/12/00pm).  Can
you verify that it still crashes?

What I see is the page loads into the reply compose window, but it continually
reloads because of the ad banner.  That's a URL loader bug for travis or mscott,
probably.

Comment 43

[Katsuhiko Momoi]

I don't see a crash with 1/11/00 Win32 build, either.
(We haven't had a good mail build since that time to
display and let alone reply to a msg.)

The infinite loop is there, however.

Ehat would be the best thing to do here? Keep it open
and monitor it while working on the loop problem?

Comment 44

[buster]

The crash is gone, replaced by an infinite loop that seems to be triggered by
the ad banner.  Reassigning to mscott, maybe a URL loading problem?  cc'ing
travis and rpotts.

Comment 45

[Scott MacGregor]

wow, this is a long bug report...Kat, can you summarize for me what is still
causing a problem? (i.e. what I need to do to see it) Thanks!

Comment 46

[Scott MacGregor]

I'll take a look at this in M14....

Comment 47

[Scott MacGregor]

When I do send page from 4.5 then turn around and get the message in 5.0 and
then reply to it, the quoting in 5.0 only shows the url, it doesn't try to
layout the page in the reply window. So I don't see an infinite loading loop
here. I wonder what I'm doing wrong.

Comment 48

[Katsuhiko Momoi]

I don't we'll be able to see what the current status of this bug is until Bug 23931
is fixed. That bug makes it impossible to quote HTML attachment material at present.
The dependency is now marked.

Comment 49

[leger]

Putting dogfood in the keyword field.

Comment 50

[Scott MacGregor]

Moving my remaining M14 bugs to M15 which is the next targeted milestone.

Comment 51

[lchiang]

bulk move to M16. Not an M15 stopper.  If you disagree, pls comment in bug and 
cc: [e-mail]

Comment 52

[selmer (gone)]

Is this still dogfood??

Comment 53

[Katsuhiko Momoi]

** Checked with 5/20/2000 Win32 build **

The crash was real problem for M15/Beta1/NS PR1 builds.
With todya's build above, I ran through all the cases I have
which induced this crash (type 3 above) and none is causing
the crash described in this report any more. 

I'm happy to say that this is now "Worksforme".

Comment 54

[Katsuhiko Momoi]

Verified as Worksforme with the above Win32 build.

Comment 55

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/9b70635da016
[fenix] For https://github.com/mozilla-mobile/fenix/issues/18312: Do not update secure flag on pausing logins fragments.