20799 - bluesnews.com downloads the page, erases it, and then displays the banner ad full screen. Should be displayed on the page.

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Neil Marshall]

In the 1999120315 build of Mozilla, if you go to www.bluesnews.com it downloads
the page and when it comes to displaying the banner ads, it whipes the screen
clean and shows only the 2 banner ads.
I can stop this if, as its downloading, I grab onto the slider thing on the
scrollbar and keep the mouse held down until the page finishes loading.

Comment 1

[Neil Marshall]

sorry.  Even holding onto the scrollbar doesn't work.  It also does it on other
pages on that site.

Comment 2

[Mats Palmgren (inactive)]

Attachment: testcase, distilled from www.bluesnews.com

Comment 3

[troy]

Thanks for the simplified test case.

Dumping the content model shows only the image. Some how the P that contains
"Headlines" has disappeared...

Comment 4

[troy]

Vidur, I see "Headlines" appear briefly and then the frame construction code's
ContentRemoved() function is called. After I continue then it is no longer
displayed and no longer in  the content model.

Here's the stack trace:

nsCSSFrameConstructor::ContentRemoved(nsCSSFrameConstructor * const 0x018ab490,
nsIPresContext * 0x018f4f00, nsIContent * 0x00000000, nsIContent * 0x0193de8c,
int 0) line 6307
StyleSetImpl::ContentRemoved(StyleSetImpl * const 0x018ab3c0, nsIPresContext *
0x018f4f00, nsIContent * 0x00000000, nsIContent * 0x0193de8c, int 0) line 965
PresShell::ContentRemoved(PresShell * const 0x018ab558, nsIDocument *
0x01926b20, nsIContent * 0x00000000, nsIContent * 0x0193de8c, int 0) line 2139 +
50 bytes
nsDocument::ContentRemoved(nsDocument * const 0x01926b20, nsIContent *
0x00000000, nsIContent * 0x0193de8c, int 0) line 1607
nsHTMLDocument::ContentRemoved(nsHTMLDocument * const 0x01926b20, nsIContent *
0x00000000, nsIContent * 0x0193de8c, int 0) line 1094
nsDocument::Reset(nsIChannel * 0x018f4c90, nsILoadGroup * 0x00f7ecc8) line 794
nsHTMLDocument::Reset(nsIChannel * 0x018f4c90, nsILoadGroup * 0x00f7ecc8) line
311 + 16 bytes
nsHTMLDocument::OpenCommon(nsIURI * 0x0177cb28) line 1657 + 32 bytes
nsHTMLDocument::Open(nsHTMLDocument * const 0x01926c00, JSContext * 0x00f8c3d0,
long * 0x018b0c24, unsigned int 1) line 1736 + 18 bytes
nsHTMLDocument::ScriptWriteCommon(JSContext * 0x00f8c3d0, long * 0x018b0c24,
unsigned int 1, int 0) line 1814 + 40 bytes
nsHTMLDocument::Write(nsHTMLDocument * const 0x01926c00, JSContext * 0x00f8c3d0,
long * 0x018b0c24, unsigned int 1) line 1853
NSHTMLDocumentWrite(JSContext * 0x00f8c3d0, JSObject * 0x0183bc70, unsigned int
1, long * 0x018b0c24, long * 0x0012f348) line 1168 + 24 bytes
js_Invoke(JSContext * 0x00f8c3d0, unsigned int 1, unsigned int 0) line 665 + 26
bytes
js_Interpret(JSContext * 0x00f8c3d0, long * 0x0012fc20) line 2226 + 15 bytes
js_Execute(JSContext * 0x00f8c3d0, JSObject * 0x0183a2c8, JSScript * 0x01928790,
JSFunction * 0x00000000, JSStackFrame * 0x00000000, unsigned int 0, long *
0x0012fc20) line 838 + 13 bytes
JS_EvaluateUCScriptForPrincipals(JSContext * 0x00f8c3d0, JSObject * 0x0183a2c8,
JSPrincipals * 0x018f723c, const unsigned short * 0x018ec0e8, unsigned int 389,
const char * 0x018eaf30, unsigned int 0, long * 0x0012fc20) line 2705 + 27 bytes
nsJSContext::EvaluateString(nsJSContext * const 0x00f8c368, const nsString &
{...}, void * 0x0183a2c8, nsIPrincipal * 0x018f7238, const char * 0x018eaf30,
unsigned int 0, const char * 0x004c5454, nsString & {...}, int * 0x0012fc78)
line 284 + 53 bytes
HTMLContentSink::EvaluateScript(nsString & {...}, int 0, const char *
0x004c5454) line 3602
HTMLContentSink::OnUnicharStreamComplete(HTMLContentSink * const 0x0193dbf4,
nsIUnicharStreamLoader * 0x01922320, unsigned int 0, unsigned int 389, const
unsigned short * 0x01923a00) line 3623 + 27 bytes
nsUnicharStreamLoader::OnStopRequest(nsUnicharStreamLoader * const 0x01922324,
nsIChannel * 0x01921108, nsISupports * 0x00000000, unsigned int 0, const
unsigned short * 0x00000000) line 127 + 63 bytes
nsChannelListener::OnStopRequest(nsChannelListener * const 0x01922538,
nsIChannel * 0x01921108, nsISupports * 0x00000000, unsigned int 0, const
unsigned short * 0x00000000) line 1588
nsHTTPChannel::ResponseCompleted(nsIChannel * 0x01922990, unsigned int 0, const
unsigned short * 0x00000000) line 812 + 50 bytes
nsHTTPResponseListener::OnStopRequest(nsHTTPResponseListener * const 0x018e2238,
nsIChannel * 0x01922990, nsISupports * 0x01921108, unsigned int 0, const
unsigned short * 0x00000000) line 263
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x018f9808) line
279
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x018f9860) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x018f9860) line 522 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00b47a28) line 483 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000a015a, unsigned int 49425, unsigned int 0,
long 11827752) line 947 + 9 bytes
USER32! 77e135f8()
USER32! 77e13769()
USER32! 77e17b9a()
main(int 2, char * * 0x00a953b0) line 137 + 11 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e9bc52()

