Closed
Bug 84648
Opened 23 years ago
Closed 23 years ago
JavaScript banner code forces banner to be the only thing displayed
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: hansmann.d, Assigned: jst)
References
()
Details
(Whiteboard: [pdt+][nsBranch+][FIXED AND VERIFIED ON THE TRUNK])
Attachments
(1 file)
4.40 KB,
patch
|
Details | Diff | Splinter Review |
the first page of www.hpvk.net loads, but if a link is activated, the next page isn't shown, instead the banner is displayed (but "view source" shows thw whole document). the banner is included by a javascript in the body. the problem does not occur in NN6 but in mozilla 0.9 or higher. including the script in a simpler page works... netscape 4.x, ie5 and konqueror 2.1 render the page correctly.
Comment 1•23 years ago
|
||
This is the problem: document.write('<LINK rel="stylesheet" type="text/css" href="/views/nn4.css">'); commenting out this line makes the page appear correctly. Peterv, a dup of one of your bugs? Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Comment 2•23 years ago
|
||
This looks more like a redirect problem to me. If you go to the URL mentioned (http://www.hpvk.net/), you'll eventually end up with just the banner displayed. But if you go directly to the page that http://www.hpvk.net/ redirects you to, namely http://www.hpvk.net:9001/views/Main.po, the page is displayed correctly.
Assignee | ||
Comment 4•23 years ago
|
||
Ok, so here's the problem: We start loading the page, we see a <link> tag that causes an external stylesheet to be loaded so we block the parser. So far so good. Then, once the stykesheet is loaded it calls ResumeParse() in the parser which continues the parsing and sees the inline script that does a document.write() that writes out a <link> tag that again causes the parser to be blocked while the stylesheet is being loaded. At this point, the stack looks something like this: 1: HTMLContentSink::::ProcessLINKTag(), this returns NS_ERROR_HTMLPARSER_BLOCK ... 2: nsParser::BuildModel() 3: nsParser::ResumeParse()4: nsParser::Parse(string) 5: document.write() ... 6: nsParser::BuildModel() 7: nsParser::ResumeParse() 8: stylesheet done loading notification Now, the top most nsParser::ResumeParse() (i.e. stack frame 3 above) will catch the NS_ERROR_HTMLPARSER_BLOCK code and block the parser and return, we'll continue to roll back and we get back into the bottom most nsParser::BuildModel(), and since this doesn't see the NS_ERROR_HTMLPARSER_BLOCK return value that was caught earlier it doesn't realize that the parser is blocked so it just continues building it's model from the tokens it already has, and one of those tokens is the token (or tokens) for a script tag that referes to an external script file so we end up blocking the already blocked parser, oops! So here's the obvious problem, now we have two asynch loads going on at the same time, and whichever one that's done loading first will unblock the parser even if there's still another load going on that blocked the parser. This is a problem in the parser, reassigning to Harish, and nominating for mozilla0.9.3, and nsBranch.
Keywords: mozilla0.9.3,
nsBranch
Assignee | ||
Comment 5•23 years ago
|
||
Assignee | ||
Comment 6•23 years ago
|
||
Oops, forgot to reassign to harishd, but we have a fix already so I won't reassign it now, but I need the fix reviewed. Harish, r=?
Assignee | ||
Updated•23 years ago
|
Target Milestone: --- → mozilla0.9.3
Assignee | ||
Updated•23 years ago
|
Whiteboard: [HAVE FIX]
r=harishd. However, the parser/dtd could be taught to not rely completely on return values. Currently, it looks like, the parser/dtd need to be informed about the block state more than once but instead we should make the parser/dtd to respond more intelligently to Block() and Unblock() calls.
Assignee | ||
Updated•23 years ago
|
Whiteboard: [HAVE FIX] → [FIX ON THE TRUNK]
nsBranch ok, but please remember not to reintroduced the initial regression caused on the trunk... (says vidur).
The above URL and the links in it load fine. Verified with Build ID 2001070604
Whiteboard: [FIX ON THE TRUNK] → [FIXED AND VERIFIED ON THE TRUNK]
Comment 10•23 years ago
|
||
The fix for this is pretty straightforward and has baked on the trunk for more than a week. Without this fix, the page above does not display at all. Any page that does a document.write() of a LINK element that loads an external stylesheet will be affected by this fix. Marking nsBranch+
Whiteboard: [FIXED AND VERIFIED ON THE TRUNK] → [nsBranch+][FIXED AND VERIFIED ON THE TRUNK]
Updated•23 years ago
|
Whiteboard: [nsBranch+][FIXED AND VERIFIED ON THE TRUNK] → [pdt+][nsBranch+][FIXED AND VERIFIED ON THE TRUNK]
Assignee | ||
Comment 11•23 years ago
|
||
Fixed on the brach and the trunk now.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 12•23 years ago
|
||
Verified with todays branch builds [2001-07-23-06] with WinNT.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•