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

[Agi Sferro | :agi | [slow ni? rn sorry] | ⏰ PST | he/him]

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