Closed Bug 379025 Opened 18 years ago Closed 18 years ago

IBM Infocenter web pages don't display any content

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha6

People

(Reporter: matt.lavin, Assigned: mrbkap)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

testcase
(deleted), text/html
Details
Fix, for real
(deleted), patch
sicking
: review+
jst
: superreview+
Details | Diff | Splinter Review
Mochitest
(deleted), patch
sayrer
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070426 Minefield/3.0a4pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070426 Minefield/3.0a4pre IBM support 'Infocenter' web pages don't show any content when they are loaded. The pages loaded fine in Firefox 2 and in IE. Reproducible: Always Steps to Reproduce: 1. Visit the http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp page.
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Chtml%3E%0D%0A%3Chead%3E%0D%0A%3Cnoscript%3E%0D%0A%3C/noscript%3E%0D%0A%0D%0A%3Cstyle%3E%0D%0A%3C/style%3E%0D%0A%3C/head%3E%0D%0A%0D%0A%3Cframeset%20rows%3D%22300%2C*%22%3E%0D%0A%20%20%3Cframe%20src%3D%22%22%3E%0D%0A%20%20%3Cframe%20src%3D%22%22%3E%0D%0A%3C/frameset%3E%0D%0A%3C/html%3E IE7 allows the <noscript> tag in the head. Firefox doesn't seem to allow that and currently even wraps it in the <body>, which seems the reason why the frame related tags get thrown away. So maybe <noscript> should be allowed in the head?
Assignee: nobody → mrbkap
Status: UNCONFIRMED → NEW
Component: General → HTML: Parser
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → parser
Flags: blocking1.9?
Version: unspecified → Trunk
Attached file testcase (deleted) —
Attached patch Wrong file (obsolete) (deleted) — — Splinter Review
This is one fix. It might be scary, though, since now with script turned off, <head><noscript><table><foo> has to work right (and we're back where we started with <object>). I was also considering a fix that would add a kPreferHead special prop to the element table and sticking it on <style>. kPreferHead would override the mMisplacedContent.GetSize() check found at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/parser/htmlparser/src/CNavDTD.cpp&rev=3.490&mark=626&root=/cvsroot#622 . Perhaps we should do both...
Attachment #263040 - Flags: superreview?(jst)
Attachment #263040 - Flags: review?(jonas)
Attached patch Fix, for real (deleted) — — Splinter Review
Sorry, attached the wrong filename before.
Attachment #263040 - Attachment is obsolete: true
Attachment #263041 - Flags: superreview?(jst)
Attachment #263041 - Flags: review?(jonas)
Attachment #263040 - Flags: superreview?(jst)
Attachment #263040 - Flags: review?(jonas)
Attachment #263040 - Attachment description: Fix → Wrong file
Flags: in-testsuite?
Blocking since it's a regression and there is a patch. Blake, could you explain what'll happen with this patch? It's all black magic to me :)
Flags: blocking1.9? → blocking1.9+
(In reply to comment #5) > Created an attachment (id=263041) [details] mrbkap, could you attach a file containing test cases in the same format as http://lxr.mozilla.org/seamonkey/source/parser/htmlparser/tests/mochitest/html5lib_tree_dat3.txt the data section is the input, while the document section shows the expected DOM hierarchy through indenting.
Comment on attachment 263041 [details] [diff] [review] Fix, for real Sure, lets try it :)
Attachment #263041 - Flags: review?(jonas) → review+
(In reply to comment #6) > Blake, could you explain what'll happen with this patch? It's all black magic > to me :) This patch is a little bit of a hack, and I'm hoping to follow up with a more general fix that won't rely on elements other than <style> having the right flags. The problem here deals with the source: <noscript></noscript><style>foo</style>. The <noscript> is not a valid child of the head, so we add it to the misplaced element queue. <style> used to be a head-only element, which meant that it would ignore the misplaced queue and stick itself directly into the head, leaving the <noscript> to be processed later. Now, it falls into the codepath here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/parser/htmlparser/src/CNavDTD.cpp&rev=3.490&root=/cvsroot&mark=626-628#625 and sticks the <style> element into the misplaced queue, but leaves the "foo" on the tokenizer. The text causes us to open a body element, and once we have either a <body> or <frameset>, the other will be ignored later, causing the page to not be displayed. The fix allows the <noscript> to be a child of the head, allowing the <style> to be a child of the head as well. As a followup fix, I'm hoping to make the <style> ignore the already-misplaced content.
Status: NEW → ASSIGNED
Targeting A6 per conversation with Blake.
Target Milestone: --- → mozilla1.9alpha6
Attachment #263041 - Flags: superreview?(jst) → superreview+
I checked the fix in for this bug in on Friday, it seems. Looking at adding a mochitest for it now.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Attached patch Mochitest (deleted) — — Splinter Review
I admit that I'm sort of stumbling around in the dark here, but this seems to work.
Attachment #269751 - Flags: review?(sayrer)
Attachment #269751 - Flags: review?(sayrer) → review+
Flags: in-testsuite? → in-testsuite+
Depends on: 401169
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: