Can you provide a link to the page that you were trying to print or another page that reproduces the problem?

You mention this is related to scaling - was the cut off content not an issue in older versions of Chrome, before scaling was added (56 and below)?

Will try to create a repro page tomorrow. Thanks.

Thank you for providing more feedback. Adding requester "rbpotter@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Ok so I figured out what it was (test page attached).  The outer element had a height set on it, but the inner elements were causing page breaks which exceeded the calculated height. Tough to say if there's anything the browser should necessarily do in that scenario.

Deleted: test.html 532 bytes

test.html 532 bytes View Download

Thanks for the test case, I can reproduce the problem. It also happens with the scaling feature disabled, so it seems to be a layout issue that looks different at different scaling settings. The outer element height gets scaled along with the inner element sizes, so it prints correctly only if you can find a magical scaling value (81 works for the test case with Letter paper/Default margins) that allows the inner elements with page breaks to fit in the scaled outer element height.

+Blink>Layout to see if there is anything that could be done here. It gets cut off in Print Browser mode as well.

Also happens on Windows.

+atotic as he looked into a similar issue not too long ago.

 The absolutely positioned divs get fragmented by LayoutBlockFlow between pages. LayoutBlockFlow is complex, and outside of my current knowledge.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

So who does understand LayoutBlockFlow?

+mstensho

We're kind of doing the right thing here.

The outer DIV has a fixed height that's overflowed (and overflow is hidden) because of a soft page break between the two (relatively positioned) children. The second child doesn't fit right after the first child, and it's not at the beginning of the page, so we get a soft break and the sibling is pushed to the next page. Of course it doesn't fit there either, but this is how we're supposed to behave. This is similar to how we break words in line layout. If you have a super-long word that doesn't fit on the current line (that already contains other words), we'll insert a soft line break and push that word to the next line, even if it might not fit there either.

Then again, the spec does say that the user agent *may* treat objects with non-auto height and hidden overflow as monolithic [1], and therefore not attempt to fragment inside them. We could do that, but that could potentially break other things, since we'd no longer be inserting breaks inside such objects, and we'd therefore risk slicing monolithic children (such as lines) between pages.

[1] https://www.w3.org/TR/css-break-3/#possible-breaks