10202 - {sink} content before STYLE element in BODY displayed twice

Status: VERIFIED DUPLICATE of bug 17932

(Core :: Layout, defect, P3)

Description

[bouchard]

This is a customizable display of news headlines, etc.  When the page was first
displayed in the default mode, it displayed properly.  After I signed in the
first time and all subsequent displays, the heading of the page is displayed
improperly, exhibiting two problems.  To wit: 1) Some of the icons / links are
displayed at the wrong location in the first heading; and, 2) The heading is
displayed twice.  The second heading seems to be displayed properly.

I looked at the HTML for the page and found only one section dealing with the
heading... implemented with /TABLE.  I haven't tried narrowing it down to a
particular HTML code segment.  Sorry.

Comment 1

[Daniel Bratell]

Is this the same as bug 5847? Please check and mark it a duplicate if it is.

Comment 2

[lkimmeringer]

Attachment: Effect occures with STYLE-tags

Comment 3

[lkimmeringer]

In default.html of start.mindspring.com there is a style-tag
after the "heading". This leads to a second heading.

(BuildId: 1999071416)

Comment 4

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

It's not clear if this is parser or layout - it doesn't look like tables
though.  Since "Dump Content" looks OK (as opposed to "Dump Frames") except for
high refcounts, I'm sending it to Layout...

The problem is that STYLE elements in the BODY cause content (not all,
sometimes) before the style element to be duplicated.

Comment 5

[troy]

Peter, sounds like a DUP of one of the problems you're working in

Comment 6

[Peter Linss]

Moving all content sink issues to M14.

Comment 7

[Peter Linss]

Make that M14.

Comment 8

[Peter Linss]

Thanks for taking this Vidur. Many of these are likely dups. I haven't marked
them as such to make sure I had the testcases handy...

Comment 9

[vidur (gone)]

We now hit an assertion in the HTML content sink (stack below) as a result of an
unexpected series of calls from the parser. We get a BeginContext() call,
presumably to deal with invalid content in a table. This is followed by a call
to CloseContainer() - there is no preceding call to OpenContainer() within the
same context. In this case, the CloseContainer() is for a CENTER tag. As a
result, we pop the top container in the context off the stack and hit an
assertion when we try to flush the remaining text.

nsDebug::Assertion(const char * 0x0186d774, const char * 0x0186d764, const char
* 0x0186d720, int 1777) line 280 + 13 bytes
SinkContext::FlushText(int * 0x00000000, int 1) line 1777 + 38 bytes
SinkContext::FlushTextAndRelease(int * 0x00000000) line 312
HTMLContentSink::EndContext(HTMLContentSink * const 0x02681e10, int 2) line 2113
CNavDTD::HandleSavedTokensAbove(nsHTMLTag eHTMLTag_table) line 1577
CNavDTD::HandleEndToken(CToken * 0x01c231d0) line 1485 + 18 bytes
CNavDTD::HandleToken(CNavDTD * const 0x0264c260, CToken * 0x01c231d0, nsIParser
* 0x0270f180) line 656 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x0264c260, nsIParser * 0x0270f180,
nsITokenizer * 0x0264c450, nsITokenObserver * 0x00000000, nsIContentSink *
0x02681e10) line 458 + 20 bytes
nsParser::BuildModel() line 1038 + 34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 949 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x0270f184, nsIChannel * 0x0270eef0,
nsISupports * 0x00000000, nsIInputStream * 0x0270b048, unsigned int 0, unsigned
int 3826) line 1376 + 19 bytes
nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x02659b30,
nsIChannel * 0x0270eef0, nsISupports * 0x00000000, nsIInputStream * 0x0270b048,
unsigned int 0, unsigned int 3826) line 1200 + 32 bytes
nsChannelListener::OnDataAvailable(nsChannelListener * const 0x0267a300,
nsIChannel * 0x0270eef0, nsISupports * 0x00000000, nsIInputStream * 0x0270b048,
unsigned int 0, unsigned int 3826) line 1386
nsChannelListener::OnDataAvailable(nsChannelListener * const 0x0270d040,
nsIChannel * 0x0270eef0, nsISupports * 0x00000000, nsIInputStream * 0x0270b048,
unsigned int 0, unsigned int 3826) line 1386
nsHTTPResponseListener::OnDataAvailable(nsHTTPResponseListener * const
0x0270d080, nsIChannel * 0x0270e920, nsISupports * 0x0270eef0, nsIInputStream *
0x0270b048, unsigned int 0, unsigned int 3826) line 171 + 47 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x02708ef0)
line 413
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0270ce10) line 169 + 12 bytes
PL_HandleEvent(PLEvent * 0x0270ce10) line 533 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c5ef90) line 494 + 9 bytes

Reassigning to Harish to fix the erroneous parser calls.

Comment 10

[harishd]

Reduced case:

<center>
<table>
  <tr><td>foo</td></tr>
hello
</center>
</table>

Comment 11

[vidur (gone)]

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

Comment 12

[harishd]

Fixed the problem on the parser end.

vidur, it's all yours.

Comment 13

[vidur (gone)]

The last remaining part of this fix is removing the assert, which Rick is going
to do for bug 17932.

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

Comment 14

[Chris Petersen]

Agreed. Marking as verified dup of 17932.