1888866 - Addons options_ui browser_style false doesn't properly handle dark mode on macOS

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect, P3)

Description

[Jeff Johnson]

Attachment: manifest.json

Steps to reproduce:

1. Switch to dark mode on macOS
2. Load the attached add-on Dark Mode Bug in about:debugging#/runtime/this-firefox
3. Open about:addons
4. Selec Dark Mode Bug Preferences

Actual results:

The Preferences background is white rather than black, but the text is white and thus unreadable.

Expected results:

The Preferences background should be dark.

Comment 1

[Jeff Johnson]

Attachment: options.html

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Toolkit::Add-ons Manager' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Jeff Johnson]

Attachment: browser_style false.png

Comment 4

[Jeff Johnson]

Attachment: browser_style true.png

Comment 5

[Jeff Johnson]

I was told in https://bugzilla.mozilla.org/show_bug.cgi?id=1880107 to use browser_style false to fix a bug with the appearance of <hr> elements, but dark mode only works correctly with browser_style true.

Comment 6

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (126.0a1/20240402213900), Beta (125.0b7/20240401091600) and Release (124.0.1/20240321230221) under Windows 10 and macOS 11.3.1 using the attached extension.

With dark mode enabled, the options page of the extension has a white background and white text, making the text unreadable.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

Rob is going to take a closer look.

Comment 8

[Rob Wu [:robwu]]

When browser_style is true, the color is always #222426 and the background always transparent, which is effectively blank regardless of the dark/light theme selected through color-scheme. Note that other HTML (including the input) are rendered for theme, so ideally the outcome should be for the background to be dark and the color to be light.

When browser_style is false (which is the new default, and cannot be reverted in MV3), the color is CanvasText (black in light mode, blank in dark mode). The background is still transparent (the default), which is somehow blank, independently of the dark/light scheme.

The bug here is thus that the background is unconditionally blank, independently of the preferred color scheme. I'll submit a patch to fix the issue when browser_style:false is used.

The question is what to do when browser_style:true is used - continue using the fixed color, or drop the default color. In the interest of minimizing visual regressions, balanced against the intent when color-scheme: light dark is used, I think that we could put the color: #222426 declaration in a media query (prefers-color-scheme) to limit that color to when the light theme is selected, so that if an extension uses color-scheme: dark light, that the expected result happens without additional CSS hacks. An alternative is to fix the root's color to white unconditionally (instead of transparent) to have the result from before. While this would keep the behavior unchanged, it invalidates the expectation that developers have of color-scheme: dark.

Comment 9

[Rob Wu [:robwu]]

Attachment: Bug 1888866 - Improve dark theme support in options_ui

This patch changes the behavior for extensions with an embedded
options_ui page (open_in_tab not false), that have specified the
"dark" value in the "color-scheme" meta tag or CSS property, AND
with the user having indicated the preference for dark theme support.
There are no changes when any of these conditions have not been met.

The "color-scheme" CSS property is the standard way for extensions (web
pages in general) to opt in to automatic dark theme support, e.g. by
changing the foreground color to white. Prior this patch, the
background was unconditionally white, which resulted in unreadable text
when the dark theme is enabled. This patch changes the default
background color to "Canvas", which is a special keyword that is dark
theme-aware (almost black - rgb(28, 27, 34) by default).

When browser_style:true is used (which is the default in MV2),
extension.css is activated, which unconditionally specifies a black
foreground color. To avoid a poor contrast with the new theme-dependent
background color, the color is now white when the dark theme is enabled.

This patch includes comprehensive test coverage, but the only tests
whose behavior changed by this patch are:

• options_ui_dark (background changed)
• options_ui_browser_style_true_dark (color, background changed)

Comment 10

[Rob Wu [:robwu]]

dev-doc-needed (see comment 9 for details):

• add to release notes
• no BCD change needed
• Update Options_pages article at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/user_interface/Options_pages#specifying_the_options_page
  • Add <meta name="color-scheme" content="dark light"> to the head to demonstrate best practices of dark theme support.
  • Mention that it enables automatic dark theme support.
  • also update the code sample at https://github.com/mdn/webextensions-examples/tree/main/favourite-colour

Here is an example of <meta name="color-scheme" content="dark light"> in action: https://github.com/Rob--W/fosdem-2024-ext/blob/a98c24af4571b1d8a1b9b9d0689e70fec9bad0ca/code-samples/content_scripts.mv3%2Boptions_ui/options.html#L7
note that background: Canvas was specified there, to work around this bug. With this bug fixed, that work-around is no longer needed, and adding a meta tag is all that's needed to have automatic dark theme support working out of the box.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3504712be7dd
Improve dark theme support in options_ui r=willdurand,desktop-theme-reviewers,emilio

Comment 12

[Aron Cseh]

https://hg.mozilla.org/mozilla-central/rev/3504712be7dd

Comment 13

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

The patch landed in nightly and beta is affected.
:robwu, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox126 to wontfix.

For more information, please visit BugBot documentation.

Comment 14

[Alex Cornestean]

Verified as Fixed. Tested on the latest Nightly (127.0a1/20240418214121) under Windows 10 x64 and Ubuntu 22.04 LTS.

The preferences page background is now dark, and text is visible. See the attached screenshot.

Comment 15

[Alex Cornestean]

Attachment: 2024-04-19_09h29_15.png

Comment 16

[Richard Bloor]

Changes ready for review:

• MDNcontent Dark theme support in embedded options pages fix #35778
• example Automatic theme switching support in favorite colours #567