1951930 - Firefox radio buttons unusable on dark backgrounds

Status: VERIFIED FIXED

(Core :: Widget, defect, P1)

Description

[Matěj Humpál]

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

Steps to reproduce:

Updated from 129.0 to 136.0 and opened a form on a page with dark background

Actual results:

Radio buttons that were clearly recognizable, were changed so that only a border is colored, which is hard to distinguish

https://opu.peklo.biz/p/25/03/05/1741166450-f0e62.jpg

Expected results:

Previous version of radio buttons should be used as they were more usable.

https://opu.peklo.biz/p/25/03/05/1741170151-3bef8.jpg

Comment 1

[Alice0775 White]

Regressio window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=32d761bfc411cb5ba4caac64e72195ab3bf22094&tochange=95af8fcb06d6d29902d341778e2d0b8c18130c6c

Comment 2

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

Set release status flags based on info from the regressing bug 1941755

:emilio, since you are the author of the regressor, bug 1941755, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

This is only about the checked state, right? This was a change requested by UX.

FWIW the page can customize the accent color with the accent-color CSS property, so maybe not that bad? But anyways, not my call.

Comment 4

[Matěj Humpál]

Yes, that is about the check state. IMHO the checkbox should be usable with default accent-color no matter the background.

Comment 5

[Petr Soucek]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

This is only about the checked state, right? This was a change requested by UX.

What exactly means "This was a change requested by UX."?
IMHO the UX has worsened with this change.

Comment 6

[Martha Palotay]

The problem exists on light backgrounds, too: with the new appearance, both a selected and an unselected radio button are, essentially, white circles. There are subtle differences in line thickness and color, but those are hard to see and easy to dismiss as insignificant.

Comment 7

[gotmilk0112]

Yeah, not sure why this was changed. Just makes radio buttons harder to see. Especially if the website has a blue background color, the circle around the edge of the radio button becomes almost invisible.

Comment 8

[Eugene Savitsky]

We heavily use radio buttons in our company webUI.
Now all company (9 FF installations) is pissed off about the design change. It is harder to see it even on white background.

Chrome-based browsers showing is the classic way. Why would the change was needed?

Comment 9

[Eugene Savitsky]

Attachment: 2025-03-10_11-01-06.png

Comment 10

[Donal Meehan [:dmeehan]]

:dao could this be triaged for severity/priority?

Comment 11

[Tyson F Nuss]

As a UX professional, I agree this is a regression. Aside from the visibility issues mentioned above, the appearance is ambiguous, resembling the blue border that appears when a UI element merely has focus (e.g. using Tab-key navigation) but is not necessarily selected.

I infer this may have been meant to coordinate with the similarly-changed Windows 11 native radio buttons, but even there the circle outline is much thicker, leaving a smaller white dot in the center. IMO that was also a dubious decision and a pointless "change for the sake of change" on the part of MS UX folks, but at least their implementation of it was slightly less problematic.

Comment 12

[Julian Gaibler]

Hey everyone, thanks for all the feedback!

We updated the radio button design to better align with how they look natively across Windows, macOS, and common Linux environments. That said, I understand the concerns about visibility, especially on dark backgrounds.

Based on feedback, I’ve already filed bug 1952998 to make the white circle smaller so that the blue area stands out more. Hopefully, that will help with clarity on lighter background.

Regarding the original issue in this bug, I see how the previous version was easier to distinguish on darker backgrounds without relying on accent-color. I’ll take a closer look at that. However, Firefox is not the only browser using this style – Safari has a similar look, which also presents contrast challenges in your example-

We’re currently not planning to revert to the old look, but I’d love to better understand any other specific issues with the new design so we can explore potential refinements.

Again, I really appreciate the discussion, and I’m happy to keep listening to concerns to see where improvements can be made.

Comment 13

[Eugene Savitsky]

What do you mean with "look natively across Windows, macOS, and common Linux environments"?

Screenshots of Edge and Chrome. Checked Win 10 and Linux, they are looking the same.

Comment 14

[Eugene Savitsky]

Attachment: Edge

Comment 15

[Eugene Savitsky]

Attachment: Chrome

