1947430 - Sidebar background color lacks contrast with dark themes that rely on default colors

Status: NEW

(Firefox :: Sidebar, defect, P2)

Description

[Kestrel]

Attachment: Dark theme with low contrast light sidebar toolbar

STR:

1. Set sidebar.revamp = true.
2. Install a theme that triggers dark mode like MiincDesign_33 (15k users).

Expected:
Sidebar toolbar is white text on dark background like the sidebar content.

Actual:
Sidebar toolbar is white text on light background with low contrast. Vertical tabs also affected.

Bug 1899336 made the background transparent which was later fixed by Bug 1915805 but now it lacks contrast.

Other affected themes with the same regressor:
https://addons.mozilla.org/en-US/firefox/addon/green-tropical-leaves/ (9k users)
https://addons.mozilla.org/en-US/firefox/addon/classic-blue/ (5k users)
https://addons.mozilla.org/en-US/firefox/addon/blackswirlywater/ (4k users)
https://addons.mozilla.org/en-US/firefox/addon/northern-lights-fantasy/ (2k users)

All have white tab_background_text which triggers dark mode (browser.theme.toolbar-theme = 0).

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=73d37e644eb977c4205e20c6a349453f39e09ec4&tochange=f81bc4882ecc99d79404676fdcf3dd5b4355800f

Regressed by Bug 1899336.

Comment 1

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

:sclements, since you are the author of the regressor, bug 1899336, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Sarah Clements [:sclements]]

This is essentially a duplicate of bug 1947421 and as we've made clear in that bug and bug 1946450 its very difficult to use variables that will work perfectly for every single theme, especially user created themes. We'll need to figure out if there should be outreach with theme authors but we don't have time to prioritize that at the moment.

Comment 4

[Kestrel]

Unlike Bug 1947421, these themes are not doing anything wrong. For example MiincDesign_33 only changes two colors, leaving the rest as default:

{"theme": {"images": {"theme_frame": "Fractal33.jpg"}, "colors": {"frame": "#ffffff", "tab_background_text": "#ffffff"}}, "version": "2.0", "name": "MiincDesign_33", "manifest_version": 2}

The white tab_background_text is triggering dark mode (browser.theme.toolbar-theme = 0) which should be automatically making the sidebar background dark but this was broken by Bug 1899336 and the fix for it in Bug 1915805 does not appear to consider dark mode.

Every theme that triggers dark mode and relies on default colors for the sidebar background is affected.

Comment 5

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

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

Comment 6

[Sarah Clements [:sclements]]

