Closed Bug 1707653 Opened 3 years ago Closed 3 years ago

background-image on the body makes overridden background invisible, when turning on the preference for "Override the colors specified by the page"

Categories

(Core :: Layout, defect)

Firefox 87
defect

Tracking

()

VERIFIED WONTFIX

People

(Reporter: jason.vas.dias, Unassigned)

References

(Regression)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

Browse sites like 'https://www.msys2.org/', which specify CSS:
:root { background : ... }
, when my Preferences->Colours->
'Override the colours specified by the page with your selections above' setting is 'ALWAYS', and I have specified my preferred 'Text' (white) & 'Background' (dark grey) colors (and my Linux Desktop is using a Dark theme).

Actual results:

Only the \<BODY> & \<P> text appears in my chosen colors (white on dark grey), in a narrow centered box, with the rest of the whole page appearing in the website specified background color (white) , which looks awful.

Expected results:

Both the :root (default 'rest of whole page' background color), and the 'color' and 'background' of all BODY / P elements within it, should be rendered in my
chosen Text and Background colors, since I have selected Override = ALWAYS .

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

Component: Untriaged → Preferences

It looks like the preference selector is working, so it's the underlying behaviour of the preference that might be broken. Putting into the Core :: Layout bucket, since I think this is layout/style/PreferenceSheet.cpp stuff.

Component: Preferences → Layout
Product: Firefox → Core

This is because that page has:

body { background: transparent url(body-bg.png) 0 0 repeat }

So it's a background image, which we started preserving when Morgan implemented backplating. Using browser.display.permit_backplate=false should "fix" this, but there's lots of pages which use background-images for actual content.

Summary: :root css pseudo-class colors override Preferences->Colors->'Overrride ...'==ALWAYS → background-image on the body makes overridden background invisible.

Aha! Yes, thanks, setting 'browser.display.permit_backplate=false' did fix this issue.
But since I'd set Preferences->Colors->'Overrride ...'==ALWAYS , I'd suggest making
this change automatically for users when they select Colors->'Overrride ...'==ALWAYS.

Severity: -- → S3
Summary: background-image on the body makes overridden background invisible. → background-image on the body makes overridden background invisible, when turning on the preference for "Override the colors specified by the page"

(In reply to JVD from comment #4)

Aha! Yes, thanks, setting 'browser.display.permit_backplate=false' did fix this issue.
But since I'd set Preferences->Colors->'Overrride ...'==ALWAYS , I'd suggest making
this change automatically for users when they select Colors->'Overrride ...'==ALWAYS.

Actually, this permit_backplate pref is intended to make things better when users have colors overridden. So we're not going to default it to off when users opt into overridden colors.

If you manually set the pref set to false, we have to turn off background images entirely when the user enables forced-colors mode, because we don't know what color(s) the image will have, and we don't know if the user's chosen text-color will be readable over the image.

In your particular case with this particular website, you happen to like the image being turned off :) which is why setting the pref "fixes" things for you. However, if the background image here were an important part of the content, then it could be pretty-bad that we turned off the background image.

With the pref set to true (the default), we draw a backplate between the text and the image, which ensures that the text will always be displayed over the user's chosen background-color and will remain readable. The backplates don't always look super-pretty, but they're a compromise that lets us paint background images while still letting the user choose their own custom text/background-color & ensure that text will be readable regardless of how the user's chosen text-color looks over the web developer's chosen background images.

So: I think this is things behaving-as-expected, basically, and the unwanted results are just a cosmetically-not-great outcome from the fact that this particular page happens to use a solid-color background-image (which we dutifully preserve and draw backplates over, which looks not-great but keeps things readable while still letting us draw the image).

I don't know that we have any good way to avoid this outcome; it's an inevitable consequence of the backplate feature (which is a feature that on the whole makes things better for users & lets us avoid hiding potentially-important content & lets us keep text readable).

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX

If you're curious, there's a bit more info about the backplate feature here:
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/HighContrast/explainer.md#ensuring-readability

(And the bug that added this feature to Firefox was https://bugzilla.mozilla.org/show_bug.cgi?id=1539212 )

Status: RESOLVED → VERIFIED
Regressed by: 1539212
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.