* When clip-path is set to a different value, say inset(1px), the expected behavior occurs.

Clipping is a paint concept, over to the paint team for triage.

Able to reproduce the issue and is broken in M55, below are the bisect details for the same:

55.0.2860.0 - Good Build
55.0.2864.0 - Bad Build:

Change Log: https://chromium.googlesource.com/chromium/src/+log/55.0.2860.0..55.0.2864.0?pretty=fuller&n=10000

Unable to narrow down as all the builds invoked in between do not load any web sites, both using per revision scrip and regular bisect script. Unable to find a possible suspect from the change log as well.

Adding needs triage, so that it gets triaged properly. Untriaging it so that it gets addressed.

The test as written would not work prior to 418827. Changing clip-path to -webkit-clip-path would allow checking older builds.

https://chromium.googlesource.com/chromium/src/+/57da1c75484e5a3f0af03d038c43e6f23e1549e8 seems highly plausible for at least one of the issues.

Or https://chromium.googlesource.com/chromium/src/+/469bcf04ced0868049864010a367b0d56a73ffa7

But yes, also check earlier versions with the -webkit-clip-path property.

Seems likely it was me. I'll take a look.

Actually, I tried this on M54 (and as far back as M52) using -webkit-clip-path as suggested in #6 and the behavior was the same so it's definitely not my patch. The behavior changed sometime in M56 where the #child div doesn't show up at all, but it's still not correct.

Has clip-path ever worked properly on high-DPI screens? It seems like we composite the layers but clip-path can't be handled properly on the compositor and needs to be repainted on scroll. I can cause clip-path to fail on Linux-dev by passing --force-device-scale-factor=2.

Unassigning so someone from paint can have a look.

Clip path for a composited child of the clipper is known to be broken https://bugs.chromium.org/p/chromium/issues/detail?id=615870

I think we leave this as Available because we are clearly not right and I think we should see what happens when we fix 615870.

Thanks for the speedy responses!

We noticed 615870 has a fix committed, but we're still able to reproduce the issue in Canary (57.0.2971.0). Has the fix made it into the Canary builds? If not, when might we expect it to be?

We looked into the nature of the fix for 615870. As we understand, "hasClipRelatedProperty()" wasn't recognizing "clip-path" as a clipping property; This patch starts recognizing it as such, so elements with "clip-path" are correctly clipped.

I think it's safe to say the patch is unrelated to this problem. When we set "overflow: hidden" on an element, which should cause "hasClipRelatedProperty()" to return true and circumvent the bug in 615870, we still experience the issue on Retina Displays.

Something we observed that might be share-worthy: We're getting the expected behavior if we substitute "clip-path" with an equivalent "clip" property.

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. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

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

This appears to be fixed, if I am correctly understanding the expected behavior. There is no difference Retina/non-Retina and the greenish div is only visible when scrolled up.