We did some work in this area already as part of https://bugs.webkit.org/show_bug.cgi?id=142662, but there is a case where an element with both a "backdrop-filter" and a "mask" may not correctly clip the backdrop layer. This happens mostly on WK1 but can happen infrequently on WK2 as well.
<rdar://problem/29320059>
Created attachment 299811 [details] Patch
Comment on attachment 299811 [details] Patch I'll have a test up later, but I wanted to let the bots have a try with this patch to see if it breaks anything.
Comment on attachment 299811 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=299811&action=review Why no test? > Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:2018 > - updateClippingStrategy(*m_backdropLayer, m_backdropClippingLayer, m_backdropFiltersRect); > + if (!m_maskLayer) > + updateClippingStrategy(*m_backdropLayer, m_backdropClippingLayer, m_backdropFiltersRect); Is it ever the case that you have both a m_maskLayer and m_backdropClippingLayer here? In that case, I think this breaks things. I think the layer might have a mask for normal masking, but also a backdrop (possibly with m_backdropClippingLayer because of rounded corners).
(In reply to comment #4) > Comment on attachment 299811 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=299811&action=review > > Why no test? See my previous comment, this is only temporary. > > Source/WebCore/platform/graphics/ca/GraphicsLayerCA.cpp:2018 > > - updateClippingStrategy(*m_backdropLayer, m_backdropClippingLayer, m_backdropFiltersRect); > > + if (!m_maskLayer) > > + updateClippingStrategy(*m_backdropLayer, m_backdropClippingLayer, m_backdropFiltersRect); > > Is it ever the case that you have both a m_maskLayer and > m_backdropClippingLayer here? In that case, I think this breaks things. I > think the layer might have a mask for normal masking, but also a backdrop > (possibly with m_backdropClippingLayer because of rounded corners). So… m_backdropClippingLayer is set only as a result of calls made to updateClippingStrategy() in updateBackdropFiltersRect(), which then sets the m_backdropClippingLayer as the m_backdropLayer. It seems to me we'd get in a situation where we may have both a m_backdropClippingLayer and a m_maskLayer if the element has backdrop-filter, border-radius and mask CSS properties set. The current code doesn't know how to deal with that as far as I can tell and our current test coverage doesn't seem to test this, or at least my change doesn't break that. I think with my change `mask` would take precedence over border-radius if both are specified.
Actually, in the particular case I've been dealing with it's a "clip-path" property, but I expect both "mask" and "clip-path" both end up setting the m_maskLayer on a GraphicsLayerCA.
Created attachment 299934 [details] Patch
Created attachment 299963 [details] Patch
Comment on attachment 299963 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=299963&action=review > Source/WebCore/ChangeLog:8 > + If a layer had a backgrop filter, but also corner radii that triggered using a mask layer, BACKGROP!
Comment on attachment 299963 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=299963&action=review > LayoutTests/css3/filters/backdrop/backdrop-filter-uneven-corner-radii-expected.html:34 > + <div class="clipped container"> "clipped" class doesn't do anything > LayoutTests/css3/filters/backdrop/backdrop-filter-uneven-corner-radii.html:35 > + <div class="clipped container"> "clipped" class doesn't do anything
Comment on attachment 299963 [details] Patch Attachment 299963 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/2960332 New failing tests: css3/filters/backdrop/backdrop-filter-uneven-corner-radii.html
Created attachment 299970 [details] Archive of layout-test-results from ews101 for mac-elcapitan The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-elcapitan Platform: Mac OS X 10.11.6
https://trac.webkit.org/r211305 Test fix in https://trac.webkit.org/r211307