Able to repro in Chrome 54 (stable).
Chrome 56 doesn't even render the print preview, filed  issue 668918 .

Able to reproduce the issue on Windows 10, Ubuntu 14.04 and mac 10.11.6 using chrome reported version #54.0.2840.98.

Bisect Information:
=====================
Good build: 51.0.2696.0  Revision(384437)
Bad Build : 51.0.2697.0  Revision(384752)

Change Log URL: 

https://chromium.googlesource.com/chromium/src/+log/f501c58425cbab94a2f1004f20102353665da37c..533c402f8b21e503ebcaf3f0de427f41076b4de1

From the above change log suspecting below change

Review url: https://codereview.chromium.org/1817873002

robhogan@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

Reverting my change doesn't fix it. There's something else going on here now. 

Could you double-check the bisect? I'm not seeing how we ever supported different margins on pages in the same print flow - which is what this issue is all about.

for what it's worth, when printing attached "content.html" if you set margins dropdown's value to "custom" and set the same margins manually, it renders correctly. The bug only occurs when margin dropdown's value is "default".

[ubuntu 16.04 Chrome Version 54.0.2840.100 (64-bit)]

seems like the same issue https://bugs.chromium.org/p/chromium/issues/detail?id=107912 it's been around for a while...

I am wondering if Chrome support @page:first CSS pseudo-class.

I set @page:first's margin and it works(it shouldn't work if @page:first is not support). but it's also destroy the whole print layout. 

Why setting @page:first's margin different to other pages cause bug?

Thanks all!

HI hejinjun529@ - the problem here is that we respect the page:first when it comes to positioning the margins but we don't reflow the text. This is on my list to fix, it's just going to be a little while before I get to it.

Just to update, still able to reproduce this issue on Win-10 using latest canary #57.0.2970.0.

robhogan@ - Could you please have a look into this issue.

Thanks...!!

The bug affects Chrome 55.0.2883.87 (64-bit) on Ubuntu 16.04 as well.

Also following bugs seem similar or the same with this one:

* https://bugs.chromium.org/p/chromium/issues/detail?id=259661
* https://bugs.chromium.org/p/chromium/issues/detail?id=167570
* https://bugs.chromium.org/p/chromium/issues/detail?id=355116

Just to update, still able to reproduce this issue on mac 10.12.2 using latest canary #57.0.2985.0	

robhogan@ - Could you please take a look

This is in my queue and I will get to it eventually, but it's the way it has always worked so not a regression.

mstensho@ - had a look at this and using ViewFragmentationContext seems promising for letting layout know about different page dimensions when it lays out the view. Returning a different fragmentainerLogicalHeightAt() depending on which page we're on, for example, seems straightforward enough.

But I can't yet see my way to how we can have a different width for the view for different pages - I think any change I make to the width for page 2ff. is going to affect the layout width on page 1, no?

Do we maybe need to do what PrintHeaderandFooter() does and create a separate WebView for the first page and layout that separately?

I'd appreciate your thoughts - I don't think the possibility for different column widths is available in column layout is it?

Right - Blink supports variable fragmentainer heights (it's used when printing multicol that crosses page boundaries, and also when there's a nested multicol container situation), but there's no support for variable fragmentainer widths. There actually used to be support for variable fragmentainer widths too, to implement CSS regions, but that was removed some years ago. WebKit still has it, I think. The code to support it caused complexity and was rather intrusive. It was scattered all across block layout code (to set the right line width depending on which fragmentainer you were in, to reposition and resize floats, depending on which fragmentainer you were in, and so on). I'm not sure if anyone ever tried to make it work for other layout models, such as tables or flexbox (but I doubt it). Also, this was only done for flow thread based layout, i.e. multicol (which actually doesn't need it) and CSS regions. In other words, I don't think it has ever worked with printing.

I don't imagine this is something that should be reintroduced in the current Blink layout engine. We should expect to see it in LayoutNG, though, which has native support for fragmentation.

Spec: https://drafts.csswg.org/css-break/#varying-size-boxes

OK well we leave it open until that happens.

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

Is there a rough ETA on when LayoutNG will be in production? N {weeks, months, years} ?

N years sounds about right. :)
NG will be shipped in phases (not all layout modes/features at the same time), and it might be that it will be possible to test support for variable fragmentainer sizes in NG already late this year, if you enable experimental features.

I think that's as accurate as I can present it.

Is there a bug we can block this one on?