Firefox Nightly, macOS 12.4

0. Have a Culture Amp account and have a Report you can access
1. In your Culture Amp account, at the top under Feedback, click on Surveys (it's under "Organization" for me)
2. On the right, beside a report name, click "View Report"
3. Close to the top right, click the 3 vertical dots > Print
4. Print the report to a PDF (or you can just scroll through Print Preview)

Expected

• text flows and nothing is lost (Chrome does this)

Actual

• lines are missing around page breaks

I thought maybe "Print headers and footers" was the problem but it's not). If someone looking at this works at Mozilla, please let me know and I think we can get you set up with a demo Culture Amp report to reproduce.

I can reproduce a similar issue (a couple of lines of text missing at the page break) when printing/previewing a performance review in Culture Amp. It looks to me like this may be triggered by the mix of display:flex and position:absolute (or fixed) involved in the header of the Culture Amp page, where it displays its menu of Home / Feedback / 1-on-1s / etc.

If I use the DevTools Inspector to hide this by setting display:none on the <div class="App-App__navigationBarWrapper--2pbRN"> element that contains this header, and then look at the print preview again, the lines of text are no longer missing.

Seems like this might be related to bug 939897 or other issues linked from there...

There are a few things going on here, but I don't think it's related to bug 939897.

[One thing that confused me at first was that there were several blanked-out areas in the lines near the pagebreak on Overholt's screenshot; but at second-glance I realized that those were intentional-redactions rather than bugs. :) ]

Here are STR that work for me to reproduce this issue:

1. Visit https://mozilla.cultureamp.com/performance/
2. Ensure browser window is wide enough so that you see Home Feedback 1-on-1s Goals Reviews Development at the top.
3. Click "Reviews" and then "Your Performance Reviews"
4. Click "2021 H2 Performance Review"
5. Print / print-preview with Ctrl+P

EXPECTED RESULTS: No missing/covered up content.
ACTUAL RESULTS: The fixed "navigation-bar" header is present at the top of each page and covers up content wherever it is present.

However:

• If I shrink my Firefox window to be small enough to prompt Culture Amp to hide this navigation-bar header, and then I print, the header is also hidden in the printed output. [For now, this is a workaround for this bug, I think.]
• In Chrome, the header is always missing in the printed output, regardless of window size / whether-it-was-present-before-printing. [EDIT: per comment 5, Chrome does actually show the header in print/print-preview output, if you use a sufficiently wide page size and/or a sufficiently-small scale.)

It seems pretty clear that Culture Amp doesn't want this header to show up in the printed content, and they're apparently hooking in somehow (using something more-fiddly than media-queries) to hide it when printing in Chrome, but they're apparently not doing that in a way that works for Firefox.

(Also: this isn't UA-sniffing. Firefox-with-Chrome-UA-string gives the same results as stock Firefox.)

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

But actually: it turns out no content is actually missing; it's just covered up by the fixed header that jfkthame mentioned. This is the Home Feedback 1-on-1s etc. header -- in our printed output, that gets repeated at the top of every page, and it stomps on content.

Focusing on just the presence/absence of that header-bar in the printed output, I can reproduce this on many culture amp pages, e.g. this front landing page: https://mozilla.cultureamp.com/app/home

If I print-preview that page (with the header bar visible) in Firefox, the header-bar shows up in the print-preview rendering as well. But it's missing in Chrome's print-preview rendering.

• If I shrink my Firefox window to be small enough to prompt Culture Amp to hide this header, and then I print, the header is also hidden in the printed output. [For now, this is a workaround for this bug, I think.]

Note, this^ seems to be because Culture Amp actually modifies the DOM and literally removes this content from the page when I shrink my browser window. Presumably something like that happens when Chrome print-preview this page, too, but I'm not sure about the details yet.

(Also: unfortunately the page doesn't save/reduce very nicely; it's extremely JS-driven.)

In Chrome, it looks like the navbar wrapper-element <div class="styles_wrapper__2KjDZ"> gets removed from the DOM, at print-time, via a callback that fires from react-media.js and specifically via a MediaQueryListener.

Based on that, I think this might be a version of (or related to) bug 774398.

Also: they're not registering with a print media-query, but rather a viewport-width-based media query, (max-width: 767px). Apparently most page sizes are skinnier than that, and Chrome detects that we're crossing that threshold when setting up the print preview rendering and fires the callback.

However, if I intentionally make Chrome's print-preview dialog use a page that's a bit wider (in terms of CSS Pixels) by e.g. choosing US Letter with Landscape orientation and scale: 73%, then I can reproduce this exact same issue in Chrome.

So: bottom line, we're entirely interoperable here except for the fact that chrome seems to fire this MediaQueryListener JS-callback (and runs some JS as a result, modifying the document) at print-time.

I'm not sure that's something we can easily handle, for reasons discussed in bug 774398 comment 17 and bug 774398 comment 21.

I have an idea for that...

(Really, CultureAmp should just be using CSS media queries to show/hide this header, rather than using a listener and JS callbacks to modify the DOM.

And they probably also should be explicitly using a @media print query to hide this navbar element in printed output, regardless of viewport size. Otherwise it appears on every page and stomps-on-content in Firefox, and does so in Chrome too if the page is sufficiently large in terms of CSS pixels.)

Here's a reduced testcase, I think, using the media query from comment 5.

STR:

1. Load the testcase in a fullscreen browser (wider than 767px)
2. Ctrl+P to print-preview the testcase (using default print settings, i.e. US Letter or A4, portrait-orientation).

RESULTS:
After step 1, Firefox and Chrome both show "no" and only a single list-entry (in the browser-window).
After step 2, when the print-preview rendering appears:

• Firefox continues to show the same thing (still "no", still just 1 list-entry), in both the browser-tab and print-preview renderings.
• Chrome's print-preview rendering shows "Yes" and 2 list entries; and Chrome's browser-tab (behind print-preview) continues to show "no" and shows 3 list entries.

So it looks like Chrome is firing the media query listener-callback once when generating the printed document (due to the viewport-size shrinking to below the media query's threshold), and then they render the resulting document for print-preview; and then they fire the media query callback again when restoring the original viewport settings for the regular browser-tab presentation. Or something to that effect.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

I have an idea for that...

(From Matrix discussion: this was https://phabricator.services.mozilla.com/D150499 ; but unfortunately that only helps for print media queries, not viewport-size media queries which is what we've got here.)

For reference, relevant Chromium source seems to be this... I guess we could extend my patch above to also hack the page size or something. Though then we'd need to re-clone every time print settings change I guess.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #10)

Though then we'd need to re-clone every time print settings change I guess.

Maybe we could optimize to only do that if there's a media-query-listener registered? (not sure how easy that is to detect or condition on)

FWIW, Chrome seems to be doing something like re-cloning on every print-settings change, with my attached testcase. E.g. if I perform my comment 8 STR and then change Scale to Custom and then click uparrow/downarrow on the scale to wiggle back and forth between 100% and 101% (an inconsequential change), Chrome adds 2 list items for each change. This indicates that they're repeating the dance that I discussed at the end of comment 8.

If we can get the attention of some folks at Culture Amp, here's a style rule that we could suggest that they add to explicitly hide the navbar in print output. This fixes the issue for me (using the Stylus add-on to add arbitrary CSS to pages):

@media print {
     /* from https://mozilla.cultureamp.com/app/home */
    .styles_wrapper__2KjDZ,
     /* from https://mozilla.cultureamp.com/performance/evaluation_cycles/shared/ */
    .styles-styles__wrapper--Ld_tO
    {
        display: none;
    }
}

This^ is using the class names for the outermost navbar-wrapper-element that Culture Amp removes when the viewport gets sufficiently small. They seem to be using random-ish suffixes, so I wouldn't be surprised if that ends up changing over time & varying between deployments. Presumably/hopefully CultureAmp themselves have the ability to set this sort of media query CSS up with the appropriate selectors.

This fix (explicitly hiding the navbar in printed output) makes things substantially better for Firefox users, and it also fixes the same issue in Chrome for users who happen to be using wide printed pages (or equivalently, "scale:custom" with small scales). As discussed above, Chrome users with reasonable page-sizes will get lucky enough not to hit this, but only due to the viewport-size media query happening to match & fire its callback to remove this element from the DOM -- not via CultureAmp explicitly hiding this element in printed output (yet).

I changed https://phabricator.services.mozilla.com/D150499 to also fake the page size before cloning. But I think it'd be awkward to re-clone when changing print settings... That means you're not really printing the same document, you're picking up all the changes that happened between the beginning of the print operation and now. That seems to be Blink's behavior tho.

For illustration purposes, here's a screenshot of the original bug reproducing at https://mozilla.cultureamp.com/app/home (not an especially-important page, but I chose it because it doesn't really have any private info on it).

As you can see here, the header bar is present in Firefox's print-preview of this page (using default settings); and on page 2, the header-bar overlaps & covers-up content.

For comparison, here's Chrome with default settings; note that the navbar is not present in the print-preview rendering.

...and here's Chrome with custom print settings (landscape orientation, scale:66%) which does trigger the bug (due to being over Culture Amp's 767px threshold). As you can see here, the navbar does show up in this configuration; and it does cover up content on page 2+, on pages where there is content there (e.g. performance reviews), though you can't tell in this screenshot because this particular page is pretty small.

To illustrate the Blink (and WebKit) behavior Emilio describes in comment 13, load a continually-changing document such as

data:text/html,<body><h1></h1><script>f=function(){document.body.firstChild.textContent=Date.now();setTimeout(f,100)};f()</script>

and then open the Print dialog and try changing various settings (paper size, margins, scale, background, headers&footers, etc).

In Chrome, and also in Safari, every change results in the document content being updated, whereas in Firefox once the Print panel is open, the document content remains static as settings are changed (although it is restyled/reflowed as needed, e.g. when the available space changes).

IMO, the Firefox behavior seems preferable here.

Yes, agreed, that's why I think the patch in https://phabricator.services.mozilla.com/D150499 is a reasonable compromise... I'm on PTO after the 4th of July but happy to clean it up and add a test if it seems sensible.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #18)

Yes, agreed, that's why I think the patch in https://phabricator.services.mozilla.com/D150499 is a reasonable compromise...

This has landed now (thanks emilio!) which fixes this issue. Let's mark this as a dupe.