[Windows] White artifacts on icons using high contrast with dark theme
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
Accessibility Severity | s4 |
People
(Reporter: sclements, Unassigned)
References
(Regression)
Details
(Keywords: access, regression, Whiteboard: [fidefe-quality-foundation] )
Attachments
(6 files, 1 obsolete file)
(Spinning out the Windows portion of bug 1718743 into its own, since the Mac issue has been resolved.)
Affected versions
Looks to be all versions starting from Nightly 91.0a1 (Build ID: 20210629214925)
Affected platforms
Windows
Steps to reproduce
Start Firefox.
Enable dark theme on OS level.
Enable dark theme for Firefox.
Enable High Contrast.
Visit www.youtube.com and select a video.
Visit the about:addons page
Expected result
There are no visual artifacts on dark mode with High Contrast.
Actual result
There are several white visual artifacts on icons.
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Comment 3•3 years ago
|
||
I'm uncertain if W11 or W7 are of any concern in relationship to this particular bug. Maybe wouldn't hurt to at least know what the status is for these platforms, although I don't know if we can set these coment 0 prerequisites on them.
Vlad (W11), Petrutat(W7) could you please take a look?
Comment 4•3 years ago
|
||
Hello,
I can confirm the faulty behavior on Youtube.com with 99.0a1 (2022-02-17) and Windows 11(OS Build 22543.1000) using all the High Contrast flavors except Night Sky(Aquatic, Desert, Dusk).
However this issue does not seem to reproduce in about:addons for none of the high contrast themes in this OS.
Screenshot of issue: https://photos.app.goo.gl/5keejV45PLVZSriDA
Comment 5•3 years ago
|
||
I have the same results on latest Nightly 99.0a1 under Win 7 32-bit. The issue is reproducible on all HCM themes for youtube.com and about:addons is the same as in the attachment uploaded by Adrian.
Comment 6•3 years ago
|
||
The severity field is not set for this bug.
:dao, could you have a look please?
For more information, please visit auto_nag documentation.
Reporter | ||
Comment 7•3 years ago
|
||
Reporter | ||
Comment 8•3 years ago
|
||
I wasn't able to narrow down exactly what caused this regression, since it went too far back in time (I got a range of revisions on March 30, 2000), so after looking through those and trying to understand if any affected this, I thought to try out what ended up fixing the problem for mac (per here). So I basically copied :morgan's patch, applying it to Windows and.... it fixes the black mask around the buttons (the arrow buttons in the above screenshots are anchor tags, not buttons, interestingly). However, if there's some reason I shouldn't fix the problem this way, I'm open to another approach.
Did a manual test on Windows 11 for youtube and html5 video, and the buttons look fine in HCM and dark themes (OS and Firefox).
Reporter | ||
Comment 9•3 years ago
|
||
Reporter | ||
Comment 10•3 years ago
|
||
Comment 11•3 years ago
|
||
I mean, this would disable forced colors on HCM on windows by default. Which I'm not sure we want to do. This all seems intentional behavior? Or what am I missing? Users that use HCM and don't want this can go to the "manage colors" dialog.
How does edge behave here? Depending on what the page is doing behavior here could be different between us and edge, but backplating the video progress and so on seems expected.
Comment 12•3 years ago
|
||
I agree with Emilio.
Also, I'm a little confused about the "artifacts" this bug refers to -- what are they?
Comment 13•3 years ago
|
||
I just took a look and the button "artifacts" (which I suspect are just the extra backgrounds) are basically bug 1666059.
Reporter | ||
Comment 14•3 years ago
|
||
If you look at the video control buttons here https://bugzilla.mozilla.org/show_bug.cgi?id=1755713#c5, you can see a black mask around these buttons which only happens on Windows, HCM in black theme. Those button have a background-color: transparent
property set, with svgs, yet somehow its being rendered with black (the reason why the next and back buttons don't have that is because they are anchor tags with button roles).
It sounds like disabling this pref isn't desired here - emilio can you give me a bit more context on why (I'm new to the code base and FE team) and some guidance on what would a better solution? It looks like its a similar issue to bug 1625036. I'm also curious why removing this particular pref actually works (even though it sounds like isn't desired).
Reporter | ||
Comment 15•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)
How does edge behave here? Depending on what the page is doing behavior here could be different between us and edge, but backplating the video progress and so on seems expected.
I don't see this issue on edge on Windows 11. So backplating is... how we determine what image/color to use when a specific elements, like buttons, have a background-color: transparent
property?
Reporter | ||
Updated•3 years ago
|
Comment 16•3 years ago
|
||
So there are two different mechanisms involved here: Forced colors and backplating. Backplating you can turn off or on with browser.display.permit_backplate
. That's not the mechanism involved here.
The main issue is that, when forcing colors, we effectively end up here, which ends up turning background-color: transparent
into background-color: revert
. That is so that we can guarantee that the color matches the one we force and we don't get situations like bug
However, in a setup like the one from that bug (with black background, light text color, but then light button background, but black button text color), even windows native titlebars lack contrast, see incoming screenshot. So I think we should just fix bug 1666059 to align with Edge here, which will fix this too.
Comment 17•3 years ago
|
||
Edge is respecting the background-color: transparent
. So does Windows in a bunch of places, causing contrast issues.
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Comment 18•3 years ago
|
||
Ah I see, thanks for explaining. So once you change how the background-color is being determined when in force color mode, it will still technically not be great for people wanting (and using) HCM on Windows but then in that case they can override that and force their own contrasting colors?
Reporter | ||
Updated•3 years ago
|
Comment 19•3 years ago
|
||
(In reply to Sarah Clements [:sclements] from comment #18)
Ah I see, thanks for explaining. So once you change how the background-color is being determined when in force color mode, it will still technically not be great for people wanting (and using) HCM on Windows
Not be great in what sense?
but then in that case they can override that and force their own contrasting colors?
Yeah, they can already do that if they want via the colors dialog in about:preferences.
The dark backgrounds here should be gone after bug 1666059
Reporter | ||
Comment 20•3 years ago
|
||
hrm, I'm still seeing this on Windows 11. I ran it locally (on mc tip, using artifact mode) and I checked the latest Nightly. Did you test this on a different version of Windows Emilio?
Comment 21•3 years ago
|
||
Grr, yes, that was a bug in my patch for bug 1666059, thanks! Added a better (and simpler, too) test.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Comment 22•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #21)
Grr, yes, that was a bug in my patch for bug 1666059, thanks! Added a better (and simpler, too) test.
This looks good now, thanks!
Updated•3 years ago
|
Comment 23•3 years ago
|
||
Set release status flags based on info from the regressing bug 1625036
Updated•3 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Comment 24•2 years ago
|
||
I managed to reproduce this issue on Firefox 98.0(20220304153049) on Win10 64-bits using Dark Mode enabled at OS and Browser level+ HC Black. Verified as fixed on Firefox 100.0(20220425210429) and Nightly 101.0a1(20220425213655) on Win10 64-bits and Win 11.
Updated•1 year ago
|
Description
•