Comment 16

[Julian Gaibler]

Sorry, maybe I should have been more clear: I meant closer to how these systems render their own radio buttons. So not inside of Firefox, but across native surfaces like their respective system settings apps.

I am hearing Matěj on the dark background issue though, and will look into a way to rectify that.

Comment 17

[Eugene Savitsky]

Attachment: KDE

KDE has as well classic radio buttons. Do not have Gnome to check.

Comment 18

[Matěj Humpál]

Sigh.

I find the argument with default appearance of radio buttons in operating systems a bit off. Yes, Win 11, MacOS and IIRC Gnome on Ubuntu do have this "outer ring" style of radio buttons, but OSs do have a luxury of also (almost every time) knowing what the background and therefore the contrast between the selected radio and the background will be.

Given the inherent legacy nature of the web and ability of customization (od the background in this case), this doesn't apply here. And many websites/systems will not and/or can not be altered to better suit this new design.

And just changing the size of the ring/white circle will IMO not help the usability as the problem is the lack of contrast difference on the outside od the radio button. Or maybe it will just shift the problem somewhere else.

Just out od curiosity: were there any considerations about users with different forms of colour-blindness when proposing this change? How were they backed, was there a study, perhaps?

Comment 19

[Emilio Cobos Álvarez (:emilio)]

I'll put up a revert for review for now (I'm intermittently available this week).

Comment 20

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1951930 - Back out checked radio rendering change from bug 1941755. r=julian!

And add a comment pointing to this and related bugs.

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1951930 - Keep 1px outer border width tho. r=julian!

For consistency with the unchecked state.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ceea4f67721f
Back out checked radio rendering change from bug 1941755. r=Julian
https://hg.mozilla.org/integration/autoland/rev/52e03a45a5b1
Keep 1px outer border width tho. r=Julian

Comment 23

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/ceea4f67721f
https://hg.mozilla.org/mozilla-central/rev/52e03a45a5b1

Comment 24

[Eugene Savitsky]

It will be fixed only for 138. in two months? :-/

Comment 25

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9470995 [details]
Bug 1951930 - Back out checked radio rendering change from bug 1941755. r=julian!

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Reverts to pre-136 behavior
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial-ish change.
• String changes made/needed: none
• Is Android affected?: Yes

Comment 26

[Pascal Chevrel:pascalc]

Should we uplift both revisions? The uplift request is only for ceea4f67721f

Comment 27

[Emilio Cobos Álvarez (:emilio)]

Ugh, yeah... It used to be the case that bugzilla allowed you to set both at the same time :/

Comment 28

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/5e04c88b16e0
https://hg.mozilla.org/releases/mozilla-beta/rev/767d2cd0d4ec

Comment 29

[Julian Gaibler]

Hey again!
As you might’ve already seen, after some further discussion, we decided to mostly revert to the previous appearance of radio buttons.

As mentioned earlier, the goal of the change was to align with a more common appearance across operating systems. But, as many of you pointed out, that version didn’t work as well across different backgrounds by default; sorry about that! We appreciate you taking the time to report this and bring it to our attention.

On that note, I also want to kindly remind everyone that while this feedback is very welcome, there’s no need for exasperated or accusatory language. So for future discussions I'd encourage you to keep the conversation constructive and assume good intent. Thanks!

Comment 30

[Donal Meehan [:dmeehan]]

Comment on attachment 9470995 [details]
Bug 1951930 - Back out checked radio rendering change from bug 1941755. r=julian!

Approved for 136.0.2

Comment 31

[Donal Meehan [:dmeehan]]

Comment on attachment 9471097 [details]
Bug 1951930 - Keep 1px outer border width tho. r=julian!

Approved for 136.0.2

Comment 32

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/a6587465cde8
https://hg.mozilla.org/releases/mozilla-release/rev/cc386eacf361

Comment 33

[Peter Magyari (Desktop QA)]

Verified fixed on Nighty 138.0a1 (20250316213034) and Beta 137.0b6 (20250314092052).

Comment 34

[Peter Magyari (Desktop QA)]

Also verified fixed on Firefox 136.0.2 (20250317120031).