New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 615870 link

Starred by 10 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-01-10
OS: Linux , Android , Windows , Chrome , Mac
Pri: 1
Type: Bug



Sign in to add a comment

Elements with clip paths and composited descendants must be composited

Reported by josero...@gmail.com, May 30 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.63 Safari/537.36

Example URL:
http://codepen.io/zen-co/pen/jrOxEg

Steps to reproduce the problem:
1. make a div with a clip-path (basic-shape for exemple)
2. make a child div, with the css: transition: transform (or all);
3. create a class with any transform, like translate;
4. make sure the child is position so clipping is obvious;  
5. apply the class to child.

What is the expected behavior?
clipping still applies during the transform transition.

What went wrong?
clipping is disabledduring transition, re-applied after.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? N/A 

Chrome version: 51.0.2704.63  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 21.0 r0
 
Components: -Blink Blink>Animation Blink>Paint

Comment 2 by suzyh@chromium.org, May 30 2016

Cc: rjwright@chromium.org ericwilligers@chromium.org
Components: -Blink>Animation Blink>Layout
Labels: Hotlist-Interop
Status: Untriaged (was: Unconfirmed)
Confirmed on Chrome 51 stable and 52 dev on Linux.

Firefox is intending to ship support for clip-path (https://bugzilla.mozilla.org/show_bug.cgi?id=1247229). Expected behaviour seen in Firefox nightly with layout.css.clip-path-shapes.enabled=true and substituting "clip-path" for "-webkit-clip-path". Adding Hotlist-Interop.

My understanding is that this is either Paint's or Layout's responsibility at the moment. Adding ericwilligers (as Animation team representative) and rjwright (who has more current context on this).
Components: -Blink>Paint -Blink>Layout Internals>Compositing>Animation Blink>Compositing
Labels: -OS-Windows OS-All
Looks like yet another compositor animated case that may be fixed by slimming paint.
Status: Available (was: Untriaged)
Summary: Elements with clip paths and composited descendants must be composited (was: Clip-path is disabled during child's transform transition)
The bug is that elements which have clip-path and composited children must become composited.
We have logic for that for other types of clipping, but it appears not for clip path.

<!doctype HTML>
<style>
body {
  height: 100vh;
  margin: 0;
}
#parent {
  height: 100%;
  -webkit-clip-path: circle(128px at center);
  clip-path: circle(128px at center);
  background: #eee;
}
#parent div {
  position: absolute;
  background: #222;
  transition: all 1s;
  width: 64px;
  height: 64px;
  margin-left: -32px;
  margin-top: -32px;
  left: calc(50% - 64px);
  top: calc(50% - 128px);
}
#parent.fx1 div {
  top: calc(50% + 128px);
}
#parent.fx2 div {
  transform: translateX(128px);
}
#parent.fx3 div {
  transform: scale(0.5);
}
#child {
    will-change: transform;
}
</style>


<div id="parent">
  <div id="child">?</div>
</div>
<script>

Owner: chrishtr@chromium.org
Status: Assigned (was: Available)
See subtreeReasonsForCompositing in CompositingRequirementsUpdater.cpp.

Comment 6 by phistuck@gmail.com, Jun 1 2016

 Issue 157218  might be related here.
I think this bug is causing an issue I am seeing.

Parent with -webkit-clip-path, children with transform: rotateZ() causing the clip-path polygon to mutate.

JSBin demonstration: http://output.jsbin.com/xufowohora
Cc: -rjwright@chromium.org chrishtr@chromium.org
Owner: schenney@chromium.org
Owner: smcgruer@chromium.org
Status: Fixed (was: Assigned)
Cc: smcgruer@chromium.org gov...@chromium.org pbomm...@chromium.org
 Issue 674344  has been merged into this issue.
