RESOLVED DUPLICATE of bug 68196 140535
Border-radius clip of non-stacking composited descendant doesn't work 
https://bugs.webkit.org/show_bug.cgi?id=140535
Summary Border-radius clip of non-stacking composited descendant doesn't work
Simon Fraser (smfr)
Reported 2015-01-15 20:23:11 PST
Created attachment 244746 [details] Testcase Attached testcase shows a big blue rectangle on Mac; it should get radius clipping.
Attachments
Testcase (566 bytes, text/html)
2015-01-15 20:23 PST, Simon Fraser (smfr) 		no flags
Details
extra examples w/ exaggerated offsets (2.71 KB, text/html)
2016-07-14 14:48 PDT, Russell Bicknell 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Simon Fraser (smfr)
Comment 1 2015-01-15 22:03:52 PST
I have a fix for this.
Simon Fraser (smfr)
Comment 2 2015-01-15 22:17:44 PST
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.
Byungseon(Sun) Shin
Comment 3 2015-01-19 10:37:36 PST
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.
Russell Bicknell
Comment 4 2016-07-14 14:48:28 PDT
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.
Simon Fraser (smfr)
Comment 5 2016-07-14 15:27:47 PDT
Please file that issue in a new bug.
Russell Bicknell
Comment 6 2016-07-14 16:36:02 PDT
Filed as 159794.
Radar WebKit Bug Importer
Comment 7 2020-08-19 11:22:18 PDT
<rdar://problem/67414831>
Simon Fraser (smfr)
Comment 8 2021-09-22 12:05:51 PDT
*** Bug 216065 has been marked as a duplicate of this bug. ***
Simon Fraser (smfr)
Comment 9 2022-08-31 14:40:14 PDT
*** This bug has been marked as a duplicate of bug 68196 ***
Note You need to log in before you can comment on or make changes to this bug.