Previously we didn't support mac's native high contrast mode and so it made sense to set "override with system colors?" to "never". Currently, though, if you enable "Increased contrast" in MacOS System Prefs, you see no changes to Firefox because of the default option-- we should make it easier for users to benefit from FF HCM by enabling HCM when MacOS's Increase Contrast is checked.

Users can revert this option by navigating to about:preferences > Language and Appearance > Colors > set dropdown to "never" > OK

Backed out changeset 550fd06e9120 (Bug 1713015) for causing bc failures in browser_HCM_telemetry.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/c2684115028cad5f3834e099c6de068c8cb503d8
Push with failures, failure log.

https://hg.mozilla.org/mozilla-central/rev/52ed1b7f1fb0

Morgan, is that worth mentioning in our release notes? If you think it is, could you request an addition? Thanks!

https://wiki.mozilla.org/Release_Management/Release_Notes#How_to_decide_whether_a_change_should_be_included_in_release_notes.3F

Release Note Request (optional, but appreciated)
[Why is this notable]: We've had support for high contrast mode on Mac for a few releases now, but in order for users to benefit from our support, they had to have prior knowledge of FF's HCM preferences and know to enable HCM in the browser as well as the OS. Now, the browser will automatically enable HCM when it detects MacOS's system preference is set.
[Affects Firefox for Android]: No
[Suggested wording]: Firefox now automatically enables High Contrast Mode when "Increase Contrast" is checked on MacOS.
[Links (documentation, blog post, etc)]: N/A

Note added to nightly release notes, thanks.

This was in the 91 relnotes.

Looks like there is quite a number of users who are surprised by this change. Maybe there should have been a more explicit notification to the affected users.

Related: bug 1720012 (which is resolved fix for 92).

The standard high-contrast colors can be hard or impossible to distinguish, depending on eyesight, monitors, and accessibility software.

I had set alternate link colors which were easier for me to distinguish, high-contrast mode overrode my choices, the fix for bug 1720012 should allow user choice to override the standard high-contrast mode colors. So can you make sure updates to this bug don't override user choices again?

(In reply to MarjaE from comment #11)

Related: bug 1720012 (which is resolved fix for 92).

The standard high-contrast colors can be hard or impossible to distinguish, depending on eyesight, monitors, and accessibility software.

I had set alternate link colors which were easier for me to distinguish, high-contrast mode overrode my choices, the fix for bug 1720012 should allow user choice to override the standard high-contrast mode colors. So can you make sure updates to this bug don't override user choices again?

Hi MarjaE, are you seeing changes to your local config that were disrupted by changes here, or to bug 1726606?
Neither should've affected your local choices for active or visited link color, unless you've also checked "use system colors".

They were disrupted by bug bug 1691793.

I have not checked "Use System Colors" and have had to turn off "Increase Contrast" system-wide because it causes trouble in many other apps. e.g. it turns black text on certain light backgrounds into white text on the same backgrounds.

(In reply to MarjaE from comment #13)

They were disrupted by bug bug 1691793.

I have not checked "Use System Colors" and have had to turn off "Increase Contrast" system-wide because it causes trouble in many other apps. e.g. it turns black text on certain light backgrounds into white text on the same backgrounds.

Have you updated to the most recent version of firefox? (91.0.2)
In my testing locally, I can't reproduce a scenerio where enabling Increase Contrast changes my custom colors -- do you have steps to reproduce? That's definitely not expected behaviour, so it's important to fix if we can track down how it happens.

Yes.

For instructions, see the other bug https://bugzilla.mozilla.org/show_bug.cgi?id=1720012#c10

That's supposed to be fixed in version 92.

I just wanted to cross-reference these bugs so that fixes to each wouldn't break the other.