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
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.
Bug 84634 seems vaguely related.
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
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=?
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.
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]
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]
Whiteboard: [nsBranch+][FIXED AND VERIFIED ON THE TRUNK] → [pdt+][nsBranch+][FIXED AND VERIFIED ON THE TRUNK]
Fixed on the brach and the trunk now.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
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.