STR:

1. Change browser.proton.enabled = false.
2. Visit about:preferences.

Checkboxes are not themed correctly, they are too small and the enabled state cannot be distinguished from the disabled state.

Many users have disabled Proton and will not be able to make the connection between the checkboxes and the Proton setting.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e9b1ff2959608e83903589fafe1a0a5d808a04a5&tochange=e10dca5c585a517c66b29eb36979384e17ee7934

Regressed by Bug 1714462.

That's not a supported configuration, browser.proton.enabled was never meant to be supported in the long term. Bug 1714462 intentionally removed rules for non-Proton.

Unsupported configurations should be migrated gracefully rather than leaving the browser in a broken state, especially for such a high profile setting that received so much attention. Leaving all the users who changed this with a broken browser with no obvious connection to the cause is a problem.

(In reply to Kestrel from comment #2)

Unsupported configurations should be migrated gracefully rather than leaving the browser in a broken state, especially for such a high profile setting that received so much attention. Leaving all the users who changed this

We have telemetry on this, and the numbers are miniscule. Also, we did not purposefully draw attention to the pref. There was some confusion on SUMO, which was resolved. We're in the process of removing the remainder of the pref checks, which will resolve the issue, but we don't have time to try to beta-uplift extra work here for a configuration we don't support. Users should turn the pref back on to resolve the issue - it doesn't do what they want anymore on 91 anyway. If we flipped the pref for users, they would no doubt blame us for overwriting their settings when they then downgrade back to a version where the settings "work". There is no winning move here, other than not to play.

with a broken browser with no obvious connection to the cause is a problem.

I expect this particular issue might be fixed by bug 1703630 (which, despite the summary, also affects checkboxes). These are the rules in https://searchfox.org/mozilla-central/source/toolkit/themes/windows/global/checkbox.css#62, https://searchfox.org/mozilla-central/source/toolkit/themes/linux/global/checkbox.css#56 among others. Anyway, I don't think it's useful to track this separately.

Wouldn't renaming the pref be the normal course of action under these circumstances (eg to browser.proton.testing.enabled)? It neatly transitions users to a supported configuration without touching their prefs and recognizes that the setting now functions differently. This would seem to be a relatively straightforward patch and maintain goodwill with a critical segment of the user base.

(In reply to Kestrel from comment #4)

Wouldn't renaming the pref be the normal course of action under these circumstances (eg to browser.proton.testing.enabled)?

I'm not sure why you think this is "normal" - I don't recall us ever having done this before. We've renamed prefs that were intended for users to flip (e.g. ctrl tab prefs) where we're changing the default, in order to persist previous user choices, but that's not what's happening here - a choice is being removed, and the pref is becoming increasingly meaningless, until finally it will be removed altogether.

It neatly transitions users to a supported configuration without touching their prefs and recognizes that the setting now functions differently. This would seem to be a relatively straightforward patch

It's additional work (that, IMO, is not actually all that straightforward) on top of actually removing the code, and I don't think that it has value.

and maintain goodwill with a critical segment of the user base.

I don't think it's possible to maintain goodwill with people who yell at us at every opportunity, while also removing the thing they want (ie non-proton support), irrespective of what else we do.