Closed Bug 1762298 Opened 2 months ago Closed 2 months ago

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

Categories

(WebExtensions :: Themes, enhancement, P2)

Desktop
All
enhancement

Tracking

(firefox101 fixed)

RESOLVED FIXED
101 Branch
Tracking Status
firefox101 --- fixed

People

(Reporter: sdk, Assigned: emilio)

References

Details

Attachments

(2 files)

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.

Flags: needinfo?(emilio)
See Also: → 1435216

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?

Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(dao+bmo)

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.

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Flags: needinfo?(emilio)
Severity: -- → N/A
Priority: -- → P2
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(dao+bmo)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5f2dedfd64a6
Inherit used color-scheme from embedder <browser> elements. r=nika,dao,Gijs
Pushed by emilio@crisal.io:
https://hg.mozilla.org/integration/autoland/rev/e2ba788a9a87
GCC build bustage and reftest fixes.

(In reply to Pulsebot from comment #4)

Pushed by emilio@crisal.io:
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 :/

Flags: needinfo?(agi)
Regressions: 1763001
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
Regressions: 1763158

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

(In reply to Pulsebot from comment #4)

Pushed by emilio@crisal.io:
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.

Flags: needinfo?(agi)
You need to log in before you can comment on or make changes to this bug.