271184 - Missing content in the page displayed

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Jayanta Mandal]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

I do not see any content in the page displayed for the URL mentioned above in
the URL field (This is one of the URL out of lot). Whereas I could see the lot
of content when I see the view page source for the same page.


Reproducible: Always
Steps to Reproduce:
1. GO to http://ind.cricinfo.com/db/PLAYERS/AUS/M/MCGRATH_GD_02002101/
2.
3.

Actual Results:  
See the Detail section.

Expected Results:  
Page must display the content.

Check the "view page source" to get actual html content for the page.

Comment 1

[Martijn Wargers (dead)]

after long searching I think this is an error in the website.
See:
http://direct.ninemsn.com.au/jnserver/CAT=SPORT/SITE=NINEMSN.BAGGYGREEN/AREA=PLAYER.PROFILES/LOC=TOP/AAMSZ=BANNER/PAGEID=1101133421685/ACC_RANDOM=1101133421685?
This script gets dynamically written in the page.
But in that script, I think, there is the error.
The script tag gets closed before the iframe gets closed, but it should become
closed after the iframe gets closed. (this is all in document.write stuff)

Comment 2

[Martijn Wargers (dead)]

Attachment: js file for testcase

Comment 3

[Martijn Wargers (dead)]

Attachment: Testcase

Well, it might be incorrectly nested tags inside js document.write statements,
but I still don't know the text underneath the table doesn't show up.
Maybe it is eaten up by the iframe element (as content inside the
<iframe></iframe>), but then I should be able to see it inside the DOM
inspector, which I can't.

Comment 4

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 5

[Boris Zbarsky [:bzbarsky]]

Blake, how's this testcase in your build?

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Amazingly, my build displays an <iframe> with the content |empty doc, you should
be able to see "this really should be seen", I guess| and the text |this really
should be seen, either in the document or in the dom inspector|.

I say "amazingly" because these <script> within <script>s seem to play with our
poor parser's mind. Note that I do assert once loading the page.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Sounds like this is fixed in your build then... mark it dependent on the
relevant bug with patch?  ;)

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Marking fixed. Note that there may be additional issues with the original page
(a couple of times the banner ad overwrote all of the page content) but that
should be a seperate bug.

Comment 9

[Martijn Wargers (dead)]

Ok, the behavior of the testcase changed. I'm reopening it.
With a 2005-02-17 build, the text right besides the iframe can be seen, but with
a 2005-02-20 build, the text cannot be seen anymore (it is parsed inside the
iframe tag).
I'm not sure what behavior is more correct. With IE6, I can see the text right
besides the iframe in a similar testcase (that uses no data uri).

Comment 10

[Martijn Wargers (dead)]

This is a bonsai link for the regression range:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-02-17+07%3A00%3A00&maxdate=2005-02-20+07%3A00%3A00&cvsroot=%2Fcvsroot

Comment 11

[Boris Zbarsky [:bzbarsky]]

Confirming.  It looks like this regressed between 2005-02-18-06 and
2005-02-19-06; there are a couple parser checkins in there:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-02-18+04%3A00%3A00&maxdate=2005-02-19+08%3A00%3A00&cvsroot=%2Fcvsroot

Blake, any idea what's up here?

Comment 12

[Blake Kaplan (:mrbkap) (inactive)]

The current plan of attack is to not rely on a lucky sequence of events (which
is now impossible) as we do for bug 97886, but instead to generate proper parser
keys for document.write().

Comment 13

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1

Instead of relying on mWriteLevel to be correct (which it never is), this uses
the currently executing script element as a key. This will generate new parser
contexts in the parser for each scripts' document.write()s. The parser then
correctly creates new parser contexts and inserts unused input into the other
correct contexts.

Comment 14

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1.1

Missed a file in patch v1.

Comment 15

[Johnny Stenback (:jst)]

Comment on attachment 185232 [details] [diff] [review]
patch v1.1

sr=jst

Comment 16

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 185232 [details] [diff] [review]
patch v1.1

This makes nested document.write()s work better by ensuring that their content
is written and parsed in the order dictated by the author (as opposed to
backwards)

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked in. Thanks for catching this!

Comment 18

[Blake Kaplan (:mrbkap) (inactive)]

*** Bug 297323 has been marked as a duplicate of this bug. ***

Comment 19

[Blake Kaplan (:mrbkap) (inactive)]

*** Bug 216685 has been marked as a duplicate of this bug. ***