1249755 - [quirks mode] Incorrect parsing of hashless CSS colors that begin with something that looks like a scientific notation number

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[orsha.kaluga]

Attachment: picture.html

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160209234642

Steps to reproduce:

1. Open attached .html file
2. See the bug


Actual results:

Some of colours (#9e9e9e, #8e8e8e, ..., #0e0e0e) are displayed incorrectly.


Expected results:

All colours should be displayed correctly.

Comment 1

[Loic]

Reg range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2e486e139e76a52cac490d8939ef653fd404cc93&tochange=7ff25645a05855ef09a359b4d46d4701976003ff

Comment 2

[Loic]

Any idea, Alice?

Comment 3

[Alice0775 White]

In this case, "e" means scientific notation. And also 9e9e9e is invalid <number>. Browser has been confusion?

See https://developer.mozilla.org/en-US/Firefox/Releases/29#CSS
> Scientific exponential notation, like 3e1 or 10e+0, is now supported for <number> values and
> derivatives, like <percentage> and unit values, but not <integer>  (bug 964529).

Anyway, I think this is invalid bug.

Comment 4

[Loic]

Yes, but for background-color? I don't see any reason to support scientific notation over color notation for this attribute.

Comment 5

[Alice0775 White]

@dbaron ?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Was comment 2 the wrong regression range?

This does seem like a valid bug; we shouldn't be responding in such a weird way.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oh, and to find the code for this quirk, look for mHashlessColorQuirk in layout/style/nsCSSParser.cpp .

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

To fix this, we can probably use the scanner's GetTokenOffset() method to simplify the big if (mHashlessColorQuirk) block in CSSParserImpl::ParseColor to just re-scan the buffer, instead of switching on token type.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Note that Chrome has introduce a slightly different bug (the lines are white rather than more interesting colors), probably as a result of implementing what https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk says, including what for us would be an mIntegerValid check.

Comment 10

[Simon Pieters [:zcorpan]]

Originally I specified something closer to what IE did, with preserving the CSS token's source text and having a strict syntax check of that string. But it seemed like Gecko/WebKit/Blink were not so interested in implementing that because it increases memory (I think?), and what they were doing was good enough for Web compat (this bug notwithstanding). So I changed the spec to take the other approach, which meant that some colors fail to parse. Unfortunate, but this is quirks mode, and omitting the hash is an authoring error. Can't we say that this is just the way it is, and recommend against using quirks mode in the first place?

This is also tested in http://w3c-test.org/quirks-mode/hashless-hex-color.html btw ("1e1" etc).

There are more ways where this quirk is non-sensical. Like "99" is accepted as a color, but "aa" is not. However, "making sense" is not a design goal for quirks for me... :-) If we can get interop and good-enough Web compat, I'm happy.

Comment 11

[Simon Pieters [:zcorpan]]

I researched httparchive and concluded to not change the spec. See analysis in https://www.w3.org/Bugs/Public/show_bug.cgi?id=29489#c2