Add ability to get the prefers-color-scheme of the chrome in an addon
Categories
(WebExtensions :: Themes, enhancement, P2)
Tracking
(firefox101 fixed)
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:
-
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 theprefers-color-scheme
of the content
for anything else.There's some drawbacks with this solution because we have to decide what and
when theprefers-color-scheme
should be the chrome or content one. -
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.
Assignee | ||
Comment 1•2 months ago
•
|
||
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 usedcolor-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?
Assignee | ||
Comment 2•2 months ago
|
||
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.
Updated•2 months ago
|
Assignee | ||
Updated•2 months ago
|
Updated•2 months ago
|
Assignee | ||
Updated•2 months ago
|
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.
Assignee | ||
Comment 5•2 months ago
|
||
(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 :/
Comment 6•2 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/5f2dedfd64a6
https://hg.mozilla.org/mozilla-central/rev/e2ba788a9a87
(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.
Description
•