Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: c9651d6e97ae380627a634511249933c0a615098
https://github.com/WebKit/WebKit/commit/c9651d6e97ae380627a634511249933c0a615098
Author: Matt Woodrow <[email protected]>
Date: 2025-06-30 (Mon, 30 Jun 2025)
Changed paths:
M LayoutTests/TestExpectations
M
LayoutTests/css3/filters/clipping-overflow-scroll-with-pixel-moving-effect-on.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/ios/TestExpectations
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
M Source/WebCore/rendering/RenderLayerCompositor.cpp
M Source/WebCore/rendering/RenderTreeAsText.cpp
Log Message:
-----------
overflow:hidden should not clip filter: drop-shadow().
https://bugs.webkit.org/show_bug.cgi?id=219520
<rdar://72205047>
Reviewed by Simon Fraser.
This fixes various filter clipping issues, primarily that overflow clipping
should be applied before filtering, and clip(-path) should be applied after.
It also fixes some backdrop-filter WPTs because there's a clip outside of the
filtered element (in the reference file) which is being applied to the filter
rendering context. This prevents pixels that are outside of the visible area
from being available to the blur filter (which will move some of their value
into the visible area).
The existing clipToDirtyRect functionality attempts to prevent this, but gets
overriden if there's also a new clip inside the filter (which then walks
ancestors combining clips, and pulls the clip outside the filter back in). The
dirty rect already gets expanded to account for the required pixel movement, so
we do want to clip to this.
I think the right fix here is to make the clip ancestor walk not cross the
filter context boundary, rather than trying to avoid clipping inside the filter
at all.
Makes ClipRectContext's 'TemporaryClipRects' type an option flag, so that the
intended use of the clip rects (painting vs absolute etc) is independant of
whether the result should be cached.
When switching painting over to a temporary filter context, set a flag so that
clip calculations will stop at the current layer and not include clips from
outside the filter context. Force temporary clip rects for descendants, since
this is different to the normal clipping.
Refactor RenderLayer::calculateClipRects to use parentClipRects(), so that the
logic of walking ancestor clips is all in a single spot.
Add a check for painting clip rect to parentClipRects, and don't combine clips
across a painted filter boundary that moves pixels.
Adds a new ClipRectsOption 'OutsideFilter'. This is distinguish between the
clipping applied to the filter context (includes overflow clipping on the
renderer itself, but not clips from ancestors), and clipping applied when
drawing the filter context to the outer context (clips from ancestors, but not
the local clip).
Remove clipToDirtyRect entirely, since the only remaining caller is LBSE (and
manually running clipping tests with that shows no regressions).
* LayoutTests/TestExpectations:
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::requiresFullLayerImageForFilters const):
(WebCore::RenderLayer::paintLayerWithEffects):
(WebCore::RenderLayer::setupFilters):
(WebCore::RenderLayer::paintLayerContents):
(WebCore::RenderLayer::collectFragments):
(WebCore::RenderLayer::paintTransformedLayerIntoFragments):
(WebCore::RenderLayer::verifyClipRect):
(WebCore::RenderLayer::updateClipRects):
(WebCore::RenderLayer::calculateClipRects const):
* Source/WebCore/rendering/RenderLayer.h:
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::computeClippedOverlapBounds const):
(WebCore::RenderLayerCompositor::clippedByAncestor const):
(WebCore::RenderLayerCompositor::computeAncestorClippingStack const):
* Source/WebCore/rendering/RenderTreeAsText.cpp:
(WebCore::writeLayers):
Canonical link: https://commits.webkit.org/296844@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
