Closed Bug 271184 Opened 15 years ago Closed 15 years ago

Missing content in the page displayed

Categories

(Core :: DOM: HTML Parser, defect)

x86
Windows 2000
defect
Not set

Tracking

()

VERIFIED FIXED

People

(Reporter: jayanta.mandal, Assigned: mrbkap)

References

()

Details

(Keywords: testcase)

Attachments

(3 files, 2 obsolete files)

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.
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)
Attachment #166765 - Attachment mime type: application/x-javascript → text/javascript
Attached file Testcase (obsolete) —
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.
Attached file Testcase
Attachment #166766 - Attachment is obsolete: true
Keywords: testcase
Component: General → DOM: Level 0
Product: Firefox → Browser
Version: unspecified → Trunk
Blake, how's this testcase in your build?
Assignee: firefox → parser
Component: DOM: Level 0 → HTML: Parser
QA Contact: firefox.general → mrbkap
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.
Sounds like this is fixed in your build then... mark it dependent on the
relevant bug with patch?  ;)
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.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Depends on: 88952
Resolution: --- → FIXED
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).
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
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().
Assignee: parser → mrbkap
Status: NEW → ASSIGNED
Attached patch patch v1 (obsolete) — Splinter Review
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.
Attachment #185223 - Flags: superreview?(jst)
Attachment #185223 - Flags: review?(bugmail)
Attached patch patch v1.1Splinter Review
Missed a file in patch v1.
Attachment #185223 - Attachment is obsolete: true
Attachment #185232 - Flags: superreview?(jst)
Attachment #185232 - Flags: review?(bugmail)
Attachment #185223 - Flags: superreview?(jst)
Comment on attachment 185232 [details] [diff] [review]
patch v1.1

sr=jst
Attachment #185232 - Flags: superreview?(jst) → superreview+
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)
Attachment #185232 - Flags: approval1.8b3?
Attachment #185232 - Flags: approval1.8b3? → approval1.8b3+
Fix checked in. Thanks for catching this!
Status: ASSIGNED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
*** Bug 297323 has been marked as a duplicate of this bug. ***
*** Bug 216685 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.