User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Turned on "increase contrast" in MacOS Accessibility Menu.

Actual results:

Firefox completely shit the bed and has high contrast boxes everywhere, including UI elements / text that is totally invisible.

Expected results:

Nothing

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Workaround
Click the "Colors..." button in Preferences> General> Fonts & Colors.
Set from "Only with High Contrast themes" to "Never".

Before Firefox 91, the initial value of the above settings seems to be "Never".

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

Stephen can you take a look / triage this?

Reclassifying under the a11y component -- this is just a bug about High Contrast Mode looking not-great, and there isn't really any mac/cocoa-specific issue here, other than the fact that we recently started to auto-enable HCM mode on Mac-for-users-with-increased-contrast-system-preference (with an opt-out as noted in comment 2).

The attached screenshot is just the Google sign-in page, with high-contrast-mode turned on. The black sidebars do definitely look weird, but they're there for a reason -- Google is using transparent-borders for layout there, via this CSS (which sets 24px transparent borders on the left and right):

.Us7fWe {
    border: 0 solid transparent;
    border-width: 0 24px;
}

...and Firefox's HCM mode forces borders to be the user's chosen foreground color.

This is annoying, but it's an expected outcome of "forced colors" mode - borders and text all are forced to be the user's chosen foreground color (black in this case). We might want to reach out to Google to see if they can avoid using transparent borders here, since they have this unfortunate effect of showing-up (against Google's intent) in this configuration.

So we tweaked the default for GTK because light high-contrast-themes on GTK caused issues (see also bug 1623938).

Perhaps we should do the same on macOS since IME very few people know of the "override document colors" setting, and if things look broken and you don't know how to fix it you just change browsers.

WDYT Morgan? It seems Safari also doesn't do anything special with "increase contrast" on macOS, so it's perhaps a more sensible default, to let users use HCM if they opt into it on macOS.

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

So we tweaked the default for GTK because light high-contrast-themes on GTK caused issues (see also bug 1623938).

Perhaps we should do the same on macOS since IME very few people know of the "override document colors" setting, and if things look broken and you don't know how to fix it you just change browsers.

WDYT Morgan? It seems Safari also doesn't do anything special with "increase contrast" on macOS, so it's perhaps a more sensible default, to let users use HCM if they opt into it on macOS.

Yeah, agreed. We had an a11y meeting about this yesterday -- I think maybe eventually we'll go back to offering HCM with increase contrast, but for now it seems to be more of a hindrance than a help in terms of what users expect FF to do. Reading through user feedback, its also really apparent that the colors dialog is confusing. Users don't understand that that dialog is where they should look to change HCM settings, and they don't correlate the dropdown in that dialog to having any effect on the changes they see on screen. So, discoverability is low, and so is the intuitiveness of that pref in the first place. I think I'll try to spend some time figuring out how to re-work that, and maybe revisiting having an accessibility preferences section...

Anyway, for now I'm going to try to do a remote pref flip in release, and then land/uplift a reverting patch for beta and nightly. I'll r?you on the patch :)