User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0

Steps to reproduce:

Press Ctrl+P to open Print dialog on page with styles set to only apply when not printing (and a transition set on the element). Minimal reproduction attached.

The issue does not occur in Chrome or Microsoft Edge.

Actual results:

Padding, margin, color, and other styles are incorrectly applied to the printed page when the element has transition-duration set.

Expected results:

Styles should not be applied when printing when a media query excludes them, regardless of whether the element has a transition.

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

Regression investigation results:

2022-11-02T16:07:03.613000: DEBUG : Found commit message:
Bug 774398 - Hack to make print and viewport media query listeners fire when printing. r=geckoview-reviewers,owlish,dholbert
This still doesn't fire on print settings changes, so it uses the
default page size. Which is probably better than nothing, but...

To make viewport-size media-query listeners work more generally for
printed documents, we would need to re-clone the top document
unconditionally for all print settings changes, which needs front-end
work at least, and is dubious if the page changes dynamically.

Differential Revision: https://phabricator.services.mozilla.com/D150499

In conclusion, this is a regression of bug 774398 starting in branch 105.

:emilio, since you are the author of the regressor, bug 774398, could you take a look?

For more information, please visit auto_nag documentation.

Hmm, so I'm not sure I agree with the expected result after looking more into this.

What happens after bug 774398 is that we trigger the style change due to @media print matching, which triggers transitions as expected. All those properties are transitioning, so at the time we print we see the "start" of the transition, which in this case are the initial values.

Here's a similar test-case that does this "manually", an where chromium also agrees on giving a red color.

I guess I could avoid starting transitions on print documents, which would fix this. One could argue that transitions when going into print are kinda silly because you'd always get the pre-transition value.

Scratch the above, this shows the difference more clearly.

Two tweaks:

• Use nsPresContext::Medium to decide whether to start transitions.
  This catches both the print emulation and the before/afterprint event
  dispatching code too, which is desirable.

• Don't clone transition effects for print docs. This seems to match
  other browsers (click "trigger transition", then Ctrl+P in Chromium
  for example).

Move our existing css-animations tests to WPT. They were written for
compat with other browsers so we want to know if other browsers behave
differently.

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

Reproduced the issue in Release 107 using Windows 10.
Verified - Fixed in Beta 108.0b4 and the latest Nightly 109.0a1 (2022-11-21) on Win10, macOS 12 and Ubuntu 20.