Closed Bug 1559961 Opened 2 years ago Closed 1 year ago

Page is truncated when printing


(Core :: Printing: Output, defect)

67 Branch
Not set



81 Branch
Tracking Status
firefox81 --- fixed


(Reporter: thisismikedanger, Assigned: TYLin)


(Depends on 1 open bug, )



(5 files)

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
[EDIT: don't use that link. Instead use this one: ]

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.

Component: Untriaged → Printing: Output
Product: Firefox → Core

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.

Flags: needinfo?(thisismikedanger)

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.

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.

Flags: needinfo?(thisismikedanger)

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? I cloned this page from the original version at (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.

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?

Depends on: 939897

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. :)

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

Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 939897

Test printing 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.

Ever confirmed: true
Resolution: DUPLICATE → ---

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

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

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

Assignee: nobody → aethanyc

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

Attachment #9167157 - Attachment description: Bug 1559961 Part 3 - Reflow lines with pushed floats under constrained available block-size or in paginated context. → Bug 1559961 Part 4 - Reflow lines with pushed floats under constrained available block-size or in paginated context.
Pushed by
Part 1 - Update the reason for child's completeness in measuring reflow of flex items. r=dholbert
Part 2 - Consider a line's scrollable overflow when marking a line dirty. r=dholbert
Part 3 - Refactor the conditions to mark a line dirty under constrained available block-size. r=dholbert
Part 4 - Reflow lines with pushed floats under constrained available block-size or in paginated context. r=dholbert
Created web-platform-tests PR for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.