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

VERIFIED FIXED in M13

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Neil Marshall, Assigned: harishd)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE], URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

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

Comment 2

18 years ago
Created attachment 3222 [details]
testcase, distilled from www.bluesnews.com

Updated

18 years ago
Whiteboard: [TESTCASE]

Comment 3

18 years ago
Thanks for the simplified test case.

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

Updated

18 years ago
Assignee: troy → vidur

Comment 4

18 years ago
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

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

Comment 6

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

Comment 7

18 years ago
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

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

Comment 9

18 years ago
*** Bug 22544 has been marked as a duplicate of this bug. ***
*** Bug 22560 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Assignee: vidur → harishd
Status: ASSIGNED → NEW

Comment 11

18 years ago
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.
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M14
*** Bug 23242 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
*** Bug 22169 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Target Milestone: M14 → M13

Comment 14

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

Comment 15

18 years ago
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...
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Comment 16

18 years ago
Ok, it's FIXED:)

Comment 17

18 years ago
Fixed in the Jan 20 th build.
Status: RESOLVED → VERIFIED

Comment 18

18 years ago
*** Bug 22991 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.