1587723 - change events for prefers-color-scheme are never triggered on a web-extension's background page

Status: NEW

(WebExtensions :: Developer Tools, defect, P3)

Description

[Dahan Gong]

Attachment: Different console results

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36

Steps to reproduce:

• Install a web-extension, and inspect its background process
• run var b = ()=>matchMedia('(prefers-color-scheme:dark)'), c=b(); c.onchange = ev=>console.log('onchange', ev.target.matches); on its console
• switch the "Personalization -> Color -> default app mode" between Light and Dark on the "Settings" APP of Win 10
• see console messages

Actual results:

No messages will be logged.

If I run the same code on a console of a normal page (like "about:debugging"), then expected messages will occur.

Expected results:

It logs onchange true and onchange false (depending on the latest color scheme) on the console of a web-extension's background process.

https://bugzilla.mozilla.org/show_bug.cgi?id=1561546 seems related, but, although it's marked "fixed", I can not get "onchange" triggered on a background process yet.

Comment 1

[Raluca Popovici, Desktop QA]

Attachment: 2019-10-17_11h00_57.png

Comment 2

[Raluca Popovici, Desktop QA]

Hi,
This works as expected for me. I tried on my machine(Win 10) on Nightly 71.0a1 (2019-10-16). I attached a screenshot with my results.
Can you please test it using the latest Nightly build(https://nightly.mozilla.org/) and a new profile, you can find the steps to do that below:
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
Thanks!

Comment 3

[Dahan Gong]

@Raluca The bug only occurs on the console for an extension's background process, and during my tests, normal web pages do receive change events as expected.

I've tested latest https://download-installer.cdn.mozilla.net/pub/firefox/nightly/latest-mozilla-central-l10n/firefox-71.0a1.zh-CN.win64.installer.exe , and this issue still exists.

Comment 4

[Dahan Gong]

Explanation for a typo of the last message: not only code running on the console, but also an extension's background scripts (defined in manifest.json) have such a problem.

Comment 5

[Raluca Popovici, Desktop QA]

This seems a bit to technical for me but maybe one of our devs can take a look and might be able to reproduce on their end. I'm not sure if dev Tools Console is the correct component for it but it seems like a good place to start.

Comment 6

[Dahan Gong]

No, it's not a bug about DevTools. It's a bug about "background page" of web-extensions.

Here the console on DevTools is just to display error log messages, and

• this problem still occurs and is 100% reproducible even you setup a listener in the code of an extension's background scripts.
• if open an extension's options page, and use the window object to setup such a listener, then "change" events will be dispatched as expected.

Therefore, it should blame to some inner logic about the special implementation of "background page".

Extra info

This bug also exists on Chrome and I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=968651&can=2&q=reduced-motion%20change . As far as I've found, I think on Chrome it's because of lazy-dispatching for change events (it wait a Layout() which will never be executed on a background page).

Comment 7

[Nicolas Chevobbe [:nchevobbe]]

I can reproduce with the following:

var mediaQueryList = matchMedia('(prefers-color-scheme:dark)');
mediaQueryList.onchange = function(e) {
  console.log('prefers-color-scheme:dark changed to:', e.target.matches);
}

But I'm not sure the onchange should be triggered in webextension background scripts.

Let's ask the WebExtension folks who know probably more than I do.

Comment 8

[Miruna Curtean]

Attachment: Nightly 72 onchange.gif

I've tested this on Windows Pro 10 64-bit and Ubtunu 18.04.3 LTS on and in Nightly versions 70 and 71, also on Beta 70, and no logs were created when performing the theme color change.
However, when testing on the latest Nightly, 72.0a1 (20191022094606), the true and false logs were displayed (see Nightly 72 onchange GIF).
Could you please recheck to see if this issue still occurs for you on the latest Nightly or if it has been resolved?
Thank you

Comment 9

[Dahan Gong]

The 72.0a1 does not work on my laptop: Firefox 72.0a1 1022/093606 en-US (http://ftp.mozilla.org/pub/firefox/nightly/2019/10/2019-10-22-09-46-06-mozilla-central/firefox-72.0a1.en-US.win64.installer.exe) on Win 10 v1903 Education (build 18362.418). Neither (prefers-color-scheme: dark) nor (prefers-reduced-motion: reduce) can call onchange listeners.

My system language is zh-CN (Simplified Chinese), and the zh-CN version of the latest nightly build of Firefox 72.0a1 also failed during my tests.

Comment 10

[Miruna Curtean]

Thank you for trying this out. Somehow, after trying again this morning on the nightly installer provided I was not able to obtain any console logs during the OS color change.
After re-testing this in in Firefox Release 70.0 (20191016161957) , Beta 71.0b3 (20191021164841) and Nightly 72.0a1 (20191022214314) on Windows 10 Pro x 64 bit and Ubuntu 18.04.3 LTS, I've decided to mark this as NEW, as the occasions it has worked appear to be flukes.

Comment 11

[Dahan Gong]

(In reply to Miruna Curtean from comment #10)

Thank you for trying this out. Somehow, after trying again this morning on the nightly installer provided I was not able to obtain any console logs during the OS color change.
After re-testing this in in Firefox Release 70.0 (20191016161957) , Beta 71.0b3 (20191021164841) and Nightly 72.0a1 (20191022214314) on Windows 10 Pro x 64 bit and Ubuntu 18.04.3 LTS, I've decided to mark this as NEW, as the occasions it has worked appear to be flukes.

I've found why you saw those logs:

• The problem I've met is that listeners on "background page" (aka. the background window object) don't work
  • in fact, the code you ran on the console didn't generate log messages, which is "as described in this bug report"
• However, the two messages occuring when you switched the system dark mode is from the "extension tabs"
  • you had opened two new tab pages provided by the extension "Tabliss"
  • you had modified the extension's main.js and added the code in the discussions above (am I right?)
  • in one tab, the modified part of code was to log prefers...: changed to..., and the other tab had a log message of onchange ...
  • both tabs responsed on system dark mode changes
• This is why the logs are from "main.js:271:156182" - you add the code there.

BTW, I think the Tabliss is not a suitable example for this issue: because it has no background pages, so if no its tabs are opened, you'll find a location of chrome://devtools/content/shared/webextension-fallback.html when you inspecting it.

I recommend some other extensions, like uBlock Origin, Vimium, or my Vimium C to test this issue .

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 13

[Daniel Bodea [:danibodea]]

Setting component as "Developer Tools" so it would not reappear in outstanding lists. If further testing is needed, please NI me.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

This is probably because background pages are children of a windowless browser and the windowless browser has just a puppet widget, unfortunately we can observe system setting changes corresponding to prefers-color-scheme in a concrete widget on each platform.

Comment 15

[Hiroyuki Ikezoe (:hiro)]

For references for the person who will work on this issue. I tried nsIWindowMediator to enumerate top level windows, but it doesn't contain the windowless browser. (Note that it contains a hidden window). Instead BrowsingContextGroup::GetChromeGroup()'s TopLevels() contains the windowless browser, so that we can propagate the system settings changes into background pages something like this.

    BrowsingContextGroup* group = BrowsingContextGroup::GetChromeGroup();
    for (auto& context : group->Toplevels()) {
      if (nsIDocShell* docShell = context->GetDocShell()) {
        if (!docShell->IsInvisible()) {
          continue;
        }
        if (nsPIDOMWindowOuter* window = docShell->GetWindow()) {
          nsContentUtils::CallOnAllRemoteChildren(window, NotifyThemeChanged in nsPresContext.cpp,
                                                  nullptr);
        }
      }
    }