Using the per-revision bisect providing the bisect results,
Good build:51.0.2696.0(Revision: 384437).
Bad build: 51.0.2697.0(Revision: 384752).

You are probably looking for a change made after 384517 (known good), but no later than 384521 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.
 
https://chromium.googlesource.com/chromium/src/+log/f501c58425cbab94a2f1004f20102353665da37c..533c402f8b21e503ebcaf3f0de427f41076b4de1

From the CL above, suspecting the below change 

@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.

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

Note : 1.Issue is seen in Mac OS 10.11.6 and Linux Ubuntu 14.04 
       2.Issue is seen in latest canary #M56 - 56.0.2895.0 

Thanks!

This is another view of the same (probably) bug.

1) Open 'index.html' and show the print preview. It looks like 'print-preview-no-scaling.PNG' - 4 pages, where page breaks are inserted not to clip the boxes. Note that one box on page 4 should fit on page 3... maybe related to margin styling.

2) In 'index.html', change "scale(1)" to "scale(0.25)". Open it and show the print preview. Now it looks like 'print-preview-0.25-scaling.PNG'. Four(!) pages is needed, and the page breaks from 1) are there!

Deleted: print-preview-no-scaling.PNG 18.8 KB

	print-preview-no-scaling.PNG 18.8 KB View Download

Deleted: print-preview-0.25-scaling.PNG 26.0 KB

	print-preview-0.25-scaling.PNG 26.0 KB View Download

Deleted: index.html 1.2 KB

index.html 1.2 KB View Download

I'm now getting a blank page when I print preview the test case in the original report. Could we get another bisect on this?

Tested the same on Mac os 10.12.2 using both good build 51.0.2696.0 and bad build 51.0.2697.0 and found the same bisect range.

To reproduce the issue , followed the below steps :

1. Download and Open the attached inline-block.html in chrome.
2. Click cmd+p for print preview page to open , now change the print preview settings to Layout -> landscape , colour->colour , paper size -> letter and check the options -> background graphics and uncheck the headers and footers.

Attached screencast for both good and bad build behavior.

Issue is seen on latest stable , beta , dev and canary channels.

Please let us know if anything else required from our end.

Thanks!

Deleted: 657402_good.mp4 760 KB

	657402_good.mp4 760 KB View Download

Deleted: 657402_bad.mp4 840 KB

	657402_bad.mp4 840 KB View Download

robhogan@chromium.org Did you enable background graphics when printing?

I'm no longer seeing the clown on ToT. Yes, you need to enable background graphics.

Wait, I forgot to turn it to landscape. Let me bisect again to confirm comment 1.

So near r300000, I actually see... 2 clowns when using Default margins. The only way to get no clowns is to turn margins to None or Minimum. At r390000, there's only 1 clown with Default margins. So the behavior has changed, but I can't ever reproduce the 0 clown case unless I change the margins.

The video in comment 4 shows this as well.

For comparison, attached is the Firefox output, with no clowns.

Deleted: mozilla.pdf 1.5 KB

mozilla.pdf 1.5 KB Download

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Attached the patch 'layoutstate.patch' which by no means is a fix for the issue, but for our purposes it solves the problem since we don't care for page breaks. At least, this suggests that page breaks are not inserted correctly.

Deleted: layoutstate.patch 616 bytes

layoutstate.patch 616 bytes Download

This is kind of a dupe of 653515 but only if it's wrong for paginated layout  (like normal layout in a viewport) to render the CSS layout, then decide the number of pages or viewport height needed to display that layout, and only then transform any elements with transform specified. 

I suspect it's correct to do that and that 653515 should be a wontfix. 

What's happening in the testcase in #1 here is that the page is first laid out without the transform applied. When there's a default margin on the page that results in the green/blue boxes overlapping a page break, so since they're inline-block they get moved down so that their top aligns with the start of the next page. Then the transform gets applied and so you see them rendered below the clown images but no longer sitting at the top of the second page.

With a margin of none on the page, the problem goes away because now the green and blue boxes fit on the first page again. So is it correct for the abspos element to position itself with respect to the top of the page as given by respecting the margin?

The behaviour of absolute positioned elements in paged media is specified at https://drafts.csswg.org/css2/visudet.html#containing-block-details and is says: "In paged media, an absolutely positioned element is positioned relative to its containing block ignoring any page breaks (as if the document were continuous). The element may subsequently be broken over several pages."

That's fine, so where is the edge of the containing block when a page has margins?

I go to https://drafts.csswg.org/css-page-3/#page-model and read the part that goes: "The page area acts as a container for all the boxes generated by the root element and its descendants that are laid out within a given page box. The edges of the page area on the first page establish the rectangle that is the initial containing block of the document."

And that makes me think our behaviour is correct - the top margin pushes down the top position of the initial containing block the document and that's what the abspos element has to respect.

So re the clown images - I think we're doing the right thing here. The testcase in #2 relates to  bug 653515 .

I'm going to close as wontfix - but please add more info here if you suspect I'm going wrong somewhere in this analysis.

Deleted: 657402.html 397 bytes

657402.html 397 bytes View Download

My understanding is that paged media combined with css transforms is not properly specified, if specified at all? If the decision was mine I would probably not consider page breaks at all within a DOM subtree if its parent is transformed in any way.

- Theoretically I find it reasonable because it just does not make sense to carry over properties from the original coordinate system when the element is rendered in a different, transformed coordinate system.
- Practically I can not come up with a use case where the current behavior is desired.

Maybe an ambitious implementation for inserting page breaks would respect the values of transformedElement.getBoundingClientRect(), which is one way to get back to the original coordinate system. Surely I would get in to some ugly corner cases that would need a thourough specification, and in lack thereof the safest solution is to avoid page breaks altogether.

A valid use case for avoiding page breaks for transformed elements is to scale a document to fit specific page dimensions. This is exactly my use case in the product I am working on.

Q1: Do you think these arguments are strong enough to challenge your analysis?
Q2: If not, what are your recommendations that support our use case?
Q3: If none, can you recommend a safer/cleaner patch than the attached 'layoutstate.patch' as a workaround?

Q1: Do you think these arguments are strong enough to challenge your analysis?
I think you have a point, but you need to engage with the editor of the css-transform spec (https://drafts.csswg.org/css-transforms/#transform-property) through the www-style mailing list to canvas their opinion. I honestly don't see them moving away from the main feature of transforms which is: "This module defines a set of CSS properties that affect the visual rendering of elements to which those properties are applied; these effects are applied after elements have been sized and positioned according to the Visual formatting model from [CSS21]. "

Q2: If not, what are your recommendations that support our use case?
Could you use <body style="zoom:0.5"> and still achieve the effect you're looking for?

Q3: If none, can you recommend a safer/cleaner patch than the attached 'layoutstate.patch' as a workaround?
I don't I'm afraid. Your suggestion of ignoring page-breaks when determining position during layout of transformed objects seems like how you would achieve what you want in code. I think it would be an intrusive patch though.