We also restored settings on chrome, used multiple users logins, restarted the computer and uninstalled and reinstalled the printer hardware.

pchalla@ can you please help us in reproducing this issue.

It looks like the dashboard requires a login. Without being able to look at the dashboard, or a copy of it, it is next to impossible to figure out what's wrong. Can you do one of the following?

a) Make a test account, and email me the credentials, so I can view the dashboard.

or

b) Open the dashboard, press Ctrl + S to save the webpage, select "Webpage, Complete" rather than "Webpage, HTML only" and email me the saved files.

Also confirmed the behavior (slightly worse in terms of overlap) on Chrome Version 59.0.3037.0 (Official Build) canary (64-bit)

Bisect to https://chromium.googlesource.com/chromium/src/+log/ebec09cdbe2965a07c54715cf4ba3b50603efe39..506506eac78a8106c4e92866a59b8c724ddc8b88 so r435917 ?

Where's the test case?

Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M58.

mstensho: Please contact Alex in comment 4 for the test case.

I made a smaller test case that we may be able to attach to the bug. I'll let Alex decide if it looks ok.

I hope we can fix this soon, but it probably should not block releases.

Here is the test case - thanks to thestig for slimming it down!

Deleted: packing_slip_example_production.html 1.5 KB

packing_slip_example_production.html 1.5 KB View Download

Thanks for the test case.

I'm not sure if the bug summary is right. I don't see how this relates to "default printing settings".

In the test case I notice two peculiarities:

#1. The small square that intersects with the second .page-container is partially printed on the first and partially on the second page. The second .page-container follows a .page-break, which inserts a forced page break, meaning that the second .page-container will start at the exact top of page 2. The small square (.logo), however, has a negative top margin. What may happen in Blink when you are at the top of the second page and move backwards (e.g. with a negative top margin) is that you end up on the previous page. Firefox doesn't seem to behave like this, at least not with this test case. In Firefox the block with negative margin stays on the second page, and just gets clipped away if it ends up too high up on that page.

#2. The page gets zoomed out a lot (tested with A4 portrait). This also happens in Firefox, though. The reason appears to be that .page-container is 11.7in wide, which is wider than the page area for A4 portrait. So we have to zoom out to make it fit.

I'm guessing that what you want fixed is #1 - right? Or is it something else?

Try with landscape / US Letter. I think Alex is interested in fixing (1).

OK, I'll just assume that then.

Deleted: tc.html 470 bytes

tc.html 470 bytes View Download

Confirming that r435917 is responsible for this regression. Attaching a simpler test, which uses multicol instead (easier to test without having to enter print preview all the time).

Deleted: tc-multicol.html 331 bytes

tc-multicol.html 331 bytes View Download

Work-around, based on the packing_slip_example_production.html test:

Change this:
.page-break {
  page-break-before: always;
}

To this:
.page-break {
  page-break-after: always;
}

The assigned owner "mstensho@opera.com" is not able to receive e-mails, please re-triage.

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

This needs to be retriaged by Blink>Layout folks.

The multicol test now works in LayoutNG (and the printing test will too, as soon as we implement printing). I don't think we'll ever get around to fixing it in the legacy engine, so we'll just have to wait for LayoutNG to ship.