Affected versions

• Firefox 90.0b3
• Firefox 91.0a1

Affected platforms

• Windows 8.1
• macOS 10.15.7
• Ubuntu 20.04

Steps to reproduce

1. Launch Firefox
2. Access the language selection on Wikipedia page
3. Print the page

Expected result

• No additional blank page is added

Actual result

• An additional blank page is added

Regression range

• Will see for a regression

Additional notes

• The issue can be seen in the attachment

Hi, I was able to spot the day this behavior was introduced, it was the 18th of December 2019. I couldn't finish the bisect because my mozregression throws an error (both in windows and Ubuntu). Nonetheless, I want to point out that before this bug, the printing was worse, I attach how it used to print, it's missing the middle section.

I think this is related to the wikipedia page's lang-list-container element, which has visibility: hidden and max-height: 0, but is nevertheless contributing height as though it were being displayed. If I explicitly set height: 0 on it in the Inspector, the extra page is no longer generated.

So this seems more like a layout/fragmentation issue than specifically about Print Preview. Moving to Layout for further investigation.

(In reply to Jonathan Kew (:jfkthame) from comment #2)

I think this is related to the wikipedia page's lang-list-container element, which has visibility: hidden and max-height: 0, but is nevertheless contributing height as though it were being displayed.

More important than visibility:hidden here is the overflow:hidden. That (combined with the max-height) should prevent the contents from requiring any space on the page, but it seems that's not working properly.

I've got a reduced testcase which I'll post shortly.

(In reply to Florencia Di Ciocco, NI to vbalducci from comment #1)

Hi, I was able to spot the day this behavior was introduced, it was the 18th of December 2019.

I get the same regression range.

I couldn't finish the bisect because my mozregression throws an error (both in windows and Ubuntu).

I don't think it really throws an error - it just tries to bisect further within a single day and fails to do so because we don't have any finer-grained builds cached that far back. It's quite noisy about this which is unfortunate, but if you scroll up you can still get the last pushlog which it provided for the last bisect operation that it was able to do, which is:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=930ad6def3c7961c82b2af20b66be3351603684f&tochange=f870bccd07eeedcde5f5e0ee290d6b2158934105

The relevant bug in there would be bug 1602430.

Nonetheless, I want to point out that before this bug, the printing was worse, I attach how it used to print, it's missing the middle section.

Indeed, this wasn't really "good" before the regression. We just failed to clamp the height of the scrollable area at all; whereas after, we do clamp the height but we also let it create additional pages for some reason.

(In this case, the visibility:hidden on the content meant that it mostly didn't paint, which is why we get a mostly-blank page in good.pdf. The behavior is clearer with my attached testcase, which prints with both bordered boxes being visible on all of the pages, in builds before 2019-12-18.)

Given that, I'm removing the regression keywords, since our behavior now is essentially better than before, even if it's slightly more confusing in some cases. Bottom-line, this is a "wart" that was left behind when bug 1602430 was fixed.