The same bug is back! If you look at the original pen link (https://codepen.io/zen-co/pen/jrOxEg) you'll see the same behaviour that existed before the fix, i.e. clipping is disabled while animating the transform property.

The bug seem to be in a recent version change, probably 63. Canary (65) has the same bug. 
Status: Available (was: Fixed)
Confirmed that the codepen fails on tip of tree.

Equivalent using 'translate' transitions:
https://jsfiddle.net/ericwilligers/dsofg6t7/

Status: Started (was: Available)
Working in 62.0.3202.94, broken in 64.0.3282.24. Running a bisect now.
Actually, broken in 63.0.3239.108 too.
Owner: trchen@chromium.org
Status: Assigned (was: Started)
You are probably looking for a change made after 510001 (known good), but no later than 510003 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/71de49546d04b2d6a023c37e9cb3b6551aebb638..5e2e7cb82506a44d766a182b335383f59155f325


Looks like https://chromium.googlesource.com/chromium/src/+/5e2e7cb82506a44d766a182b335383f59155f325, which changed some clip-path criteria. trchen@ PTAL.
Labels: ReleaseBlock-Stable M-64
Labels: -Pri-2 -OS-All OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows Pri-1
ReleaseBlock must be P1, otherwise it's not important enough to block release.

Comment 20 by phistuck@gmail.com, Dec 19 2017

Did that commit fail any test? If not, can a test be added to prevent such regressions?
Cc: trchen@chromium.org
 Issue 796223  has been merged into this issue.
trchen@,Friendly ping to get an update on this issue as it is marked as stable blocker.
Status: Started (was: Assigned)
Sorry for the delay. A tentative fix is on the way: https://chromium-review.googlesource.com/c/chromium/src/+/848414
Project Member

Comment 24 by bugdroid1@chromium.org, Jan 5 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fc25706df1a4e7ee35bcd3623a33a30ea837199e

commit fc25706df1a4e7ee35bcd3623a33a30ea837199e
Author: Tien-Ren Chen <trchen@chromium.org>
Date: Fri Jan 05 22:43:14 2018

[Blink] Always create child clipping mask layer when composited clip-path is needed

A previous CL 722259 makes CompositedLayerMapping no longer creates child
containment layer when there is no overflow clip. This has a side effect
of also not creating the child clipping mask layer when the element has
clip-path but no overflow clip. This CL makes child clipping mask layer
to be always created when an element has clip-path and composited
descendants.

BUG= 615870 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I7fdc6f60eb6462a94c3123e8e157226744384cd4
Reviewed-on: https://chromium-review.googlesource.com/848414
Commit-Queue: Tien-Ren Chen <trchen@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527414}
[modify] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/LayoutTests/FlagExpectations/enable-slimming-paint-v2
[modify] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/LayoutTests/compositing/clip-path-with-composited-descendants-expected.html
[add] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/LayoutTests/compositing/clip-path-with-composited-descendants.html
[delete] https://crrev.com/7205a0d557dce9a56444ba5660e302aeeaa18b55/third_party/WebKit/LayoutTests/compositing/clip-path-with-composited-descendent-expected.html
[delete] https://crrev.com/7205a0d557dce9a56444ba5660e302aeeaa18b55/third_party/WebKit/LayoutTests/compositing/clip-path-with-composited-descendent.html
[modify] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/LayoutTests/compositing/images/direct-image-clip-path-expected.png
[modify] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/LayoutTests/compositing/images/direct-image-dynamic-clip-path-expected.png
[delete] https://crrev.com/7205a0d557dce9a56444ba5660e302aeeaa18b55/third_party/WebKit/LayoutTests/paint/clipath/clip-path-with-background-and-box-behind-expected.png
[modify] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/LayoutTests/paint/invalidation/clip/clip-path-constant-repaint-expected.txt
[add] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/LayoutTests/platform/mac/paint/clipath/clip-path-with-background-and-box-behind-expected.png
[add] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/LayoutTests/platform/win/paint/clipath/clip-path-with-background-and-box-behind-expected.png
[modify] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/Source/core/layout/LayoutObject.cpp
[modify] https://crrev.com/fc25706df1a4e7ee35bcd3623a33a30ea837199e/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.cpp

