Bug 11572 – REGRESSION: U+0000 is no longer treated as whitespace, causing rendering trouble

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Tyson Safavi]

Menu Icons are duplicated and navigation on right side is overlapping

[Alexey Proskuryakov]

Confirmed as a regression (for me, the navigation on the right side appeared unstyled on the left).

[Joost de Valk (AlthA)]

Created attachment 12559 [details]
Testcase for the left side of the menu

Ok the rendering on the left side of the menu goes wrong because of a weird charachter right behind the ; in the style block.

[Joost de Valk (AlthA)]

Created attachment 12561 [details]
Reduced testcase

Ok, both wrong renderings boil down to the fact that the first char in this testcases causes ToT to render a margin before the text in the div, where release does not.

[Joost de Valk (AlthA)]

U+0001 used to be treated as whitespace in release, and now isn't anymore, causing the rendering here to break.

[Mark Rowe (bdash)]

The test case looks identical to me in WebKit 418.9.1 and ToT.  What am I missing?

[Sam Weinig]

There was a difference a few days ago.  Perhaps r18988 (http://trac.webkit.org/projects/webkit/changeset/18988) fixed it. 

[Ian 'Hixie' Hickson]

I don't understand exactly what this bug is about, but U+0001 shouldn't be treated as whitespace according to either CSS or HTML. Could you elaborate? Does IE do this too? Should the specs be fixed?

[Joost de Valk (AlthA)]

The bug seems fixed indeed, both the testcase and URL work fine now. Hixie: it wasn't being treated as whitespace it seems, it was ignored, and it seems to be ignored again now. What it did in the regression was unclear to me, it did cause rendering errors though... What SHOULD a browser be doing? I expect it should ignore it?

[Mark Rowe (bdash)]

I think the title is incorrect, and that the character that is present and causing the problem is U+0000 rather than U+0001.  The following command show that U+0001 isn't even present in the URL linked in the bug description:

atlas:~ mrowe$ curl -s http://www.denkor.com/en_US/ALL/aboutus/cu/index.shtml | xxd | cut -d ' ' -f 2-9 | egrep '(^00|00$| 00|00 )'
2f2d 2d3e 0a3c 2f73 6372 6970 743e 0000
723b 0000 0a20 2020 0a20 2020 626f 7264
743a 2031 3770 783b 0000 0a0a 2020 2066
3d22 5374 6172 7422 3e3c 2f61 3e00 000a
3c2f 7472 3e0a 3c2f 7461 626c 653e 0000
atlas:~ mrowe$ curl -s http://www.denkor.com/en_US/ALL/aboutus/cu/index.shtml | xxd | cut -d ' ' -f 2-9 | egrep '(^01|01$| 01|01 )'
atlas:~ mrowe$ 

I'm not sure whether this changes anything about the expected behaviour, but I'm mentioning it for sake of correctness.

[Ian 'Hixie' Hickson]

Where excatly are we talking about? As normal character data? As normal character data, U+0001 should, according to the HTML5 draft spec, be treated as normal character data like "x". Or do you mean elsewhere?

Assuming you do mean in HTML parsing, I wouldn't worry about the spec yet. Once the spec is stable, we can get browsers to look at implementing it but until then there's not really any point.

[Ian 'Hixie' Hickson]

Ah, per HTML5, all U+0000 NULL characters in the input must be replaced by U+FFFD REPLACEMENT CHARACTERs before the parser sees the input stream, even in the middle of a tagname. But my above caveat still applies.

[Joost de Valk (AlthA)]

Well fact was that it was behaving differently than release, that seems now solved :)

these replacement characters mean that it get's ignored by the parser i assume?

[Ian 'Hixie' Hickson]

No, they just get treated like unknown characters, like "%" or something.