Bug 12145 – Color parsing is too relaxed in strict mode

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Sam Weinig]

The testcase pointed to in the URL field demonstrates a way in which the css color parsing is too relaxed.  In particular, hexidecimal color values without a leading # should be illegal.  This test passes in Firefox 2, IE7 and Opera 9, but not in either shipping Safari or WebKit ToT.

[Dave Hyatt]

Try the same test without the doctype (in quirks mode).  Probably a quirk that isn't properly qualified.

[Sam Weinig]

(In reply to comment #1)
> Try the same test without the doctype (in quirks mode).  Probably a quirk that
> isn't properly qualified.

You are correct.  In quirks mode Firefox, IE and Opera, the line does get successfully parsed.

[Sam Weinig]

Created attachment 12271 [details]
testcase (strict mode)

[Sam Weinig]

Created attachment 12272 [details]
testcase (quirks mode)

[Rob Buis]

Created attachment 12336 [details]
First attempt

I figured out the Format substitution (http://trac.webkit.org/projects/webkit/changeset/17700) broke
color parsing like color: 33FFFF. Related is handling of FF33333, as shown by the testcases for this bug. This patch should fix both.
Cheers,

Rob.

[Darin Adler]

Comment on attachment 12336 [details]
First attempt

Looks fine, r=me.

+    if (Color::parseHexColor(name, rgb) && !strict)
         return true;

It would be nice to not even parse in the strict case. Just reverse the two halves of the &&.

+        static RGBA32 parseColor(const String&, bool = false);

Should have the name strict here, since bool along doesn't make it clear what the parameter is.

+        static bool parseColor(const String&, RGBA32& rgb, bool);

Ditto.

[Rob Buis]

Landed in r18722.