Bug 40200 – "Fix" fast/dom/stripNullFromTextNodes.html in HTML5 parser

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Adam Barth]

"Fix" fast/dom/stripNullFromTextNodes.html in HTML5 parser

[Adam Barth]

Created attachment 57958 [details]
Patch

[Eric Seidel (no email)]

Comment on attachment 57958 [details]
Patch

I guess we don't have any way to check in results for a test like this, eh?  We could with the html5lib tests.

Please consider adding a test with checked in results.

[Alexey Proskuryakov]

So, neither WebKit nor shipping versions of Gecko turn nulls into U+FFFD, but HTML5 requires that. Could it be a bug in the spec? What does IE do?

[Alexey Proskuryakov]

For some context: HTML5 offline storage parser also had the requirement to turn nulls into U+FFFD, which was dropped based on our feedback.

U+FFFD is generally used to signal decoding errors, which a null definitely doesn't cause.

[Adam Barth]

I believe swallows the nulls, but I haven't tested recently.  We should file a bug with the HTML5 WG.

[Alexey Proskuryakov]

I tested in more detail, and it seems to be trickier:
- WebKit passes stripNullFromTextNodes.html, as it strips nulls from text node content;
- so does IE 7;
- Firefox 3.6.3 actually fails the test, and inserts U+FFFD;
- but Firefox passes an original reduction for rdar://4702420, which I incorrectly assumed to be the same: <div>\0</div>

So, Firefox seems to drop the null if it's the only character in a text node (?!)

[Alexey Proskuryakov]

Created attachment 57967 [details]
original reduction

[Adam Barth]

Comment on attachment 57958 [details]
Patch

Clearing flags on attachment: 57958

Committed r60791: <http://trac.webkit.org/changeset/60791>

[Adam Barth]

All reviewed patches have been landed.  Closing bug.