Comment 5

[vidur (gone)]

In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.

Comment 6

[troy]

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

Comment 7

[Mats Palmgren (inactive)]

The testcase looks something like this (schematically):
... content ...
<SCRIPT>
document.write('<SCRIPT>');
document.write('</SCRIPT>');  // 1)
</SCRIPT>

I think the problem is that the write() at 1) is closing
both open <SCRIPT> tags, so when the parser sees the last
</SCRIPT> it decides that everything up til now was really
a <SCRIPT> block and removes it (even though there's no
matching start tag).

Comment 8

[Mats Palmgren (inactive)]

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

Comment 9

[Mats Palmgren (inactive)]

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

Comment 10

[Mats Palmgren (inactive)]

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

Comment 11

[vidur (gone)]

The problem is that the document.written SCRIPT element with a SRC attribute is
correctly blocking the parser, but the blocked state isn't propagating up the
stack to the outer SCRIPT element. As a result, we continue parsing and complete
the document. The loaded script, when it completes, is treated like an
out-of-band document.write and the document is reopened. Passing along to
harishd per our conversation - the blocked state needs to be propagated up.

Comment 12

[Mats Palmgren (inactive)]

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

Comment 13

[vidur (gone)]

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

Comment 14

[briareos]

This appears to be fixed with the Jan. 13 dated Linux snapshot.

Comment 15

[briareos]

Actually, I spoke too soon. It worked once with the Jan. 13 snapshot, but
attempts to view the page again result in a new behaviour--the main page loads,
then reloads and displays a flat grey page. This is across browser restarts
(maybe a caching issue?). Hmm, I just destroyed ~/.mozilla and restarted, but
the page still gives me a grey screen...

Comment 16

[harishd]

Ok, it's FIXED:)

Comment 17

[Chris Petersen]

Fixed in the Jan 20 th build.

Comment 18

[vidur (gone)]

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