Closed Bug 563526 Opened 14 years ago Closed 14 years ago

[HTML5] Early U+0000 eats <frameset> (Can't configure D-Link DSL-G604T ADSL router)

Categories

(Core :: DOM: HTML Parser, defect, P2)

x86
macOS
defect

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: kinetik, Assigned: hsivonen)

References

()

Details

(Keywords: regression)

Attachments

(3 files)

Attached file testcase
+++ This bug was initially created as a clone of Bug #514602 +++

I forgot to test the fix for the original bug against the problematic router.  I've just tested now and it's still broken.  There's a difference between the testcase I submitted and what the router actually sends--the first byte of the document is an ASCII NUL.  New testcase attached.
Testcase shows the ASCII NUL when the HTML5 parser is enabled.  With it disabled, and in Safari 4, it shows "i win" as expected.
What router is this?

Regardless of the router model, having this is any router out there is pretty bad. I think this needs escalation to spec. The potential fix I see is distinguishing between literal U+FFFD and U+0000 mapped to U+FFFD and treating the latter as white space in the tree builder.
Summary: [HTML5] Early closing </html> tag eats <frameset> → [HTML5] Early U+0000 eats <frameset>
It's the D-Link DSL-G604T ADSL router.  Cheap and very common in at least Australia and New Zealand as it's often included free when signing up for DSL service.  There's one in the NZ MoCo office with the latest firmware that exhibits this problem.
Filed as http://www.w3.org/Bugs/Public/show_bug.cgi?id=9659 with a narrowed fix suggestion than what I suggested in comment 3.
Summary: [HTML5] Early U+0000 eats <frameset> → [HTML5] Early U+0000 eats <frameset> (Can't configure D-Link DSL-G604T ADSL router)
Not an alpha blocker.
Priority: P1 → P2
blocking2.0: --- → ?
We should sort this out for 1.9.3.
blocking2.0: ? → final+
Keywords: regression
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Comment on attachment 449619 [details] [diff] [review]
Patch anticipating a spec change

Let's land this ahead of spec change.
Attachment #449619 - Flags: review?(jonas)
Comment on attachment 449619 [details] [diff] [review]
Patch anticipating a spec change

Not quite following what changes this results in as far as parsing goes. However as long as we're tracking the spec once there is a decision then it seems good.
Attachment #449619 - Flags: review?(jonas) → review+
http://hg.mozilla.org/mozilla-central/rev/ae259fec2443
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
The test for bug 566280 now effectively tests for this bug, too.
Flags: in-testsuite+
Looks like this is not completely fixed yet - the following testcase still fails:

&#0;<html>
<head>
<title>HTML5 parser bug</title>
</head>
<frameset>
<frame src="data:text/html,PASS">
</frame>
</html>


Here, we have an &#0; entity rather than a literal ASCII NUL (U+0000). This still causes the frameset to be ignored.
(In reply to comment #16)
> Looks like this is not completely fixed yet - the following testcase still
> fails:
> 
> &#0;<html>
> <head>
> <title>HTML5 parser bug</title>
> </head>
> <frameset>
> <frame src="data:text/html,PASS">
> </frame>
> </html>
> 
> 
> Here, we have an &#0; entity rather than a literal ASCII NUL (U+0000). This
> still causes the frameset to be ignored.

Is that a problem for real existing content?
Probably not, but it is a potential method to block Firefox from webpages in a way that looks like the browser is at fault (remember the "Why Firefox is blocked" campaign a few years ago).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: