Bugzilla

 (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.

With 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 this "fixes" things for you.  However, if the background image here were an important part of the content, then it would 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 preserve images while still letting the user choose custom text/background-color & ensure that they'll be readable.

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.

 (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 this "fixes" things for you.  However, if the background image here were an important part of the content, then it would 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 preserve images while still letting the user choose custom text/background-color & ensure that they'll be readable.

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.

 (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 would 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 preserve images while still letting the user choose custom text/background-color & ensure that they'll be readable.

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.

 (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.

 (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).