Closed
Bug 20799
Opened 25 years ago
Closed 25 years ago
bluesnews.com downloads the page, erases it, and then displays the banner ad full screen. Should be displayed on the page.
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
FIXED
M13
People
(Reporter: marshall, Assigned: harishd)
References
()
Details
(Whiteboard: [TESTCASE])
Attachments
(1 file)
1.21 KB,
text/html
|
Details |
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•25 years ago
|
||
sorry. Even holding onto the scrollbar doesn't work. It also does it on other pages on that site.
Comment 2•25 years ago
|
||
Updated•25 years ago
|
Whiteboard: [TESTCASE]
Thanks for the simplified test case. Dumping the content model shows only the image. Some how the P that contains "Headlines" has disappeared...
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•25 years ago
|
||
In an attempt to get my bug list in order again, marking all the bugs I have currently as ASSIGNED.
Comment 7•25 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 10•25 years ago
|
||
*** Bug 22560 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Assignee: vidur → harishd
Status: ASSIGNED → NEW
Comment 11•25 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.
Comment 12•25 years ago
|
||
*** Bug 23242 has been marked as a duplicate of this bug. ***
Comment 13•25 years ago
|
||
*** Bug 22169 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
This appears to be fixed with the Jan. 13 dated Linux snapshot.
Comment 15•25 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...
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 16•25 years ago
|
||
Ok, it's FIXED:)
Comment 18•25 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.
Description
•