| Summary: | "Fix" fast/dom/stripNullFromTextNodes.html in HTML5 parser | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Adam Barth <abarth> | ||||||
| Component: | DOM | Assignee: | Adam Barth <abarth> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | ap, eric | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | Other | ||||||||
| OS: | OS X 10.5 | ||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 39259 | ||||||||
| Attachments: |
|
||||||||
|
Description
Adam Barth
2010-06-04 20:59:16 PDT
Created attachment 57958 [details]
Patch
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.
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? 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. I believe swallows the nulls, but I haven't tested recently. We should file a bug with the HTML5 WG. 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 (?!) Created attachment 57967 [details]
original reduction
Comment on attachment 57958 [details] Patch Clearing flags on attachment: 57958 Committed r60791: <http://trac.webkit.org/changeset/60791> All reviewed patches have been landed. Closing bug. |