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)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: kinetik, Assigned: hsivonen)
References
()
Details
(Keywords: regression)
Attachments
(3 files)
+++ 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.
Reporter | ||
Comment 1•14 years ago
|
||
Testcase shows the ASCII NUL when the HTML5 parser is enabled. With it disabled, and in Safari 4, it shows "i win" as expected.
Reporter | ||
Comment 2•14 years ago
|
||
Assignee | ||
Comment 3•14 years ago
|
||
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>
Reporter | ||
Comment 4•14 years ago
|
||
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.
Assignee | ||
Comment 5•14 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
Summary: [HTML5] Early U+0000 eats <frameset> → [HTML5] Early U+0000 eats <frameset> (Can't configure D-Link DSL-G604T ADSL router)
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 8•14 years ago
|
||
We should sort this out for 1.9.3.
blocking2.0: ? → final+
Keywords: regression
Assignee | ||
Comment 9•14 years ago
|
||
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Assignee | ||
Comment 11•14 years ago
|
||
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+
Assignee | ||
Comment 13•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/ae259fec2443
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 14•14 years ago
|
||
The test for bug 566280 now effectively tests for this bug, too.
Flags: in-testsuite+
Comment 16•14 years ago
|
||
Looks like this is not completely fixed yet - the following testcase still fails: �<html> <head> <title>HTML5 parser bug</title> </head> <frameset> <frame src="data:text/html,PASS"> </frame> </html> Here, we have an � entity rather than a literal ASCII NUL (U+0000). This still causes the frameset to be ignored.
Assignee | ||
Comment 17•14 years ago
|
||
(In reply to comment #16) > Looks like this is not completely fixed yet - the following testcase still > fails: > > �<html> > <head> > <title>HTML5 parser bug</title> > </head> > <frameset> > <frame src="data:text/html,PASS"> > </frame> > </html> > > > Here, we have an � 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?
Comment 18•14 years ago
|
||
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.
Description
•