Using the per-revision bisect providing the bisect results,
Good Build: 57.0.2946.0 dev (Revision :437422)
Bad Build: 57.0.2948.0 dev (Revision :437764)

You are probably looking for a change made after 437634 (known good), but no later than 437635 (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/9b853cfcf82d8c57487cb0dd8d1eeaa5ca40260f..3de2a45741756dfa0640ce1037a76ee9eedabfbb

From the CL above, assigning the issue to the concern owner 

@smcgruer - 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/2558633005

Note : Issue is also seen on Mac os 10.11.6

Thanks!

This change in behavior is caused by my CL https://codereview.chromium.org/2558633005 , but I'm unclear what the correct behavior is. The bug I was fixing, 615870, implied that the animation should be clipped by the clip path.

If I understand http://output.jsbin.com/bogojib correctly, there is a rotating red rectangle which is a child of a div that is clipped by a SVG circle.

Note that Firefox 50.0.2 renders the rotating red rectangle as being clipped... in a slightly different way than us (see attached).

Assigning to Chris to check - Chris do you know the compliant behavior here?

Deleted: Screenshot from 2016-12-14 09:40:15.png 32.7 KB

	Screenshot from 2016-12-14 09:40:15.png 32.7 KB View Download

Note: There is something weird about our animation/clip interaction for sure. Compare http://jsbin.com/juranin/edit?html,output on Firefox 50.0.2 and Chrome 57.0.2951.0+, and also try turning the animation on/off. The animation in Chrome appears to be offset somehow. However, this doesn't relate to the original report here, which still is about whether this should clip at all.

This looks like a compositing issue, not an animation issue. The transform animation causes the red div to be promoted which exposes the compositing bug. Removing the animation and adding transform: rotate(40deg) also triggers the issue.

This is probably the same as https://bugs.chromium.org/p/chromium/issues/detail?id=615870 combined with https://bugs.chromium.org/p/chromium/issues/detail?id=157218.

With my patch for the latter applied, the border-radius case (the leftmost one) is fixed to match Firefox and the others remain unchanged.

As I recall the clipping spec, the difference compared to overflow clipping is that clipping clips everything including scrollbars, while overflow obviously does not.

chrishtr@ may still weigh in, but if I'm understanding correctly, this is a 2-way dupe and is not a regression or release blocker.

Yes, the child should be clipped. The clip is being positioned incorrectly
relative to the child. e.g. in this example at ToT.

http://jsbin.com/likorinoye/edit?html,output

schenney: agreed that there is no regression here, but there is an issue with composited clip-paths. Attached is the output of http://output.jsbin.com/juranin on ToT with your change patched in. The circular clip is offset up/left incorrectly.

I have been digging in, and the following diff in CompositedLayerMapping::updateChildClippingMaskLayerGeometry fixes the offset, but I am concerned as to the more general effects of such a change. There is also a nasty 1-pixel border left, which is likely the effect of bad rounding  or int/float conversion somewhere.

diff --git a/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp b/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
index 2d831e1..7be798a 100644
--- a/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
+++ b/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp
@@ -1378,13 +1378,9 @@ void CompositedLayerMapping::updateScrollingLayerGeometry(
 void CompositedLayerMapping::updateChildClippingMaskLayerGeometry() {
   if (!m_childClippingMaskLayer || !layoutObject()->style()->clipPath())
     return;
-  LayoutBox* layoutBox = toLayoutBox(layoutObject());
-  IntRect clientBox = enclosingIntRect(layoutBox->clientBoxRect());
-
   m_childClippingMaskLayer->setPosition(m_graphicsLayer->position());
   m_childClippingMaskLayer->setSize(m_graphicsLayer->size());
-  m_childClippingMaskLayer->setOffsetFromLayoutObject(
-      toIntSize(clientBox.location()));
+  m_childClippingMaskLayer->setOffsetFromLayoutObject(IntSize());
 
   // NOTE: also some stuff happening in updateChildContainmentLayerGeometry().
 }

Deleted: Screenshot from 2016-12-14 16:52:45.png 16.5 KB

	Screenshot from 2016-12-14 16:52:45.png 16.5 KB View Download

I think at this point we are agreed that this behavior is not a regression, although it is still incorrect... it's just arguably a tiny bit more correct than the original behavior (offset clip-path now versus no clip-path before).

Unless we can find an example of this impacting a real world use, this should not block stable.

Additional compositor clip-path issue discovered: http://jsbin.com/jexoxus/9/edit?html,output 

The clip-path is being bounded by the owning div when using the compositor, which it shouldnt be - it needs to be bounded by the size of the clip-path itself. The reason is currently unknown.

http://jsbin.com/tusehil/8 is another test-case that shows that we are clipping the mask rather than scaling it. See attached images for expected and actual.

Deleted: expected.png 13.8 KB

	expected.png 13.8 KB View Download

Deleted: actual.png 13.8 KB

	actual.png 13.8 KB View Download

Issue is still seen on mac os 10.12.2 using latest chrome canary M57 #57.0.2980.0 .

@smcgruer-- Could you please provide update on this.

Thanks!

I'm currently focused on position:sticky issues, so haven't spent any time on this. As per 6, 11, and 12, there are a number of issues with the current  implementation of composited clip-path, so it will require someone to put in more time to work out how to do this properly.

Note there is also a spec question of whether clip-path should be scaled/clipped to the owning element or not - see https://lists.w3.org/Archives/Public/public-fx/2016OctDec/0026.html .

@smcgruer,

Friendly ping!!

Still we are able to reproduce the issue on chrome latest Canary #58.0.2990.0.

Could you please look into the issue & update the thread.

Thank you.

Fixing all our clip path issues should be a one-off big task for someone. It's not P1, however.

 Issue 729394  has been merged into this issue.

 Issue 759298  has been merged into this issue.

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

We match Firefox on all the examples. I think we are correct at this time, or at least compatible. Anyone disagree? If so, reopen with what you think is the correct result.