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

Steps to reproduce:

Last changes for Win High Contrast are bad - I cannot see text on buttons any more because of white given background
Windows 10 is set to high contrast. I go for a specific webpanel of freshdesk.com, but not only this one.

Actual results:

Instead of white text on black background, I get text on white background which is incorrect for visually impaired high contrast users. All backgrounds should be black.

Expected results:

Text should be white as marked in FF options and Win High Contrast mode and background should be always black as marked in FF options and Win High Contrast mode.

You can enter about:config into the address bar and set browser.display.permit_backplate to false.

Thank you so much - it is working perfectly. Is it possible to have a similar workaround for Google Sheets? During loading the sheet, the columns and rows are black (in high contrast mode), Than after loading it is white, so not accessible for visually impaired person with high contrast mode. Can there be also a workaround for this in FireFox config?

(In reply to Mike from comment #2)

Thank you so much - it is working perfectly.

You're welcome.

Is it possible to have a similar workaround for Google Sheets?

1. Please test in the latest Nightly. If the problem is gone, it was probably fixed by bug 1614921.
2. If the problem persists, file a new bug report and attach a screenshot of the problem with browser.display.permit_backplate at its default value, and another screenshot with that preference set to false.
3. Post the link to the bug report here.

Thank you - Nightly isn't helping. No matter if browser.display.permit_backplate is true or false. Checked also in FireFox and FireFox Nightly.
I've submitted a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1617199

CC Morgan for the readability backplate issue.

This seems basically the same issue as bug 1616440... That page is using gradients. We should probably keep forbidding gradients and just allow background-image instead or such...

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

This seems basically the same issue as bug 1616440... That page is using gradients. We should probably keep forbidding gradients and just allow background-image instead or such...

was just about to add this :) google.com reproduces the same issue. strangely, even though the buttons on google.com aren't <button> (they're <div> with <a>'s inside, ugh) they get the windows HCM styling for buttons..? maybe I'm missing something

anyway: why do we allow image backgrounds on buttons (maybe other form controls too?) in HCM? does that sound like something we should change?

(In reply to Morgan Reschenberg [:morgan] from comment #7)

was just about to add this :) google.com reproduces the same issue. strangely, even though the buttons on google.com aren't <button> (they're <div> with <a>'s inside, ugh) they get the windows HCM styling for buttons..? maybe I'm missing something

Not sure which buttons are you talking about in particular, but chances are that they just happen to be similar.

anyway: why do we allow image backgrounds on buttons (maybe other form controls too?) in HCM? does that sound like something we should change?

Well, we allow image backgrounds everywhere when backplating. We could disallow them only for some elements, but that seems a bit of a whack a mole. That also doesn't solve the other bug where the thing that has the gradient background is just a <div>...

Please, revert to not enabling backgrounds, backplates and gradients in color override mode.
Isn't it just the easiest solution?
Visually impaired persons like me really suffer a lot from such color changes.
Thank you very much!

This should've been fixed by bug 1617678, as far as I can tell.