Cc: vamshi.k...@techmahindra.com
 Issue 798155  has been merged into this issue.
Labels: Merge-Request-64
NextAction: 2018-01-10
Let's bake a few days and take it to M64.
Project Member

Comment 27 by sheriffbot@chromium.org, Jan 6 2018

Labels: -Merge-Request-64 Hotlist-Merge-Review Merge-Review-64
This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: abdulsyed@chromium.org cma...@chromium.org
+ Abdul & Estelle for M64 merge review.
Thanks for the fix. My recommendation is to wait until M65, since we're already close to stable for 64. Seems like a fairly large change; however, doesn't seem as critical. Any issues with waiting until 65?
This is also a very old issue and not a regression in M64. +1 on waiting until M65
@cma not true, this was fixed last year, and broken recently, some website
/ web apps / games might be broken because of this regression;
I had to revert a game to using left/top position instead of translate,
because this totally broke a visual effect.

2018-01-09 14:04 GMT-05:00 cma… via monorail <
monorail+v2.1028981557@chromium.org>:
+1 on releasing in M64. I've got holdover fixes in place, but they aren't ideal. 
The cl is quite big and therefore needs more time to bake in beta. But we are only 1 week away from releasing M64 so let's not take the risk to merge this cl so late in the cycle. trchen@ what do you think? 
Actually this CL is not that big. Most of the changed files are rounding differences in tests. And the code changes are mostly adding comments why are we doing this and that. The only effective change is one line. :)

The expected impact is in rare cases we may unnecessarily create composited clip-path layer, resulting in slight performance/memory regression (Only on complex pages that use both clip-path and compositing layers. Other pages are unaffected.). That is due to not optimizing simple cases as aggressively, to avoid causing correctness issues.

My personal opinion is that the risks are very low.

Comment 35 by cmasso@google.com, Jan 10 2018

It is good to know the risk is very low. However, I would like what is making this issue a release blocker for M64. What is making it more critical in M64 than other previous milestones? 

We should only merge very critical fixes into the release branch at this point since the stable release is nearing.
It is a regression re-introduced in M63 by a crash fix. Recent releases prior to M62 are not affected. It is unfortunate we didn't make it before M63 goes stable, and I agree we should only take crash fixes to stable.

M64 is near to stable promotion, but before that happens, it is still beta, and IIUC it is still desirable to fix new correctness regressions in beta.
The NextAction date has arrived: 2018-01-10

Comment 38 by cmasso@google.com, Jan 10 2018

Labels: -Hotlist-Merge-Review -Merge-Review-64 Merge-Approved-64
I see. Merge approved! Let's make sure to monitor this closely in the next beta after merging it.
Project Member

Comment 39 by bugdroid1@chromium.org, Jan 11 2018

Labels: -merge-approved-64 merge-merged-3282
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40

commit cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40
Author: Tien-Ren Chen <trchen@chromium.org>
Date: Thu Jan 11 22:27:12 2018

[Blink] Always create child clipping mask layer when composited clip-path is needed

A previous CL 722259 makes CompositedLayerMapping no longer creates child
containment layer when there is no overflow clip. This has a side effect
of also not creating the child clipping mask layer when the element has
clip-path but no overflow clip. This CL makes child clipping mask layer
to be always created when an element has clip-path and composited
descendants.

BUG= 615870 
TBR=trchen@chromium.org

