I am using FF65 in GNU/Linux Ubuntu 18.10 having the same problem, the base case written 7 years ago still is valid:

var mediaQueryList = window.matchMedia('print');
mediaQueryList.addListener(function(mql) {
if (mql.matches) {
console.log('before printing');
} else {
console.log('after printing');
}
});

In Google Chrome is working perfectly.

I must hide some css class elements in printing mode and unhide or show after leave the printing mode.

I am freelancer and it is difficult to explain to final clients that they could ONLY print with Google Chrome and FF, IE and others are still in ice age era for just print a document and not working in 2019.

Please mozilla devs, me and other users would like more priority or progress in this annoying bug. Thanks

(In reply to Ángel Guzmán Maeso from comment #20)

I must hide some css class elements in printing mode and unhide or show after leave the printing mode.

Why doesn't media queries work in this case? (or in the ones above really...)

@media print {
  .my-element, .my-other-element { display: none }
}

Though maybe I'm missing something?

In general, I don't think firing the media change reflects how Gecko does printing at all, as Boris has explained above.

It doesn't work for things like Canvas or SVG where simply resizing them with CSS just stretches them (or worse clears them in the case of canvas)

Also hitting this -- same scenario: I need to resize charts dynamically (using HighCharts) to match the page size. In Chrome I can do this perfectly using window.matchMedia('print'), but this doesn't work in FF. As other posters have indicated, window.onbeforeprint also doesn't work because at this point the document isn't yet sized to the page.

(In reply to Boris Zbarsky [:bzbarsky] from comment #1)

When you print, a new document is created, has a presentation in the print
medium applied to it, and is then rasterized to the print output.

This isn't true. The document is still the same. It has all the data that the user entered and all of the visual modifications from before opening the print dialogue. Maybe it was so 9 years ago, when somebody first discovered that this isn't working. The problem is that it also still has elements at the same width as the window is. I'm designing a complex UI that needs to react to window size changes by code, and it also needs to do that before printing to make the layout fit on the printed page. But it happily remains at whatever width the window was before.

Firefox only supports the "beforeprint" and "afterprint" events but "beforeprint" is fired before the "print" media query is active, so it's useless to update the page's layout. (This is the same behaviour as in Chrome.)

Chrome can tell the page when the "print" media query is active so it can update its layout to the real available page width. That works perfectly. Firefox just can't print such pages. Fortunately, Firefox is just my desktop primary browser and the printing to a downloadable PDF in my case is done through Chrome on the server. But Firefox users shouldn't print my page directly because that fails like it's 1995.

This isn't true. The document is still the same.

Just to be clear, what I wrote is how printing is actually implemented. The existing document is cloned and the clone is printed. See https://searchfox.org/mozilla-central/rev/083983b7f09b00cdfe4f70396e39ea4f8a1735e1/dom/base/nsGlobalWindowOuter.cpp#5366 in the window.print() implementation, for example; the user printing has a similar effect.

Note that printing is an asynchronous process that can take quite a while, and the document can be mutated by script while this process is happening. Those mutations will not show up in the print output, because the document state was snapshotted during the clone.

Hello there, hitting this issue as well. I need to listen for the media query change to then trigger a "resize" event. This will force JS libraries such as React Grid Layout to recompute their size. Use case is similar as ones quoted above. It works perfect in Chrome but not in Firefox.

Also as stated by Yves Goergen above, "beforeprint" won't work because the media query is not yet applied when it fires: if I trigger a "resize" event, it will not correctly resize, because the "print" media query is not yet applied to the page. So I specifically need to listen to the "print" media query.

This might not be useful enough to land tho, given the various use cases
here which seem to rely on having a different CSS viewport size.

(FWIW I posted a testcase with a viewport-size media query over in bug 1775142 comment 8, too.)

https://hg.mozilla.org/mozilla-central/rev/164b776f5b1f