1830307 - Portrait printing edition.cnn.com creates blank pages pdf

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[nicoleta.sibisan]

Note
* further investigation needed regarding the affected platforms

Found in
* 113.0b8

Affected versions

• 112.0.2, 113.0b8, 114.0a1 (2023-04-27)

Tested platforms

• Affected platforms: win 11, MacOs12 (both only on some stations - this needs further investigation)
• Unaffected platforms: MacOs 13

Steps to reproduce
1. Launch Firefox.
2. Go to https://edition.cnn.com/
3. Wait for the page to load.
4. Ctrl/Cmd +P and observ the preview.
5. Select “Save to PDF” or “Microsoft Print to PDF”.
6. Print and check the pdf document.

Expected result

• Both preview and printed document have site content.

Actual result

• Both preview and printed document have blank pages and no other site content besides the main menu on the first page.

Regression range
Mozregression on win 11, provided the following pushlog_url:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1ec7354ac97383d101388669afb97e0d08e8be4e&tochange=164b776f5b1f58e5dde01548c6e64c2d7a080772

Additional notes

• The first page is blank in the versions which are not affected.

Similar issue: bug 1477018

Comment 1

[nicoleta.sibisan]

Attachment: edition.cnn.com_blank-print.pdf

Comment 2

[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 BugBot documentation.

Comment 3

[Daniel Holbert [:dholbert]]

I can reproduce in Nightly 114.0a1 (2023-05-03) on Ubuntu 22.04.

Interestingly, I can work around the issue by first shrinking my browser window.

• If my viewport is less than 960px wide, CNN renders with a more single-column "mobile layout" with the main story occupying the full viewport width, and I can successfully print-preview when starting from that state.
• If my viewport is 960px wide or wider, CNN renders with a multi-column article layout, and I trigger this bug when attempting to print from that state.

HOWEVER, if I have landscape-oriented paper pre-selected, then I actually get the opposite outcome -- I end up with blank pages if-and-only-if my browser viewport is skinnier than 960px at the moment that I print.

So the issue appears to reproduce when our print operation informs CNN that the document is crossing that 960px viewport-size threshold (in either direction) when we generate the print-preview rendering. That probably causes them to rebuild or restyle some part of the page. (And presumably portrait-mode US Letter paper has a viewport that is skinnier than 960px, whereas landscape mode is wider than 960px.)

Comment 4

[Daniel Holbert [:dholbert]]

If I watch the page with devtools open as I resize the browser viewport, I can see CNN briefly giving their header element this style at the moment that we cross the 960px viewport-size-threshold:
margin-bottom: -21649px

That massively-negative margin-bottom (on the header) is sufficient to pull all of the page content up off the top of the screen, leaving an entirely blank document. (I confirmed this by applying that style manually and looking at the result).

You don't actually see this happening when you're just normally viewing the page because they remove that style almost right away. But probably the removal operation doesn't get a chance to run when we're printing, and we're left with a printed doc that has the intermediate margin-bottom: -21649px; styling, and we get blank output as a result.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screencast showing extremely-large `margin-bottom` values being briefly applied to the header, when I resize the window horizontally

Here's a screencast illustrating what I mentioned in comment 4. Watch the margin-bottom values that get (briefly) applied to the header element as I resize the window -- they're often on the order of 19,000px.

At the end of the video, I manually add margin-bottom:-19000px and you can see that this does indeed make all the content disappear.

Comment 6

[Daniel Holbert [:dholbert]]

I guess the giant margin-bottom value is always coupled with a giant height value, which should effectively cancel it out and not actually produce blank content. So it's not quite as simple as what I show at the end of my video where I just add the margin-bottom:-19000px on its own.

Nonetheless: I can work around this bug entirely by inserting the following CSS into a style rule targeting that header element, e.g. extending its .header__wrapper-outer {...} CSS rule...

height: auto !important;
top: 0 !important;
margin-bottom: 0px !important;

With that added, print-preview reliably works fine, regardless of my viewport size and my page orientation, as far as I can tell. So it's still something related to those extreme styles being dynamically added.

Comment 7

[Daniel Holbert [:dholbert]]

I can also force this bug to reproduce by inserting a cursed version of the styles from comment 6: height:19000px !important; and margin-bottom: -19000px !important. Those styles don't hide any content when I view the page directly, but I do see blank output when print-previewing.

I get a lesser version of the bug if I use a less massive value, e.g. +/-3000px gives me several blank pages followed by useful content.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase demonstrating the underlying issue with `margin-bottom` shifted content getting clipped (now spun off as bug 1831201)

I think this testcase is equivalent to the rendering that CNN briefly sets up when you cross a viewport-size threshold.

In Firefox, this testcase renders with 6 blank pages in print preview.
In Chrome, the "Can you see[...]" text renders at the top of the first page. I believe that's the correct rendering.

Comment 9

[Daniel Holbert [:dholbert]]

That reduced testcase is broken quite a ways back; I can reproduce blank print-preview output in Nightly 2018-08-17, version 63.0a1.

(The recent regression here is just that we now happen to be firing an event that CNN reacts to by producing something like the attached testcase when print previewing, due to their viewport-size change handlers. Though it was actually already possible to trigger this issue in CNN even in older builds, if you happen to initiate print-preview at a moment where they have large, balanced margin/height values on the header element. For example, they seem to have those values on the header element for a second or two after pageload, and this yields a bunch of blank content in print-preview at that point even in Firefox ESR 102.)

Comment 10

[Daniel Holbert [:dholbert]]

Comment on attachment 9331472 [details]
reduced testcase demonstrating the underlying issue with margin-bottom shifted content getting clipped (now spun off as bug 1831201)

I spun off bug 1831201 for the (longstanding) issue with content getting clipped when it's shifted due to a negative margin.

I think that's what we have to fix in order to address this issue with https://edition.cnn.com/ . We could also suggest that CNN fix this with an improvement on their end, too, though -- probably adding some @media print-guarded CSS with non-gigantic height/top/margin-bottom values (with !important styles) for this header element, along the lines of what I quoted in comment 6.

Comment 11

[Daniel Holbert [:dholbert]]

This CSS fixes the issue for me, and should be pretty safe[1] & matches their intent[2] I think:

/* When printing, disable CNN's sometimes-giant styles for height, top, and margin-bottom,
   since they break print layout in Firefox.
   See https://bugzilla.mozilla.org/show_bug.cgi?id=1830307
*/
@media print {
    .header__wrapper-outer {
       height: initial !important;
       top: initial !important;
       margin-bottom: initial !important;
    }
}

We could suggest that CNN folks add that to their styles -- and in the meantime, I think we could ship that^ as an about:compat intervention. :denschub what do you think?

[1] This is "safe" in that it's sized to content (so unlikely to overflow/clip), and it only takes effect when printing (so it can't break the regular website), and it's just overriding some sticky-positioning-related dynamically-applied styles (which are irrelevant when printing, since sticky positioning is only relevant in a display medium where the user can scroll inside the content).