(cherry picked from commit fc25706df1a4e7ee35bcd3623a33a30ea837199e)

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I7fdc6f60eb6462a94c3123e8e157226744384cd4
Reviewed-on: https://chromium-review.googlesource.com/848414
Commit-Queue: Tien-Ren Chen <trchen@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#527414}
Reviewed-on: https://chromium-review.googlesource.com/862631
Reviewed-by: Tien-Ren Chen <trchen@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#488}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40/third_party/WebKit/LayoutTests/FlagExpectations/enable-slimming-paint-v2
[modify] https://crrev.com/cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40/third_party/WebKit/LayoutTests/compositing/clip-path-with-composited-descendants-expected.html
[add] https://crrev.com/cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40/third_party/WebKit/LayoutTests/compositing/clip-path-with-composited-descendants.html
[delete] https://crrev.com/e55d3f2330becb5156ba13276936eb8c0778af96/third_party/WebKit/LayoutTests/compositing/clip-path-with-composited-descendent-expected.html
[delete] https://crrev.com/e55d3f2330becb5156ba13276936eb8c0778af96/third_party/WebKit/LayoutTests/compositing/clip-path-with-composited-descendent.html
[delete] https://crrev.com/e55d3f2330becb5156ba13276936eb8c0778af96/third_party/WebKit/LayoutTests/compositing/images/direct-image-clip-path-expected.png
[delete] https://crrev.com/e55d3f2330becb5156ba13276936eb8c0778af96/third_party/WebKit/LayoutTests/compositing/images/direct-image-dynamic-clip-path-expected.png
[delete] https://crrev.com/e55d3f2330becb5156ba13276936eb8c0778af96/third_party/WebKit/LayoutTests/paint/clipath/clip-path-with-background-and-box-behind-expected.png
[modify] https://crrev.com/cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40/third_party/WebKit/LayoutTests/paint/invalidation/clip/clip-path-constant-repaint-expected.txt
[add] https://crrev.com/cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40/third_party/WebKit/LayoutTests/platform/mac/paint/clipath/clip-path-with-background-and-box-behind-expected.png
[add] https://crrev.com/cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40/third_party/WebKit/LayoutTests/platform/win/paint/clipath/clip-path-with-background-and-box-behind-expected.png
[modify] https://crrev.com/cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40/third_party/WebKit/Source/core/layout/LayoutObject.cpp
[modify] https://crrev.com/cd19cf71f82bd6493c7d6b31fc91b188c4c9ab40/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.cpp

Labels: TE-Verified-M64 TE-Verified-64.0.3282.97
Verified this issue on Ubuntu 14.04, Windows-10 and Mac OS 10.12.6 using chrome latest M64 #64.0.3282.97 by following test case provided in the original comment. Observed clipping is applied during the transform of transition. Hence marking it as TE-Verified for M64.

Thanks!
63.0.3239.108.png
20.0 KB View Download
64.0.3282.97.png
21.4 KB View Download

Comment 41 by cmasso@google.com, Jan 16 2018

Status: Verified (was: Started)
I post this here since this seems very related – using clip-path inset negative value (to extend the clip area outside of parent) is causing an issue in the same circumstance (child transform transition): 

The outside of the parent is clipped during child *transform* transition, even if it's inside the clip-path region, transition a position like 'left' is not causing the issue.

Example here: https://codepen.io/ncodefun/pen/JLbqgM

hummmm, although this seems to be fixed in canary (sorry should have checked), there's still an issue, which is quite different! 

I just tweaked the previous pen to make the child round so the issue in canary is more evident: the child is shifted down during transition !?
So this makes the problem clear in canary: https://codepen.io/ncodefun/pen/KoNOYb

The issue is that the child is shifted down by the amount of top clipping during the transition. If I should open a new bug please tell me!

Comment 45 by phistuck@gmail.com, Mar 19 2018

#44 - you should probably create a new issue. You can comment here with the issue number.

created a new issue – clip-path inset top value causes offset of child during transform transition:
https://bugs.chromium.org/p/chromium/issues/detail?id=823362

and made a bare minimal test case that show the issues (both in stable and in canary): https://codepen.io/ncodefun/pen/qoRdpj

Sign in to add a comment