Sorry, disregard the last comment.

same happens for me using a sidebar but instead of using padding I'm using margins.
Emulating print media rendering show layout correctly, print page is instead wrong.
I am using Windows 10, Chrome 52

I have the exact same use case, and see the same problem. Note that this problem is NOT present on Mac, only Windows. It also appears to be missing layout recalculation in general, because the problem exists when using padding, margin, or positioning.

Chrome 53.0.2785.116 m (64-bit), Windows 10

I couldn't reproduce the issue on Linux, Windows 7, OS X 10.11.6 with Chrome 53.0.2785.116. Here is the code snippet that I was using
http://codepen.io/anon/pen/VKmOpW
Both a print preview and a physically printed page had 0 length padding.

I was able to reproduce the bug with Chrome 53.0.2785.116 on Windows 10. The bug is not simply caused by margin/padding. I had to add a transition to the property and a media query for max-width. Removing the transition and/or the max-width query fixes the problem.

Codepen: http://codepen.io/anon/pen/zKzJOo

I have attached an html file to reproduce the problem.

Deleted: chrome_bug.html 384 bytes

chrome_bug.html 384 bytes View Download

Mmm. I actually expect that specifying a transition will not make the content move. I do not see a problem with that (if you add transition: none under @media print, then I expect it to move, but it still does not move, which is probably a bug).
However, the presence or absence of @media (max-width: 1000px) should not affect the situation anyway and the fact that it does looks like a bug.

It also makes sense that using the Developer Tools to emulate @media print does move the content to the right place, because the layout is not frozen (unlike when you actually print).

I believe the media query for max width affects the printed page based off the size of the page. For example if I lower the max-width from 1000px to 1px the query is not used and the printed page is rendered as expected. Or if I change the printed page orientation to be landscape and set page size to be tabloid the page is rendered as expected since the media query is not used.

The bug seems to be with CSS media queries and how they are rendered during printing. If "@media print" is used then transitions should be disabled and the printed page should be the layout after transitions. This behavior seems to work but gets thrown off when another media query is introduced for width, as only the start of the transition is rendered and not the layout after transitions.

The transition issue is probably  issue 652417 .

 Issue 652417  has been merged into this issue.

Hi, Thank you for filing this bug (and the one duped against this.)

This issue was a regression I caused while fixing 412281. It has been fixed in the ToT canary (M55.) Stable is currently M53. So the change should make its way to stable soon. Sorry for the inconvenience caused here. Please comment here if I can help further. 

#13 - but I am not sure the original report was about print styles in combination with transitions.

#14 However is not mentioned, with the data provided on the OP the issue is not reproducible. Without sample code or site to test, the only way reproduce it is with the CSS transition.

Nainar thanks for the time to take a look on this issue. At the moment I am using stable (53). Do you mean if I install canary (55), I should be able to verify that the problem is gone?

@nainar

Thanks for looking into this issue. I'm unable to get the codepen in comment 8 to work in Canary (55.0.2881.5). Is the CSS unable to work as expected because the rules or media queries present. It seems to work in Firefox, removing the margin when printing.

Has the fix made it into Canary yet, couldn't find a commit?

#14: The issue is caused due to the fact that currently the ResizeForPrinting() function is called too early in StartPrinting(). The resize causes transitions to be triggered too early. That issue was fixed in the CL linked below. 

#15: Yup if you test your link in canary it should work. Attaching the output in stable and canary.  

#16: I just tested the file (the attachment not the codepen) you provided in #8 
and have attached the output. Please confirm that it works correctly? Testing printing issues on codepens/fiddles tends to be erroneous due to any css that might get added by the site itself. Test files are best in that case. 

The CL that fixed this issue is: https://codereview.chromium.org/2089373002

Deleted: 641311_comment8(53).pdf 40.7 KB

641311_comment8(53).pdf 40.7 KB Download

Deleted: 641311_comment8(55).pdf 40.2 KB

641311_comment8(55).pdf 40.2 KB Download

Deleted: 652417(53).pdf 44.4 KB

652417(53).pdf 44.4 KB Download

Deleted: 652417(55).pdf 43.6 KB

652417(55).pdf 43.6 KB Download

@nainar

I am able to verify the problem is fixed on version 55.0.2881.5 canary (64-bit) that I am testing.

Thank you for verifying on your end as well! :)

@nainar

I can now confirm it does work as expected in Canary. Thank you! 

#17 - yes, again, if you presume that the original report had transitions in its CSS, which you do not know. And the reporter stays quiet. :(