(In reply to Kestrel from comment #4)

Unlike Bug 1947421, these themes are not doing anything wrong. For example MiincDesign_33 only changes two colors, leaving the rest as default:

{"theme": {"images": {"theme_frame": "Fractal33.jpg"}, "colors": {"frame": "#ffffff", "tab_background_text": "#ffffff"}}, "version": "2.0", "name": "MiincDesign_33", "manifest_version": 2}

The white tab_background_text is triggering dark mode (browser.theme.toolbar-theme = 0) which should be automatically making the sidebar background dark but this was broken by Bug 1899336 and the fix for it in Bug 1915805 does not appear to consider dark mode.

Every theme that triggers dark mode and relies on default colors for the sidebar background is affected.

Kestrel, please do not reset tags and move this - while it is a theme issue its primarily a sidebar issue and because of how the new sidebar has changed; if we had a quick fix we'd address it but it needs more assessment/analysis of the different options.

Comment 7

[Sam Foster [:sfoster] (he/him)]

I had a collection of manifests from some of the most popular extensions and did a little analysis on them to see how widespread an issue this might be. My methodology was to filter down to themes with manifest theme.colors.tab_background_text and theme.colors.frame properties. Then, using a standard algorithm to compare the luminance of the 2 colors I produced a contrast ratio for each.

I found that using a threshold of 4.5:1 (per the WCAG 2.1 recommendation) 64/323 i.e. 19.81% had low contrast. I did do a couple of spot-checks to verify these results. I installed each of the first few of the failures and confirmed they showed this bug. One was in the list above - green-tropical-leaves (wp8153887-green-plants-wallpapers). I spot checked a few of the "passes" such as "Activist - Balanced" which does not exhibit this bug and did not show up in the low-contrast list so I feel reasonably good about these results. If you dial down the passing threshold to 3:1, you get 51/323 or 15.79% which I think is still an uncomfortably large number.

Note that all but one of these failing themes included images so it seems reasonable to assume the colors were picked expecting the background image to provide the light/dark contrasting background to the foreground color. The fact we are unable to use these images in the sidebar launcher, but do use the toolbar colors leaves us with this issue.

I'm not sure what the best next steps are. Ultimately I expect the theme manifest will need to evolve as we want to provide a backwards-compatible way to allow theme authors to provide background images that can be used in the sidebar and mesh nicely with the toolbars above. But in the interim we have a lot of broken-looking themes. We could do the same contrast check and correct somehow at runtime. That's in the startup path though normally so we'd need to proceed carefully - and its not immediately obvious what the correction would be: do we just substitute in black or white for the tab_background_text property? Or is there perhaps another manifest property we can fall back to that would fit the theme's color palette better than just black/white and provide better contrast?

Comment 8

[Sarah Clements [:sclements]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #7)

I'm not sure what the best next steps are. Ultimately I expect the theme manifest will need to evolve as we want to provide a backwards-compatible way to allow theme authors to provide background images that can be used in the sidebar and mesh nicely with the toolbars above. But in the interim we have a lot of broken-looking themes. We could do the same contrast check and correct somehow at runtime. That's in the startup path though normally so we'd need to proceed carefully - and its not immediately obvious what the correction would be: do we just substitute in black or white for the tab_background_text property? Or is there perhaps another manifest property we can fall back to that would fit the theme's color palette better than just black/white and provide better contrast?

Substituting in black or white for tab_background_text seems the most straight forward and less bug-prone in the sense that we can't guarantee there will be sufficient contrast with other properties that we pick (since its the same issue ultimately as this where colors being used together weren't designed to be). Seems this would be worth trying as a first-pass attempt that we could iterate on as needed.

Comment 9

[Stuart Colville [:muffinresearch]]

Another consideration here is that whilst it's often frame vs text issues that show-up this way, it's worth also noting that when the new sidebar is enabled without vertical tabs, there's also the toolbar colours and icon colours when specified.

Comment 10

[Sam Foster [:sfoster] (he/him)]

Just some more notes as I'm picking through this: When vertical tabs are not enabled, only the top-most toolbar has the .browser-toolbox-background class applied. This applies a background-color which resolves to the frame color from the theme's manifest. If the theme has a background image, it is applied here so the frame color could be completely obscured if the image is opaque. The other toolbars and sidebar launcher get a the --toolbar-bgcolor. Technically its a background image overlaid which is a gradient:
background-image: linear-gradient(var(--toolbar-bgcolor), var(--toolbar-bgcolor)). ---toolbar-bgcolor is the toolbar color from the theme's manifest.

When we enable vertical tabs, the toolbar with the tabstrip is hidden, the tabs move to the sidebar and the topmost toolbar is now the nav-bar. It and the element that contains the sidebar launcher get the .browser-toolbox-background class. So all that stuff in the sidebar launcher - the tabs, the tools - get the frame color. Except in this context, we do not apply the background image so if there is low contrast between the frame and tab_background_text properties, the stuff in the launcher is hard or even impossible to see.

Re-running the analysis against the top 100 themes, differentiating between the vertical tabs and horizontal tabs case, the situation improves a little. 12% of the themes have below 4.5:1 contrast in the sidebar launcher when vertical tabs are enabled, 8% when using horizontal tabs. If we allow for 3:1 contrast, its 8% with vertical tabs enabled, 6% without.

Comment 11

[Stuart Colville [:muffinresearch]]

Sam, when you have a moment would you be able to estimate what it would take to provide a basic intervention for the most problematic contrast cases? This is so we can weigh up if when we might look to work on this.

Comment 12

[Rob Wu [:robwu]]

There is a request to add an addons-linter check for poor contrasts at https://github.com/mozilla/addons-linter/issues/5639

That work depends on there being a collection of theme property pairs where contrast matters. Such work would better be done and maintained on the Firefox side, such as this bug.