r428626

Confirming what you see. Indeed caused by r428626. Attaching simplified test. Should probably come up with one that uses multicol instead of printing, since that's less tedious to test.

Deleted: tc.html 311 bytes

tc.html 311 bytes View Download

No equivalent testcase for multicol is possible. This is a pure printing bug.

The shrink-to-fit machinery for printing resizes the LayoutView when it needs to zoom out to fit everything (in our case the wide DIV, which was an IMG in the original test case) on the page. It resizes LayoutView outside of layout, which is bad and evil. Then the layout engine has no means of detecting the size change, which in turn means that the auto-width descendants (HTML and then BODY and then the DIV) won't be relaid out.

So r428626 really only made an existing bug more visible.

Do you have any suggestions on how the printing code can work better with the layout engine?

I don't know how LayoutView gets its size when the browser window is resized, but ideally printing should work the same way. In general, it would be great to get rid of all such printing peculiarities.

Also, not temporarily reformatting the current screen document for printing (and back to screen afterwards) when printing would be good. Cloning all data structures (DOM and layout) would be a cleaner way, but there may be reasons why that's not feasible, for all I know. I'm speaking as a layout person here. :)

Finally, writing printing tests for layout wasn't exactly easy last time I tried. I don't know how to write a LayoutTest for this bug, for instance. https://bugs.chromium.org/p/chromium/issues/detail?id=664235#c9 suggests that this is also preventing us from fixing that bug.

The test case I attached represents a div container for a full page business form. A letterhead image sets on top of the div in the body. The proof of concept document (a full page business form) renders to print correctly. In case that's any help.

Discovered that if I set the body min-width to the size of the image in my test case that it will render to print correctly. It works on the simplified test also. In case that's any help.

Deleted: simplifiedTest.html 423 bytes

simplifiedTest.html 423 bytes View Download

Thanks. That makes sense, because, if you set the final BODY width right away, #container gets its final width right away, and it won't need a second layout pass.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7d39380b14728b8debd8bcc73672ff778018f63e

commit 7d39380b14728b8debd8bcc73672ff778018f63e
Author: mstensho <mstensho@opera.com>
Date: Wed May 31 10:06:06 2017

Always relayout children of LayoutView when printing.

We can normally trust UpdateLogicalWidth() to detect and report size changes,
but this is not the case when printing, because
FrameView::ForceLayoutForPagination() changes the logical width of the
LayoutView behind our back.

BUG= 702778 

Review-Url: https://codereview.chromium.org/2908503003
Cr-Commit-Position: refs/heads/master@{#475862}

[add] https://crrev.com/7d39380b14728b8debd8bcc73672ff778018f63e/third_party/WebKit/LayoutTests/printing/block-width-relayout-shrink-expected.html
[add] https://crrev.com/7d39380b14728b8debd8bcc73672ff778018f63e/third_party/WebKit/LayoutTests/printing/block-width-relayout-shrink.html
[modify] https://crrev.com/7d39380b14728b8debd8bcc73672ff778018f63e/third_party/WebKit/Source/core/layout/LayoutView.cpp
[modify] https://crrev.com/7d39380b14728b8debd8bcc73672ff778018f63e/third_party/WebKit/Source/core/layout/LayoutView.h