1784335 - prefers-color-scheme MediaQueryList change event doesn't fire before and after print

Status: RESOLVED FIXED

(Core :: Printing: Output, task)

Description

[BenjaminAster]

Steps to reproduce:

When printing a page, the CSS media query (prefers-color-scheme: light) is applied even when the operating system's color theme is set to dark. This is the expected result and works this same exact way in all browsers.

In JavaScript, one can listen to a change in the color scheme by creating a MediaQueryList object like this:

const mediaMatch = window.matchMedia("(prefers-color-scheme: light)");

and then listening for its change event:

mediaMatch.addEventListener("change", (event) => {
	console.log(event);
});

This also works as expected when the operating system's color theme is switched.

The issue:
In Firefox, this event is not fired when the page is printed and the operating system is in dark mode, while in Chromium it is. I don't know what the spec says about this or if it says anything about it at all, and I think both implementations make sense in some way (when printing the page, the operating system's color theme isn't actually switched, so should this event be fired or not?)
But in any case, there is a browser incompatibility going on here. So either should Firefox fire the change event before and after print, or Chromium should disable it.

I've also written a small steps-to-reproduce demo, but the entire code was already mentioned above.
Steps to reproduce:
(1) Set your operating system to dark mode in its settings
(2) Visit this URL: https://benjaminaster.com/bugs/mediaquerylist-change-event/
(3) Open the JavaScript console in DevTools
(4) Print the page by pressing Ctrl+P and cancel the print
Observe that in Firefox nothing is logged to the console, while in Chromium the event is logged, which means that Firefox does not fire the event at all while Chromium does.

Tested on Windows 11 in both stable and nightly/canary channels of Firefox and Chrome.

PS: Not all issues fit into this repro steps / actual results / expected results boilerplate template structure. Why isn't there a way to simply submit an issue without these three textboxes? Am I missing something here? I understand that you want to make it clear to users how they should structure their issue, but as I said, not all issues fit into this structure. Also, this is neither a "defect report" nor a "request for enhancement". It is simply a comment pointing out a browser incompatibility, without arguing which implementation does it the correct way. Bugzilla forces me to choose either of them.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Toolkit::Printing' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Mark Striemer [:mstriemer]]

Emilio, any thoughts on this? Seems like it isn't specified what we should do but we aren't compatible with Chromium

Comment 3

[Emilio Cobos Álvarez (:emilio)]

This is very similar to bug 774398, see that (long) discussion as for why these don't fire on Firefox (basically, the document being printed is different). But using the code from that bug we can fire it quite trivially, while also improving the DevTools print emulation.

Curious, what's the use case for this vs. just before/afterprint?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1784335 - Make print emulation also prefer light color-scheme. r=dholbert

This has the side effect of firing the media query list change event for
printing, but it also improves the print emulation on DevTools, which is
an extra win!

Comment 5

[BenjaminAster]

Curious, what's the use case for this vs. just before/afterprint?

I'm working on an application where when the page is loaded initially, the color theme is set to the system's color theme. Whenever the user changes the theme of their operating system, the app's color theme is also changed. Additionally, the app provides a dark/light color theme button where the user can overwrite their preference, but as soon as the operating system's color theme is changed, the setting gets overwritten again with the operating system's choice. I do it this way because I don't want to make a three options (os-default/dark/light) button which wastes a lot of space, but I also want the user to be able to sync the theme with their operating system's, even when the user has clicked the button once.
Printing is critical for my application, so I want to switch the site to light mode whenever it is printed. I do this by listening to beforeprint/afterprint and adding/removing a printing class to the <html> element. I don't use @media print here because I want my light mode custom properties all in one place (I use a :root:is(.light-theme, .printing) selector for that, the default is dark mode).
In Firefox, everything works perfectly here, but in Chromium I have an edge-case problem: If the user has their operating system's color theme set to dark, but chose to enable light mode with the button in the app, and prints the page, Chromium fires the change event after the print, telling me that the user's operating system switched to dark mode. My code then puts the page in dark mode again, even if the user opted into light mode before.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cf566ee2f54b
Make print emulation also prefer light color-scheme. r=dholbert

Comment 7

[Marian-Vasile Laza]

Backed out changeset cf566ee2f54b (Bug 1784335) for causing mochitest failures on test_emulateMedium.html.
Backout link
Push with failures
Failure Log

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cdd2eab67d10
Make print emulation also prefer light color-scheme. r=dholbert

Comment 9

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/cdd2eab67d10