1755713 - [Windows] White artifacts on icons using high contrast with dark theme

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Sarah Clements [:sclements]]

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

Comment 1

[Adrian Florinescu [:aflorinescu]]

Attachment: w10-youtube.jpg

99.0a1 2022.02.17 / Windows 10

Comment 2

[Adrian Florinescu [:aflorinescu]]

Attachment: w10-addons.jpg

Comment 3

[Adrian Florinescu [:aflorinescu]]

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

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

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

[Petruta Horea [:phorea], Desktop Test Engineering (back on Sep 5th)]

Attachment: Win7 HCM

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

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Sarah Clements [:sclements]]

Attachment: Bug 1755713 - Fix background color on buttons in Windows HCM and dark theme r=emilio

Comment 8

[Sarah Clements [:sclements]]

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

Comment 9

[Sarah Clements [:sclements]]

Attachment: Screen Shot 2022-03-17 at 4.01.02 PM.png

Comment 10

[Sarah Clements [:sclements]]

Attachment: Screen Shot 2022-03-17 at 3.59.54 PM.png

Comment 11

[Emilio Cobos Álvarez (:emilio)]

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

[Morgan Reschenberg [:morgan]]

I agree with Emilio.
Also, I'm a little confused about the "artifacts" this bug refers to -- what are they?

Comment 13

[Emilio Cobos Álvarez (:emilio)]

I just took a look and the button "artifacts" (which I suspect are just the extra backgrounds) are basically bug 1666059.

Comment 14

[Sarah Clements [:sclements]]

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

Comment 15

[Sarah Clements [:sclements]]

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

Comment 16

[Emilio Cobos Álvarez (:emilio)]

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

[Emilio Cobos Álvarez (:emilio)]

Attachment: Screenshot of such a setup on Windows, comparing with Edge.

Edge is respecting the background-color: transparent. So does Windows in a bunch of places, causing contrast issues.

Comment 18

[Sarah Clements [:sclements]]

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?

Comment 19

[Emilio Cobos Álvarez (:emilio)]

(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

Comment 20

[Sarah Clements [:sclements]]

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

[Emilio Cobos Álvarez (:emilio)]

Grr, yes, that was a bug in my patch for bug 1666059, thanks! Added a better (and simpler, too) test.

Comment 22

[Sarah Clements [:sclements]]

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

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1625036

Comment 24

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

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.