Bugzilla

(In reply to :Gijs (he/him) from comment #8)
> Is it possible to check if the resize / media query listener invocation is caused by print preview, e.g. by checking a different media query? :-)

You might be able to opt out of firing on print if you add `not print` to the beginning of your string...
e.g. this media-query applies to all viewports wider than 50px ***which are not print documents**
```
data:text/html,<style>@media not print and (min-width: 50px) { div { text-decoration:underline}}</style><div>hi
```

> Should I assume based on comment 7 and bug 1806913 that we're going to try to fix the print code rather than the consumers like Firefox View and google calendar? :-)

We probably need a general fix, yeah.  It's possible that it won't be super-graceful for print-selection if the document actively messes with the part of the DOM that includes the selection (spitballing: maybe we expand the selection at that point, since we've potentially lost information).

Having said that: if Firefox View is able to either reduce its DOM-fiddling or skip its matchMedia callback on print (via e.g. adjusting the media query with `not print` or something to that effect), it might still be a nice way to reduce chaos and avoid less-than-graceful print-selection fallback (to the extent that we care about print-selection reliably doing precisely the right thing for Firefox View at least...)

> I thought we disabled JS in the print document, so I wonder if that's not happening in time and/or if the resize/mql listeners being queued is somehow bypassing that. Or perhaps I'm just wrong and we don't disable JS in print docs? :-)

We do run `matchMedia` JS callbacks, as of recently -- see bug 774398.  Some sites (e.g. CultureAmp) use matchMedia to do their CSS media-queries, basically; and they end up looking broken (more broken than other browsers) if we print their formatted-for-a-wide-viewport content.  So: we fire matchMedia on print like other browsers do now.

(In reply to :Gijs (he/him) from comment #8)
> Is it possible to check if the resize / media query listener invocation is caused by print preview, e.g. by checking a different media query? :-)

You might be able to opt out of firing on print if you add `not print` to the beginning of your string...
e.g. this media-query applies to all viewports wider than 50px **which are not print documents**
```
data:text/html,<style>@media not print and (min-width: 50px) { div { text-decoration:underline}}</style><div>hi
```

I imagine the equivalent matchMedia query would have the same behavior (not firing on print).

> Should I assume based on comment 7 and bug 1806913 that we're going to try to fix the print code rather than the consumers like Firefox View and google calendar? :-)

We probably need a general fix, yeah.  It's possible that it won't be super-graceful for print-selection if the document actively messes with the part of the DOM that includes the selection (spitballing: maybe we expand the selection at that point, since we've potentially lost information).

Having said that: if Firefox View is able to either reduce its DOM-fiddling or skip its matchMedia callback on print (via e.g. adjusting the media query with `not print` or something to that effect), it might still be a nice way to reduce chaos and avoid less-than-graceful print-selection fallback (to the extent that we care about print-selection reliably doing precisely the right thing for Firefox View at least...)

> I thought we disabled JS in the print document, so I wonder if that's not happening in time and/or if the resize/mql listeners being queued is somehow bypassing that. Or perhaps I'm just wrong and we don't disable JS in print docs? :-)

We do run `matchMedia` JS callbacks, as of recently -- see bug 774398.  Some sites (e.g. CultureAmp) use matchMedia to do their CSS media-queries, basically; and they end up looking broken (more broken than other browsers) if we print their formatted-for-a-wide-viewport content.  So: we fire matchMedia on print like other browsers do now.