84648 - JavaScript banner code forces banner to be the only thing displayed

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[David Hansmann]

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

[Fabian Guisset]

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.

Comment 2

[Peter Van der Beken [:peterv]]

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.

Comment 3

[Peter Van der Beken [:peterv]]

Bug 84634 seems vaguely related.

Comment 4

[Johnny Stenback (:jst)]

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.

Comment 5

[Johnny Stenback (:jst)]

Attachment: Proposed fix done mostly by vidur.

Comment 6

[Johnny Stenback (:jst)]

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=?

Comment 7

[harishd]

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.

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

nsBranch ok, but please remember not to reintroduced the initial regression
caused on the trunk... (says vidur).

Comment 9

[harishd]

The above URL and the links in it load fine.

Verified with Build ID 2001070604

Comment 10

[Nisheeth Ranjan]

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+

Comment 11

[Johnny Stenback (:jst)]

Fixed on the brach and the trunk now.

Comment 12

[Prashant Desale]

Verified with todays branch builds [2001-07-23-06] with WinNT.