1559961 - Page is truncated when printing

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

Attachment: PDF output when attempting to print page in 67

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Attempted to print https://terralinda.beaverton.k12.or.us/supply-list-clone
[EDIT: don't use that link. Instead use this one: https://terralinda.beaverton.k12.or.us/about-us/supply-list ]

Actual results:

Content is cut off (see attached)

Expected results:

All content should have printed - I tried using Firefox Nightly's print emulation to diagnose this further. When I turn on print emulation in Nightly, everything is there, but the print still comes out missing stuff regardless of whether I'm in FF 67 or the nightly.

Comment 1

[Daniel Holbert [:dholbert]]

Thanks for the bug report. I'm not sure I see/understand the problem, though. Can you clarify which content is cut off? I don't see anything obviously cut off in the attached testcase.

I do see that each "Supply list" listing in your linked testcase will expand to show much more information when it's clicked. I'm guessing (?) that those details are the things that you might have been expecting in the printed output. Is that correct? But: for me, they are present in the printed output, if I click the elements in question to expand them before I print. In other words, the printed output matches what I see on the screen, before I print.

Comment 2

[Daniel Holbert [:dholbert]]

In particular: if you're expecting that all the collapsed information should be automatically expanded when printing even though it was collapsed on the screen, then I think you should take that suggestion to the person who designed the web app that you're using here.

From the browser's perspective, that collapsed content has the CSS display: none applied to it, which requires that the browser not display it (for as long as it's got that CSS applied).

But if I'm misunderstanding the issue, please clarify what you're expecting to happen & what's actually happening.

Comment 3

[thisismikedanger]

Thanks for taking a look. I'm actually on the support team for the CMS in question here that's generating the page. We had it reported to us that printing the page printed the entirety of the page contents in Chrome/Safari, but Firefox was generating this cut-off output. After I reproduced what the user was seeing, I did some searching and saw other users reporting similar issues with Firefox print content being cut off, so I had assumed this was another example of that type of issue and logged this tracker. It sounds like this is actually just a difference in print behavior between browsers from what you're saying, though. I'm happy to close this up if that's the case.

Comment 4

[Daniel Holbert [:dholbert]]

Thanks for the reply.

If there's a browser difference here, then it's potentially a bug and we'd be interested to take a look, but so far I haven't been able to reproduce a difference between browsers. Chrome and Safari give me a PDF that looks pretty much exactly like what you attached, when I print the URL that you provided in comment 0.

Could you provide steps that produce more content in Chrome/Safari than they do in Firefox?

Comment 5

[thisismikedanger]

Interesting...so I cloned this page from the original version at https://terralinda.beaverton.k12.or.us/about-us/supply-list (I wanted to strip the site CSS to see if the print output changed). It seems like the clone prints wrong in Firefox/Chrome/Safari, but if you try printing that original page in Chrome/Safari, you should be able to see what I'm talking about. Maybe it's something about how our site CSS interacts with Firefox...? I can send you the PDF output I get from all 3 for that original page if that helps.

Comment 6

[Daniel Holbert [:dholbert]]

Thanks, I can reproduce the issue there. The content gets expanded, but then truncated at the first page. That's an instance of bug 939897, where we don't print flex items (children of display:flex) correctly right now. Sorry about that :-/ We're hoping to improve things there before long.

I can work around it locally by adding display:block !important; to the <div id="fsPageBody"> element (overriding various display:-webkit-box / display:flex declarations for that element, which use the same flexbox rendering mechanics under the hood in Firefox). Also, the display value on that element doesn't seem to have any other effect on the output at all, so perhaps you might consider removing all the display declarations for that element (leaving it as display:block by default), if there aren't any reasons for them?

Comment 7

[thisismikedanger]

Thanks! I'm talking to one of our designers about this now. Feel free to close/merge this into the other display:flex bug if it helps you keep things organized. Thanks again for talking this through, this has been another solid experience for us (well, me) reporting issues to Mozilla. :)

Comment 8

[Daniel Holbert [:dholbert]]

Thanks! I'll go ahead and mark this as a duplicate of bug 939897.

Comment 9

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Test printing https://terralinda.beaverton.k12.or.us/about-us/supply-list again after bug 1622935 landed, on Firefox Nightly (2020-05-13), but I still see the page truncated.

However, if I set float: none on <div class=" fsDiv fsStyleAutoclear" id="fsEl_24019"> instead of float: left, I don't see any truncation. So maybe Firefox do have some bug when breaking float element.

Comment 10

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Bug 1559961 Part 1 - Update the reason for child's completeness in measuring reflow of flex items.

Comment 11

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Bug 1559961 Part 2 - Consider a line's scrollable overflow when marking a line dirty.

Before this patch, a block frame considers a line dirty only if the line's
block-end is larger than content area's block-end.

However, scrollable overflow area should be broken in paginated environment
(both in a column container and in printing). We should take this into account
when marking a line dirty.

The dynamic wpt reftests are written with the following conditions in mind to
expose the bug:

1. Initially, all the elements fit into the first column.

2. After shrinking the multicol height, the block itself still fits into
   the first column, but its tall child (either a simple tall block or a
   tall float), which overflows the smaller multicol height, needs to be
   broken.

The flexbox printing reftest are similar. A flex container uses
unconstrained available block-size to measure flex items' block-size,
and then performs a final reflow with constrained available block-size,
which is similar to the dynamic scenario above. One caveat is that flex
items usually have IsBResize() set. So to expose this bug, a float
element needs to be deeply nested under a flex items.

Depends on D85478

Comment 12

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Bug 1559961 Part 4 - Reflow lines with pushed floats under constrained available block-size or in paginated context.

When a clearance frame is discovered in a BFC
subtree (ReflowInput::WillReflowAgainForClearance() is true), all the
block descendants of the BFC return from ReflowBlockFrame immediately
without placing their children or requesting continuation for their
children, etc., because the BFC is going to reflow the subtree the
second time.

When this happens, any block descendant whose lines containing pushed floats
should be marked dirty and reflowed again so that they can go through all the
split floats logic and set their nsReflowStatus to
incomplete/overflow-incomplete correctly. (We may develop a smarter way in bug
851629 to make the performance better.)

Depends on D85479

Comment 13

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Bug 1559961 Part 3 - Refactor the conditions to mark a line dirty under constrained available block-size.

This change cleans up the complex logic with additional comments added.
It shouldn't alter the behavior.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2649323b61fb
Part 1 - Update the reason for child's completeness in measuring reflow of flex items. r=dholbert
https://hg.mozilla.org/integration/autoland/rev/d377ce300d03
Part 2 - Consider a line's scrollable overflow when marking a line dirty. r=dholbert
https://hg.mozilla.org/integration/autoland/rev/5fe73187284a
Part 3 - Refactor the conditions to mark a line dirty under constrained available block-size. r=dholbert
https://hg.mozilla.org/integration/autoland/rev/db613effb20b
Part 4 - Reflow lines with pushed floats under constrained available block-size or in paginated context. r=dholbert

Comment 15

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/24928 for changes under testing/web-platform/tests

Comment 16

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/2649323b61fb
https://hg.mozilla.org/mozilla-central/rev/d377ce300d03
https://hg.mozilla.org/mozilla-central/rev/5fe73187284a
https://hg.mozilla.org/mozilla-central/rev/db613effb20b

Comment 17

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot