1857395 - Firefox is stripping some in-line color codes

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[drbot7]

Steps to reproduce:

1. Go to https://rgb.birdflop.com
2. Use #27FF77 as hex color #1, #2F7777 as hex color #2, and ABCDEFGHIJKLMNOPQRSTUVWXYZ as the input. You can leave everything else as it is.

You can also try testing out other colors and strings if you'd like. It seems to only remove the styling for a small portion of colors maybe around 1%.

Actual results:

Observe that EF and VWX are white when they should be colored. Using inspect on the text, you can see that the surrounding colors have their styling intact but its just some characters that have had their styling stripped.

<span style="color: rgb(40, 239, 119);">D</span>
<span>E</span>
<span>F</span>
<span style="color: rgb(41, 222, 119);">G</span>

Expected results:

It should have kept the styling attached to the characters. It keeps the styling on other browser that I tested including Safari and Chrome so I believe that the server is sending the appropriate html to the browser.

I'm unsure if this even could be a bug with the website, but since it works on any other browser, I felt it was appropriate to try opening an issue here. The website is open source if you feel the need to take a look. https://github.com/birdflop/website/tree/main/resources/rgb

Comment 1

[Alice0775 White]

The site script calculated style as follows.
https://www.birdflop.com/resources/rgb/script.js line357
coloredNickSpan.style.color = colors[i];

If colors[i] is calculated as "0016e9", the web console shows following error:

Expected color but found ‘16000000000.0’. Error in parsing value for ‘color’. Declaration dropped.

Comment 2

[Alice0775 White]

Attachment: testcase.html

Comment 3

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ee15873640b6&tochange=ce3bd1ad8565

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

:dbaron, since you are the author of the regressor, bug 964529, could you take a look?

For more information, please visit BugBot documentation.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

I think this is might be invalid per spec, if a bit unfortunate. https://drafts.csswg.org/css-color-4/#quirky-color says:

If it’s a <number-token>, it must have its integer flag set. Serialize the integer’s value. If the serialization has less than 6 characters, prepend "0" characters to it until it is 6 characters long.

So it kinda relies on how you serialize that number... Code for it nowadays is here.

David, do you have opinions? In any case the site could just use the standard syntax...

Comment 6

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

I don't have strong opinions here since I haven't really thought about parsing quirks for years, but I think my inclination is that:

• if we want to keep <quirky-color> as operating on a stream of valid tokens, we probably don't want to change anything about <quirky-color> itself
• we could plausibly make some improvements to the fidelity with which tokens serialize to what the were originally
• it's maybe possible (though maybe not) that we could make things like <quirky-color> operate on the original character stream rather than on the token stream, which could make these issues go away. (do CSS variables do something like this? I've forgotten.)
• it's probably not worth changing much unless (a) real sites are broken or (b) there's lack of interop between implementations

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.