1762298 - Add ability to get the prefers-color-scheme of the chrome in an addon

Status: RESOLVED FIXED

(WebExtensions :: Themes, enhancement, P2)

Description

[Danny Colin [:sdk]]

Attachment: Dark chrome with light content.

Context:

I'm currently using the following code to detect the prefers-color-scheme
value for the user theme in Firefox and set the theme of my browserAction popup
accordingly.

getTheme(currentTheme, window) {
  if (typeof currentTheme !== "undefined" && currentTheme !== "auto") {
    return currentTheme;
  }
  if (window.matchMedia("(prefers-color-scheme: dark)").matches) {
    return "dark";
  }
  return "light";
}

This has some shortcomings because:

a. The prefers-color-scheme value returned by my code is only the one for the
content.
b. The user can set a different prefers-color-scheme for the chrome (UI) and
the content (webpage area)

For example, if the user has a dark theme for the chrome but a light theme for
the content, my addon popup will use a light theme instead of a dark theme. This
creates a UX inconsistency because one could consider that the popup is part of
the chrome and not the content. (See screenshot)

Solution:

1. Firefox should expose the prefers-color-scheme value of the chrome
   for elements like the browserAction popup, sidebar and other things that are
   linked to the chrome while exposing the prefers-color-scheme of the content
   for anything else.

   There's some drawbacks with this solution because we have to decide what and
   when the prefers-color-scheme should be the chrome or content one.

2. We expose both values in the Theming API and let the addon developer decide
   when and where to use it.

/cc :emilio which who I talked about this on #developer:mozilla.org and is definitely more knowledgeable than me.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

The only reasonable solution is 1, IMO. Dao, Gijs, here's a proposal:

The prefers-color-scheme of a page (and all its subframes) loaded in a <browser> element depends on the used color-scheme property value of that <browser> element.

That should do the right thing by default, and for the tabs the front-end would have:

#tabbrowser-tabpanels {
  color-scheme: light;
}
@media (-moz-content-prefers-color-scheme: dark) {
  #tabbrowser-tabpanels {
    color-scheme: dark;
  }
}

Or something of that sort. That way the front-end is effectively in control of the prefers-color-scheme values of ~everything. That means popups and sidebars get consistent prefers-color-scheme values, too. What do you think?

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1762298 - Inherit used color-scheme from embedder <browser> elements. r=nika!,dao!,Gijs!

This allows popups and sidebars to use the chrome preferred
color-scheme.

This moves the responsibility of setting the content-preferred color
scheme to the appropriate browsers to the front-end (via tabs.css).

We still return the PreferredColorSchemeForContent() when there's no
pres context (e.g., for display:none in-process iframes). We could
potentially move a bunch of the pres-context data to the document
instead, but that should be acceptable IMO as for general web content
there's no behavior change in any case.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5f2dedfd64a6
Inherit used color-scheme from embedder <browser> elements. r=nika,dao,Gijs

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e2ba788a9a87
GCC build bustage and reftest fixes.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

(In reply to Pulsebot from comment #4)

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e2ba788a9a87
GCC build bustage and reftest fixes.

Agi, can you sanity-check the geckoview.js change here? I needed it because some mochitests expect that pref to have an effect, and now it does only if the browser element opts into it. It's not changing any user/geckoview-consumer-visible behavior otherwise.

Mach try auto didn't catch that before landing unfortunately :/

Comment 6

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/5f2dedfd64a6
https://hg.mozilla.org/mozilla-central/rev/e2ba788a9a87

Comment 7

[[ex-Mozilla] Agi Sferro | :agi]

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

(In reply to Pulsebot from comment #4)

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e2ba788a9a87
GCC build bustage and reftest fixes.

Agi, can you sanity-check the geckoview.js change here? I needed it because some mochitests expect that pref to have an effect, and now it does only if the browser element opts into it. It's not changing any user/geckoview-consumer-visible behavior otherwise.

Mach try auto didn't catch that before landing unfortunately :/

That looks OK. Do we want to have this in all tab chrome browsers? That's what your patch is doing. From what I understand that should be equivalent to your change in tabs.css for Desktop.

Comment 8

[i73hi64d0wr5df8pckig]

Welp, this breaking change makes the firefox's behavior different from that of Chrome. I think existing users of prefers-color-scheme shouldn't be forced to adopt new code. Instead addons looking for a new behavior as described in OP should be using a new code -moz-chrome-prefers-color-scheme. Supporting a browser with 3.3% market share is getting harder and harder...

Comment 9

[i73hi64d0wr5df8pckig]

How am I supposed to style addon popup to match that of color scheme preferred by contents?
It appears that -moz-chrome-prefers-color-scheme is not understood at least in Firefox 103.
In addon popup, matchMedia('(-moz-content-prefers-color-scheme: dark)') returns "not all", and env(-moz-content-prefers-color-scheme,FALLBACK) always get computed to FALLBACK.

It looks like a bug on the implementation of -moz-content-prefers-color-scheme that it is not exposed in addon popups as well as in contents.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Can you elaborate what the use case is for having an addon popup not follow the chrome color-scheme?

Comment 11

[i73hi64d0wr5df8pckig]

My addon both has both a popup and an options page. Both are supposed to look unified. In particular, both pages are styled using similar color palette.

If users are using dark theme for chrome but light theme for contents, users will see light theme on options page but dark themes in popup page, breaking a unified look and creating UX inconsistency. Moreover, users using both Firefox and Chrome will have unexpected experience, because AFAIK in chrome, extension popup and content always have the same prefered-color-scheme.

IMO, the screenshot of the OP looks completely natural because the popup blends into the content area, not to the chrome area.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

That's not true, no other native popup behaves that way, so the current behavior in the case you're describing (dark popup, light options) is the expected one.

Comment 13

[i73hi64d0wr5df8pckig]

That depends on your view on what is "expected". Addon popups are not native, so I don't see a problem with it having a different behavior.

In Chrome, even if the chrome is styled in using mostly black colors, native popups are still styled using OS's prefered dark theme, which means Chrome devs will disagree with that view.

Moreover the change landed with this issue is a breaking change for users having dark chrome and light contents. It would be nice if there is a way to restore the old behavior by some new media queries so that users don't get surprised.