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

Steps to reproduce:

Enabled High Contrast Black

Opened URL https://en.wikipedia.org/wiki/Tungsten#Isotopes

Actual results:

Had trouble with page because I am light sensitive and there's a nearly-white bar across the top

Expected results:

CSS adding white bar should have been ignored. CSS is:

background-image: linear-gradient(to bottom,#ffffff 50%,#f6f6f6 100%);

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
20200218213359

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

(In reply to jhudson from comment #0)

Opened URL https://en.wikipedia.org/wiki/Tungsten#Isotopes

The problem is at the top of the page, not anywhere near that section.

background-image: linear-gradient(to bottom,#ffffff 50%,#f6f6f6 100%);

Applied to #mw-page-base

Maybe we should only allow url images in HCM when backplating? Or we should override the gradient stop colors? (that seems hard...)

The expected behavior is URL images don't work either, which is also the ESR behavior.

@jhudson, thank you for reporting this!

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

Maybe we should only allow url images in HCM when backplating? Or we should override the gradient stop colors? (that seems hard...)

Hmm maybe. Lemme talk with asa and team a bit more. Feels like there are two HCM use cases, and we might be conflating them (using HCM for contrast vs. using HCM because of light sensitivity, and the "both" case).

(In reply to jhudson from comment #3)

The expected behavior is URL images don't work either, which is also the ESR behavior.

Well, you can go back to the ESR behavior toggling browser.display.permit_backplate.

As far as I understand it, all the backplating shenanigans were done effectively so that images and background images could show up without hurting readability.

My analysis says they flow into each other. Consider:

<DIV STYLE="background-image: linear-gradient(to bottom,#ffffff 50%,#f6f6f6 100%);">Text here</DIV>

If you don't ignore the background, and HCM is on with its defaults (which are black background and white text), you're broken. I suppose the code could be trying to be fancy ...

I read up on the new term "backplate" and think I understand what's going on here. You are quite right, somebody missed the light sensitivity effect and only considered readability.

I'm actually surprised showing background images just drawing solid text works at all. This causes the background images to be much brighter than the content whenever the background image is nearly white. I can't imagine how this is readable for most people.

(In reply to jhudson from comment #3)

The expected behavior is URL images don't work either

Bug 1266172 asks for the exact opposite.

Alas. You can always get somebody asking for something bad. https://en.wikipedia.org/wiki/Photophobia

I have considered this in more detail. Applying the gradients in HCM is probably pointless.

Applying background images and then rectangles behind text kind of works, and fixes some sites with buggy CSS spritesheets; unfortunately this breaks other sites very badly, and I find that pushing the configuration I must use into an extremely rare config will lead to nobody testing against it anymore and the breakage becoming much worse.

I have too much trouble already with sites that think they can provide a dark theme and their job is done, neglecting the white flash on page load which cannot be suppressed by code on the website at all.

I think this should be fixed with bug 1617678? Morgan should we dupe this?

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

I think this should be fixed with bug 1617678? Morgan should we dupe this?

yes! thanks for checking! :)

(first time posting on Bugzilla)
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
Windows High Contrast Black system theme, Firefox set to use system colors (both always & only with high contrast)

Firefox has the best implementation of Windows High Contrast Black-- someone mentioned photophobia-- here's is one of those cases. Even with the current background issue, its still good except for sites with large div's with linear-gradient backgrounds-- those sites are now unreadable. Windows High Contrast Black is the only way I can still use my computer without having to resort to screen readers-- I still develop html and browser based apps thanks to Firefox's implementation of High Contrast Black system theme.

It isn't just div linear backgrounds-- it is anything that accepts linear gradient backgrounds such as buttons. On Google and Github pages, buttons are now colored. Checking the buttons with DevTools (which is a whole other issue because it doesn't apply system theme like the browser does with settings and web pages which makes it almost impossible to use because of its low contrast)--

but with DevTools, disabling the linear-gradient & background-image returned the buttons back to black backgrounds.

Possibly related: the text entry field of the browser's bottom search bar (that appears with shortcut Contrl+F) is now white when it was black. Fortunately it turns black when text is entered. Text itself (not its container element) have black backgrounds that cannot be made transparent.

People may already be aware of this, but here's an excellent reference/demo of what Windows High contrast themes does to CSS. https://codepen.io/tigt/pen/wORmqX