Created attachment 244746 [details] Testcase Attached testcase shows a big blue rectangle on Mac; it should get radius clipping.
I have a fix for this.
Actually I take that back. This is the non-stacking context case, where we use m_ancestorClippingLayer, which is going to also need a mask equivalent.
I guess it is came from the Container didn’t participate in overlap detection, so it couldn't clip child layer since later painting order of graphics layer.
Created attachment 283687 [details] extra examples w/ exaggerated offsets I found something recently that seems very closely related to this bug: composited descendants are positioned slightly differently than their ancestors. If the ancestor has a non-integer top or left (either set directly or during an animation) the descendant is sometimes positioned up or left by one *device* pixel. Maybe composited elements are aligned with floor and non-composited with normal rounding? In the attached page, the examples labeled "scale3d transform" show both this bug and the positioning thing I mentioned. However, the two cases at the bottom might go against my float vs. normal rounding possibility: If top / left of the parent are integers but a transform applied to it translates it by some non-integer amount, then there isn't any noticeable difference in the positions of the parent and child. If the top / left of the parent are *not* integers, then you can still see the slight offset of the parent and child - even with a zero translate3d transform applied to the parent. Also, if you zoom the page, you'll notice the offsets change but are never larger than one device pixel.
Please file that issue in a new bug.
Filed as 159794.
<rdar://problem/67414831>
*** Bug 216065 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 68196 ***