1595037 - Prefers-color-scheme not updated unless Firefox is restarted on GNOME

Status: RESOLVED DUPLICATE of bug 1560660

(Core :: Widget: Gtk, defect)

Description

[rugk]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

const dark = window.matchMedia("(prefers-color-scheme: dark)");
function test(darkQuery){
    console.log(darkQuery);
}

dark.addListener(test);

or, even easier, just execute this manually on the website:
window.matchMedia("(prefers-color-scheme: dark)")

Actual results:

On my system the .matches is always static unless I restart Firefox.

So e.g.:

1. Set theme to light theme (Adwaita) in GNOME Tweaks.
2. Start Firefox.
3. Run the code above. You get false for dark, which is expected.
4. Change the theme to the dark one ("Adwaita dark").
5. Run the code again. You still get false for dark, which is not expected. (It should be true, as you've changed it.)

Alternative, change ui.systemUsesDarkTheme. Even if I set ui.systemUsesDarkTheme to 1, it also did not change and still returned false for the dark query when the system was set to light at Firefox' start.

Expected results:

It should always return the current system state and trigger the matchMedia listeners.

Cross-reference: bug 1494034
Fedora 31, GNOME 3.34

Comment 1

[Seba S.]

Hi, Rugk!

Thanks for your contribution!

I'm adding product and component to this issue so we can continue making some research, and as you mentioned I think this is involved with https://bugzilla.mozilla.org/show_bug.cgi?id=1494034.

Please let us know if this issue is reproduced in the latest Nightly edition. You can download it from here: https://nightly.mozilla.org/

If you still have the issue please create a new profile, you have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager
support.mozilla.orgsupport.mozilla.org

Once you have all this information, please let us know so we can continue investigating.

Regards,

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Yes, unfortunately there's no way how to fix that, It's a duplicate of Bug 1560660

Comment 3

[Martin Stránský [:stransky] (ni? me)]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1560660#c5 for details.
Child content process does not get the message about theme change it still uses the original setup.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

This should be fixable? In Mac content processes don't observe the system change and require IPC from the parent when that happens.

Not that it's the most high-priority thing to fix, but should be feasible. In general, these kind of notifications should maybe work in a more principled way.

Comment 5

[rugk]

Note that it also works with the default about:addons page e.g., that one does switch it's design when the system switches.

So either disable that, too; or better make it without a browser restart.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

I don't quite understand what happens on Linux. If the parent process can properly receive the system change, we can propagate the change to all contents in all tabs via nsContentUtils::CallOnAllRemoteChildren.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Is it a problem on querying the up-to-date value in the child process, not a problem on notifications? That's what Emilio implies in comment 4.
See this change, what we did for MacOSX. https://hg.mozilla.org/mozilla-central/rev/cea8a92452d5