User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

It depends on the Light or Dark theme.
E.g. Goto https://www1.reaal.nl/
You get a popup? screen with check boxes.
I check the first two, but you won't see it.
Then I goto button "Selectie toestaan" (last button on page)
Then you will go to next window.

Actual results:

Same problem with radiobuttons (I will not give example. This with the radiobuttons and the checkboxes will happen on every page with those radiobuttons and the checkboxes.)

Expected results:

If I choose or check a radiobutton or checkbox, I (normally must) see my choices, that is: a black dot or a black cross.

I don't know what a 'browser's user agent string' is.

The Bugbug bot thinks this bug should belong to the 'Firefox::Theme' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Hi - thanks for filing. However, I am unable to reproduce this.
Is it possible for you to share some screenshots with us?
Also - does it happen with a fresh profile (Go to "about:profiles," create a new profile, then "Launch profile in new browser")?

I did as follows:

1. Go to the website
2. Click the middle button on the cookie banner ("Aanpassen")
3. Note that the first checkbox is checked and locked, the second one is also checked but is uncheckable

I see that they are checked - the first checkbox has a grey background with white check and the second checkbox has green background with white check. Other boxes behave identically to the second checkbox.

I've tried to reproduce this on Windows 10 with Firefox 113, with:

• Windows-wide dark theme for apps enabled
• Firefox's Website Appearance set to Dark
• Firefox's Theme set to Dark

In de Prullenbak, do you have High Contrast mode enabled in the Windows display settings?

The issue described seems to be related to High Contrast mode, and perhaps specifically to the "High Contrast White" theme. With that theme, I see a similar issue in Chrome and Edge, too.

Note that checkboxes with the browser's default appearance do NOT have this issue; with High Contrast White enabled, they get a dark background when checked, and a white checkmark. But checkboxes that are styled by the web page (as in the https://www1.reaal.nl/ example, or indeed the checkboxes right here in bugzilla) may end up with a white checkmark (it's a custom SVG image in the https://www1.reaal.nl/ case, for instance) on a white background, which obviously doesn't work well.

Morgan, do you have a clear idea what ought to be happening here to avoid the potential white-on-white result?

It looks like they're setting an SVG as the background of the checkbox (which, itself is a pseudo element and not actually a form control). I think we're doing the appropriate thing here by computing the background-color property as Canvas, though it seems like based on the author's use case they'd be better off using CanvasText.

You could argue we should be overriding fill with CanvasText or some other non-Canvas colour, I suppose, though I'm not sure that behaviour is spec'd, I'll have to look.

Ah it looks like spec behaviour is that <svg> elements have special forced-color-adjust values, which I couldn't find in our style sheets right now. See https://www.w3.org/TR/css-color-adjust-1/#forced-color-adjust-prop, specifically:

In order to not break SVG content, UAs are expected to add the following rules to their UA style sheet:

@namespace "http://www.w3.org/2000/svg";
svg|svg { forced-color-adjust: preserve-parent-color; }
svg|foreignObject { forced-color-adjust: auto; }

it also seems like we're not handling fill in forced colors mode (or at least, I don't see it marked ignored_when_colors_disabled in the longhands file)