[2] RE "matches their intent" - content doesn't get clipped, and the CNN logo still shows up as-expected, and the header-ad still shows up if you have "print backgrounds" checkbox enabled. (An even-simpler intervention would be to add display:none to this element :) but that would hide the logo & header-ad which presumably isn't something that CNN would want to be doing in their own CSS.)

Comment 12

[Daniel Holbert [:dholbert]]

(In a perfect world we would "just" fix this by fixing 1831201; but I suspect bug 1831201 may be a bit tricky, since it'll involve having one page draw frames that live on another page. That's something we do in other cases, too -- e.g. for the layout.display-list.improve-fragmentation print-truncation mitigations -- but it's fairly delicate and this might (?) be the first time we do that sort of thing in the reverse direction.)

Comment 13

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

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

Comment 14

[Dennis Schubert [:denschub]]

(In reply to Daniel Holbert [:dholbert] from comment #11)

[...], I think we could ship that^ as an about:compat intervention. :denschub what do you think?

Good idea! I filed bug 1830307 to build and ship that in the 115 cycle.

Comment 15

[Daniel Holbert [:dholbert]]

Thanks!

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Dennis Schubert [:denschub] from comment #14)

Good idea! I filed bug 1830307 to build and ship that in the 115 cycle.

(That's this bug number :) Pretty sure you meant bug 1836105.)

Comment 17

[Dennis Schubert [:denschub]]

The intervention for CNN is now shipping in Firefox 115, and I confirmed it works. The first page for the front page is still blank'ish, but there's content on the following pages. Article detail pages look fine.

If I understand this bug correctly, the underlying platform issue here is bug 1831201, so this bug is only for the specific breakage on CNN? I'll close this bug as fixed because of that, but please reopen if I got something wrong! :)

Comment 18

[Daniel Holbert [:dholbert]]

Yup, that makes sense. Thanks!