Affected versions:

Nightly 92.0a1 (2021-08-03)

Affected platforms:

 Windows 7/10/macOS

Preconditions:

Have High Contrast Black set

Steps to reproduce:

1. Go to about:preferences
2. Go to Privacy & Security

Expected result:

Enhanced Tracking Protection section text should be visible.

Actual result:

 Enhanced Tracking Protection section (Standard, Strict, Custom) text is not visible.

Regression range:

 This is a recent regression since Release 90.0.2 and Beta 91.0b9 are not affected (see comment 1). Will try to provide the regression range asap.

Thanks for CC'ing me :)
This is an issue on Mac as well, I'll attach a screenshot and change the platform.
STR:

• In System Preferences > Accessibility > Display > check increase contrast

@ Morgan, here is the pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=191e4bdf9e08fa81e2986e0a8664794b7ffa7e42&tochange=4a86d4975d4ec23847a36204422b8099d89fbd1b

Thanks!

Maybe the same issue here...as in the description issue, this also works ok in release 90 and beta 91.

Huh, yeah I'd be interested to know why we're using a white background on that text in HCM black -- the color is accurate (it should be white, given the settings at the OS level), but the text background is wrong. I'll investigate this a bit

Okay looks like the issue might be here, or at least, this is where browser toolbox takes me when I use the inspector and view the style properties: https://searchfox.org/mozilla-central/rev/4f05a46731c1f7f111ec7a41ce38a34594aa0d37/browser/themes/shared/preferences/preferences.inc.css#250

When we parse that, background-color gets set to rgba(0,0,0,0) for descriptions like this one https://searchfox.org/mozilla-central/rev/4f05a46731c1f7f111ec7a41ce38a34594aa0d37/browser/components/preferences/main.inc.xhtml#93

Interestingly, I can't reproduce the deceptive site warning issue on mac, but I can reproduce the preferences one(s)

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

Interestingly, I can't reproduce the deceptive site warning issue on mac, but I can reproduce the preferences one(s)

Indeed, I can't reproduce the deceptive site warning on mac either.

Managed to reproduce a similar issue on about:config page on Windows 10 on the latest Firefox Nightly, the issue is not reproducible on Firefox Release or on Beta

Hi, i get this issue on many other pages in MacOS 11 using high contrast mode with latest nightly

for example:

about:addons
about:config
about:memory
about:performance
about:telemetry
about:url-classifier

stuff looks like comment#10

Morgan, any chance this has been fixed by bug 1723938?

(In reply to :Gijs (he/him) from comment #13)

Morgan, any chance this has been fixed by bug 1723938?

I suspected it would've, but testing in today's nightly shows it hasn't :( Looks like this sort of a CSS issue, but maybe we could fix this in core also.

When we walk up to get our backplating color, we hit (privacy.css:116) where we pull the background color:

.content-blocking-category {
  border: 1px solid var(--in-content-box-border-color);
  background-color: rgba(215, 215, 219, 0.1);
}

and then, for some reason (?), interpret that as rgba(255, 255, 255, 0.1) which causes us to backplate white under white text, I assume because we don't do well with that alpha value.

We could fix this by maybe skipping alpha values when considering backplate colors, or by adding solid color backgrounds to these sections under a 'prefers-contrast' media query.

:emilio what do you think we should do here?

yeah I think this is part of the issue -- we remove the alpha val to get a solid color

https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/layout/generic/nsBlockFrame.cpp#243-246

but that's not really a "bug" persay, so maybe this should be fixed in CSS

:gijs, how does that sound to you? could we use different (solid) background colors for these sections when prefers-contrast is true?

Not sure. Might be worth trying to ignore colors with alpha < a threshold for the backplate, but that might get tricky.

But still that's not just it right? (though that'd fix this case)

background-color: red for example causes the same rendering, because the default background-color is white... But yeah that might be a bit trickier to get right. We might want to do something smarter here like reverting to color-contrast(currentcolor vs <default-background>, <default-color>), when we implement that?

ah seems like this is also, in part, due to bug 1709508

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

Not sure. Might be worth trying to ignore colors with alpha < a threshold for the backplate, but that might get tricky.
But still that's not just it right? (though that'd fix this case)

