Able to reproduce this issue on reported version 61.0.3163.100, latest stable 62.0.3202.75 and latest canary 64.0.3251.0 using Win 7, Win 10

This issue is seen from M57 i.e; 57.0.2926.0 from the introduction of scaling. Hence considering this issue as Non-regression and marking as Untriaged.

NOTE: Issue is not seen on Ubunutu 14.04 and Mac 10.12.6

The issue appears to be laying out the page into an area narrower than the window size (for purposes of layout scaling up is the same as printing to a smaller page). I can reproduce the same cut off behavior by setting page size to A5 paper with 100% scaling if I have the browser window fully maximized. The case described here as well as A5 paper works if you shrink the browser window before opening the preview. This seems to be related to the page CSS applying various widths based on the width of the media - simplified test case attached. +Blink>Layout as this looks like it may be layout related and the page gets cut off in Print Browser mode also.

RE: comment 1, did you test with different browser window sizes on Linux/Mac vs Windows? I was able to reproduce this on Linux, and it seems likely this is common to all platforms.

Deleted: 778837_test.html 5.6 KB

778837_test.html 5.6 KB View Download

Deleted: 778837_styles.css 266 bytes

778837_styles.css 266 bytes View Download

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

commit 4c9edd832c4cf110cb73e2000f415da43a465681
Author: Robert Hogan <robhogan@gmail.com>
Date: Mon Nov 06 19:01:50 2017

Set the page size for printing before laying out for print

ResizeForPrinting() used to be called before the page was laid
out for print. This made sense because the size of the webview
has an effect on the way the contents are laid out. In the case of this
bug for example, the width available to the layout depends on the width
of the media thanks to a css query and that determines the number of pages
required to print/preview the doc.

In https://codereview.chromium.org/2089373002 and
https://bugs.chromium.org/p/chromium/issues/detail?id=567317 ResizeForPrinting()
was moved because it was felt this was causing CSS transitions to be triggered
and adversely affecting the layout. 

Unfortunately none of the tests in that bug were successfully automated in the CL
and in manual testing the tests in the CL and the bug now pass regardless of the
position of the ResizeForPrinting() call in StartPrinting().

So this CL reverts crrev.com/2089373002 by moving ResizeForPrinting()
back to where it was since it doesn't appear to have had any positive effect.

Bug:  778837 
Change-Id: I492546756266bd1eecf1b5d155c3f3daaed694e7
Reviewed-on: https://chromium-review.googlesource.com/749949
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: nainar <nainar@chromium.org>
Commit-Queue: Robert Hogan <robhogan@gmail.com>
Cr-Commit-Position: refs/heads/master@{#514199}
[modify] https://crrev.com/4c9edd832c4cf110cb73e2000f415da43a465681/components/printing/renderer/print_render_frame_helper.cc
[modify] https://crrev.com/4c9edd832c4cf110cb73e2000f415da43a465681/components/printing/test/print_render_frame_helper_browsertest.cc

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

Looks like it's fixed.