[Webkit-unassigned] [Bug 69083] Several CSS lexer rules don't match CSS 2.1 spec
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Oct 26 03:10:52 PDT 2011
https://bugs.webkit.org/show_bug.cgi?id=69083
--- Comment #6 from Zoltan Herczeg <zherczeg at webkit.org> 2011-10-26 03:10:51 PST ---
Playing with the CSS tokenizer is quite funny. Although there are several bugs in the tokeinzer, they cannot be exploited because other mechanics hides them.
Yesterday I checked an URI parsing bug. Due to a bug in CSSParser::text(...) the slash-newlines sequences are converted to newline in the same way as '\a' converted to 'a', so they are treated as normal escape sequences. I thought I could exploit this, but I didn't work, since there is another funny CSS rule, which says chars < 32 must be skipped.
So www<tab>.<tab>google<tab>.<tab>com is the same as www.google.com since <tab> is equal to 9, which is less than 32, and discarded. However, www<space>.<space>google<space>.<space>com is different, since <space> is not less than 32. <newline> is equal to 10, so it is discarded as well.
Today I checked this bug:
> Another batch of what are considered control characters.
>
> > original:
> > unicode \\{h}{1,6}(\r\n|[ \t\r\n\f])?
> > wk:
> > unicode \\{h}{1,6}[ \t\r\n\f]?
> >
> > This can be exploited by a \r\n newline: A\41\r\nB should be "AAB" but it will be "AA" and "B" in WK.
>
> Seems likely to just be a bug.
Guess what it does not appear as well. Why?
WebCore/xml/MarkupTokenizerBase.h InputStreamPreprocessor::peek(...) converts '\r\n' sequences to '\n'! This function is indirectly called from WebCore/html/parser/HTMLDocumentParser.cpp:267 through m_tokenizer->nextToken(...). Thus, the CSS parser never encounters a '\r\n'.
Although we could simplify the "nl \n|\r\n|\r|\f" rule and CSSParser::text(...), I don't want to do it since I hope they will be dropped in the future as the hand written parser is more than twice as fast.
But I want to add a newline related layout test.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list