Bugzilla

AFAICT the bug report here is specifically about whether you can see the "RECAP AFTER USE" text on the first page.

In Chrome and in Firefox ESR102, you can see it (faintly) **if** you wait to do your print-preview operation until after the page loads.  In Firefox Nightly, that text is not visible.  So that's what the "expected results" were here.

A few interesting observations:
 (1) When you're just viewing the testcase directly (no printing): if you resize your browser window while viewing the page, the RECAP AFTER USE text disappears and then gradually fades back into view, when you cross certain viewport-size thresholds.
 (2) If you do Ctrl+P and then select landscape, and then cancel out of the print dialog and then try to reproduce again, *then* Firefox Nightly gives expected-results (the text is visible)

So I think what's happening is that the print viewport (for the default page size at least) happens to be smaller than some viewport-size-threshold.  Post-bug 774398, we give the page an opportunity to react to that, and the page decides to restart its "fade-in" animation (just as it does when you resize the browser viewport in a regular view of the page), and this means we end up getting our print-previewing at a moment where the text is invisible.

So this isn't really a Firefox bug; the page just has scripts to (temporarily) hide content when the viewport size changes beyond a certain amount, which is in fact what's happening here, which is why the content is hidden.  We're just doing what the page asked us to do.  Bug 1763030 may be involved from an interoperability perspective and might be part of why this doesn't reproduce in Chrome (it's possible they might not trigger the same viewport-size-change threshold whereas we do, as described in that bug).

But anyway,  given that this particular page isn't particularly printable anyway (per comment 2) it's probably not worth worrying about much.

AFAICT the bug report here is specifically about whether you can see the "RECAP AFTER USE" text on the first page.

In Chrome and in Firefox ESR102, you can see it (faintly) **if** you wait to do your print-preview operation until after the page finishes playing its full fade-into-view animation for that text.  In Firefox Nightly, that text is not visible.  So that's what the "expected results" were here.

A few interesting observations:
 (1) When you're just viewing the testcase directly (no printing): if you resize your browser window while viewing the page, the RECAP AFTER USE text disappears and then gradually fades back into view, when you cross certain viewport-size thresholds.
 (2) If you do Ctrl+P and then select landscape, and then cancel out of the print dialog and then try to reproduce again, *then* Firefox Nightly gives expected-results (the text is visible)

So I think what's happening is that the print viewport (for the default page size at least) happens to be smaller than some viewport-size-threshold.  Post-bug 774398, we give the page an opportunity to react to that, and the page decides to restart its "fade-in" animation (just as it does when you resize the browser viewport in a regular view of the page), and this means we end up getting our print-previewing at a moment where the text is invisible.

So this isn't really a Firefox bug; the page just has scripts to (temporarily) hide content when the viewport size changes beyond a certain amount, which is in fact what's happening here, which is why the content is hidden.  We're just doing what the page asked us to do.  Bug 1763030 may be involved from an interoperability perspective and might be part of why this doesn't reproduce in Chrome (it's possible they might not trigger the same viewport-size-change threshold whereas we do, as described in that bug).

But anyway,  given that this particular page isn't particularly printable anyway (per comment 2) it's probably not worth worrying about much.

AFAICT the bug report here is specifically about whether you can see the "RECAP AFTER USE" text on the first page.

In Chrome and in Firefox ESR102, you can see it (faintly) **if** you wait to do your print-preview operation until after the page finishes playing its full fade-into-view animation for that text.  Whereas in Firefox Nightly, that text is not visible in print-preview for the first page.  So that's what the "expected results" vs. "actual results" were about here.

A few interesting observations:
 (1) When you're just viewing the testcase directly (no printing): if you resize your browser window while viewing the page, the RECAP AFTER USE text disappears and then gradually fades back into view, when you cross certain viewport-size thresholds.
 (2) If you do Ctrl+P and then select landscape, and then cancel out of the print dialog and then try to reproduce again, *then* Firefox Nightly gives expected-results (the text is visible)

So I think what's happening is that the print viewport (for the default page size at least) happens to be smaller than some viewport-size-threshold.  Post-bug 774398, we give the page an opportunity to react to that, and the page decides to restart its "fade-in" animation (just as it does when you resize the browser viewport in a regular view of the page), and this means we end up getting our print-previewing at a moment where the text is invisible.

So this isn't really a Firefox bug; the page just has scripts to (temporarily) hide content when the viewport size changes beyond a certain amount, which is in fact what's happening here, which is why the content is hidden.  We're just doing what the page asked us to do.  Bug 1763030 may be involved from an interoperability perspective and might be part of why this doesn't reproduce in Chrome (it's possible they might not trigger the same viewport-size-change threshold whereas we do, as described in that bug).

But anyway,  given that this particular page isn't particularly printable anyway (per comment 2) it's probably not worth worrying about much.

AFAICT the bug report here is specifically about whether you can see the "RECAP AFTER USE" text on the first page.

In Chrome and in Firefox ESR102, you can see it (faintly) **if** you wait to do your print-preview operation until after the page finishes playing its full fade-into-view animation for that text.  Whereas in Firefox Nightly, that text is not visible in print-preview for the first page.  So that's what the "expected results" vs. "actual results" were about here.

A few interesting observations:
 (1) When you're just viewing the testcase directly (no printing): if you resize your browser window, the RECAP AFTER USE text disappears and then gradually fades back into view, when you cross certain viewport-size thresholds.
 (2) If you do Ctrl+P and then select landscape, and then cancel out of the print dialog and then try to reproduce again, *then* Firefox Nightly gives expected-results (the text is visible)

So I think what's happening is that the print viewport (for the default page size at least) happens to be smaller than some viewport-size-threshold.  Post-bug 774398, we give the page an opportunity to react to that, and the page decides to restart its "fade-in" animation (just as it does when you resize the browser viewport in a regular view of the page), and this means we end up getting our print-previewing at a moment where the text is invisible.

So this isn't really a Firefox bug; the page just has scripts to (temporarily) hide content when the viewport size changes beyond a certain amount, which is in fact what's happening here, which is why the content is hidden.  We're just doing what the page asked us to do.  Bug 1763030 may be involved from an interoperability perspective and might be part of why this doesn't reproduce in Chrome (it's possible they might not trigger the same viewport-size-change threshold whereas we do, as described in that bug).

But anyway,  given that this particular page isn't particularly printable anyway (per comment 2) it's probably not worth worrying about much.

AFAICT the bug report here is specifically about whether you can see the "RECAP AFTER USE" text on the first page.

In Chrome and in Firefox ESR102, you can see it (faintly) **if** you wait to do your print-preview operation until after the page finishes playing its full fade-into-view animation for that text.  Whereas in Firefox Nightly, that text is not visible in print-preview for the first page.  So that's what the "expected results" vs. "actual results" were about here.

A few interesting observations:
 (1) When you're just viewing the testcase directly (no printing): if you shrink or grow the width of your browser window, the RECAP AFTER USE text disappears and then gradually fades back into view, when you cross certain viewport-size thresholds.
 (2) If you do Ctrl+P and then select landscape, and then cancel out of the print dialog and then try to reproduce again, *then* Firefox Nightly gives expected-results (the text is visible).

So I think what's happening is that the print viewport size (for the default portrait page size at least) happens to be on the other side of some viewport-size-threshold, and the page is watching to see if that viewport-size-threshold gets crossed.  Post-bug 774398, we give the page an opportunity to react to the viewport-size-change, and the page decides to restart its "fade-in" animation (just as it does when you resize the browser viewport in a regular view of the page), and this means we end up getting our print-preview rendering at a moment where the text is invisible.

If landscape is pre-selected as the page orientation when you enter the print preview dialog, then (for me at least) the viewport-size-change happens *not* to cross that same threshold, so the page doesn't restart its animation, and  the text remains visible.

So this isn't really a Firefox bug; the page just has scripts to (temporarily) hide content when the viewport size changes beyond a certain amount, which is in fact what's happening here, which is why the content is hidden.  We're just doing what the page asked us to do.  Bug 1763030 may be involved from an interoperability perspective and might be part of why this doesn't reproduce in Chrome (it's possible they might not trigger the same viewport-size-change threshold whereas we do, as described in that bug).

But anyway,  given that this particular page isn't particularly printable anyway (per comment 2) it's probably not worth worrying about much.