1814400 - The text on the first page of www.recapafteruse.co.uk is not properly printed

Status: RESOLVED INVALID

(Core :: Print Preview, defect, P3)

Description

[Ina Popescu, Desktop QA]

Found in

• Firefox 110.0b7

Affected versions

• Firefox 110.0b7
• Nightly 111.0a1
• Firefox 109.0.1

Tested platforms

• Affected platforms: Windows 10, macOS 11, Ubuntu 22.04
• Unaffected platforms: none

Steps to reproduce

1. Access https://www.recapafteruse.co.uk/
2. Hit Ctrl+P to print first page
3. Observe the Print Preview and Output

Expected result

• The text on the first page is properly printed.

Actual result

• A black page on macOS and a white page on Windows 10, Ubuntu is printed instead when printing the first page of www.recapafteruse.co.uk.

Regression range
Last good revision: bac7ef8fd063e784d39d9e18fcbd49dbed1655ec
First bad revision: 164b776f5b1f58e5dde01548c6e64c2d7a080772
Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=bac7ef8fd063e784d39d9e18fcbd49dbed1655ec&tochange=164b776f5b1f58e5dde01548c6e64c2d7a080772

Additional notes

• The issue is not reproduceable on Google Chrome and Microsoft Edge.

Comment 1

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

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

For more information, please visit auto_nag documentation.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Whether you get a black or a white page depends on whether you specify the "print backgrounds" setting. The print output seems pretty bad in other browsers too, so I think this is probably not worth digging much into.

Comment 3

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

Set release status flags based on info from the regressing bug 774398

Comment 4

[Daniel Holbert [:dholbert]]

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.