JavaScript banner code forces banner to be the only thing displayed

VERIFIED FIXED in mozilla0.9.3

Status

()

Core
DOM: Core & HTML
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: David Hansmann, Assigned: jst)

Tracking

Trunk
mozilla0.9.3
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pdt+][nsBranch+][FIXED AND VERIFIED ON THE TRUNK], URL)

Attachments

(1 attachment)

(Reporter)

Description

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

17 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
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.
(Assignee)

Comment 4

17 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

17 years ago
Created attachment 40550 [details] [diff] [review]
Proposed fix done mostly by vidur.
(Assignee)

Comment 6

17 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

17 years ago
Target Milestone: --- → mozilla0.9.3
(Assignee)

Updated

17 years ago
Whiteboard: [HAVE FIX]

Comment 7

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

17 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).

Comment 9

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

17 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

17 years ago
Whiteboard: [nsBranch+][FIXED AND VERIFIED ON THE TRUNK] → [pdt+][nsBranch+][FIXED AND VERIFIED ON THE TRUNK]
(Assignee)

Comment 11

17 years ago
Fixed on the brach and the trunk now.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 12

17 years ago
Verified with todays branch builds [2001-07-23-06] with WinNT.
Status: RESOLVED → VERIFIED

Updated

10 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: desale → general
You need to log in before you can comment on or make changes to this bug.