background-color: red for example causes the same rendering, because the default background-color is white...

Right, sorry I should've been clearer. I meant something like this:

.content-blocking-category {
  border: 1px solid var(--in-content-box-border-color);
}

@media not (prefers-contrast) {
  .content-blocking-category {
    background-color: rgba(215, 215, 219, 0.1);
  }
}

So we end up only using the alpha when we're not in HCM. When backplating, we'll iterate up to the page background and use that instead.

But yeah that might be a bit trickier to get right. We might want to do something smarter here like reverting to color-contrast(currentcolor vs <default-background>, <default-color>), when we implement that?

Yeah, I think this issue is maybe present in other places too -- like this youtube bug for example, which probably has an alpha value in the background color of the control bar, which is why the controls get a solid black backplate.

https://bugzilla.mozilla.org/show_bug.cgi?id=1718743

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

yeah I think this is part of the issue -- we remove the alpha val to get a solid color

https://searchfox.org/mozilla-central/rev/d3683dbb252506400c71256ef3994cdbdfb71ada/layout/generic/nsBlockFrame.cpp#243-246

but that's not really a "bug" persay, so maybe this should be fixed in CSS

:gijs, how does that sound to you? could we use different (solid) background colors for these sections when prefers-contrast is true?

If solid background colours were enough, we could replace the current CSS with using color-mix to effectively pre-multiply the current background colour with the (already solid) page background colour, using the relevant CSS variables? Then we can have CSS without special-casing prefers-contrast that works correctly for backplating, I think? Except from the comments from Emilio, it sounds like actually that won't help? :-(

Anyway, putting it behind a media query also sounds OK to me, though we'll need to come up with a way of indicating the selected box (blue-ish hue in non-HCM) if we're turning that rule off for HCM as well...

Probably the best way to do that is with border style (thicker border maybe?)
We do the same kind of color overriding for border color, though, so unfortunately we can't do it that way.

Actually, looking at this some more, I'm confused once again - I duped over bug 1725824, but that got reported against 91 (and the about:support info also indicates 91), but the regressing bug here is for 92... Does that mean it can't be a dupe, or is there some way to trigger this bug in 91? Morgan, do you know?

Hmm I'm not sure if that regressing bug is accurate -- my guess is bug 1713015 might be more accurate, since it made this more prevalent because HCM became "default on if on in the OS" in 91.
That said, I'm undoing that change in bug 1726606, so users will see less of this, though they can still enable FF HCM on mac in preferences.
Prior to the regressing bug that is currently tagged, system colors were always on (so I think we would've seen this even before that).

Its likely this has been around for awhile, but that we haven't tested FF HCM on MacOS often, so it only got caught when the two bugs above made it more common.

https://hg.mozilla.org/mozilla-central/rev/b7d27172ebfa

Comment on attachment 9237113 [details]
Bug 1723742 - make privacy pref pane highlights more high-contrast friendly, r?morgan

Beta/Release Uplift Approval Request

• User impact if declined: Please see comment 0
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial CSS fix
• String changes made/needed:

Verified - Fixed in latest Nightly 93.0a1 (2021-08-26) (build id: 20210826031555) using Windows 10 and macOS 10.15.

Actually, the issue is still there if the user switch between Strict and Custom sections.

:gijs looks like we're hitting the same issue with the sub-container, since it uses this mix logic:

  --section-highlight-background-color: color-mix(in srgb, var(--in-content-accent-color) 20%, transparent);

which creates a semi-transparent white that gets flattened to solid white with HCM on

I spun off a follow-up here: bug 1727785

Comment on attachment 9237113 [details]
Bug 1723742 - make privacy pref pane highlights more high-contrast friendly, r?morgan

Sounds like what landed is an improvement over the status quo. We can keep the follow-up bug on the radar as a ride-along for an RC respin or dot release down the road. Approved for 92.0b9.

https://hg.mozilla.org/releases/mozilla-beta/rev/09d83bcb7822

Verified - Fixed in Beta 92.0b9 (build id: 20210826192006) using Windows 10 and macOS 10.15. Still reproducible the issue from comment 28 and we will keep an eye on bug 1727785 for further verification.