Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: f90bc16a71273a5be921341032e48bb5bf5bc91d
https://github.com/WebKit/WebKit/commit/f90bc16a71273a5be921341032e48bb5bf5bc91d
Author: Simon Fraser <[email protected]>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/blur-clip-border-radius-expected.html
A
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/blur-clip-border-radius-ref.html
A
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/blur-clip-border-radius.html
A
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/grayscale-clip-border-radius-expected.html
A
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/grayscale-clip-border-radius-ref.html
A
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/grayscale-clip-border-radius.html
M LayoutTests/platform/gtk/TestExpectations
M Source/WebCore/platform/graphics/GraphicsContextSwitcher.h
M Source/WebCore/platform/graphics/ImageBufferContextSwitcher.cpp
M Source/WebCore/platform/graphics/ImageBufferContextSwitcher.h
M Source/WebCore/platform/graphics/TransparencyLayerContextSwitcher.cpp
M Source/WebCore/platform/graphics/TransparencyLayerContextSwitcher.h
M Source/WebCore/rendering/RenderLayer.cpp
M Source/WebCore/rendering/RenderLayer.h
M Source/WebCore/rendering/RenderLayerFilters.cpp
M Source/WebCore/rendering/RenderLayerFilters.h
Log Message:
-----------
Cherry-pick 313267@main (b8414eccb3b1).
https://bugs.webkit.org/show_bug.cgi?id=312584
REGRESSION (303819@main): Child with filter:blur() ignores border radius
overflow clipping
https://bugs.webkit.org/show_bug.cgi?id=312584
rdar://175519148
Reviewed by Said Abou-Hallawa.
When using the TransparencyLayerContextSwitcher path for filters, we need
to be able
to supply a complex clip for items clipped by border-radius on ancestors;
this
requires running the code in `applyAncestorClippingForBorderRadius()` after
saving the graphics state, before starting the transparency layer, so factor
the code to allow this by passing a function to GraphicsContextSwitcher.
The previous attempt to fix this (312531@main) was reverted for causing
rendering
regressions of youtube buttons and on wayfair.com; this turned out to be a
Core Graphics
accelerated rendering bug (rdar://177036180) which we work around by
applying the
rounded clip in an outer transparency layer.
`grayscale-clip-border-radius.html` tests
this workaround.
Tests:
imported/w3c/web-platform-tests/css/filter-effects/blur-clip-border-radius-ref.html
imported/w3c/web-platform-tests/css/filter-effects/blur-clip-border-radius.html
imported/w3c/web-platform-tests/css/filter-effects/grayscale-clip-border-radius-ref.html
imported/w3c/web-platform-tests/css/filter-effects/grayscale-clip-border-radius.html
*
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/blur-clip-border-radius-expected.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/blur-clip-border-radius-ref.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/blur-clip-border-radius.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/grayscale-clip-border-radius-expected.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/grayscale-clip-border-radius-ref.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/filter-effects/grayscale-clip-border-radius.html:
Added.
* Source/WebCore/platform/graphics/GraphicsContextSwitcher.h:
(WebCore::GraphicsContextSwitcher::beginClipAndDrawSourceImage):
* Source/WebCore/platform/graphics/ImageBufferContextSwitcher.cpp:
(WebCore::ImageBufferContextSwitcher::beginClipAndDrawSourceImage):
* Source/WebCore/platform/graphics/ImageBufferContextSwitcher.h:
* Source/WebCore/platform/graphics/TransparencyLayerContextSwitcher.cpp:
(WebCore::TransparencyLayerContextSwitcher::beginClipAndDrawSourceImage):
(WebCore::TransparencyLayerContextSwitcher::endDrawSourceImage):
* Source/WebCore/platform/graphics/TransparencyLayerContextSwitcher.h:
* Source/WebCore/rendering/RenderLayer.cpp:
(WebCore::RenderLayer::clipToRect):
(WebCore::RenderLayer::applyAncestorClippingForBorderRadius):
(WebCore::RenderLayer::setupFilters):
* Source/WebCore/rendering/RenderLayer.h:
* Source/WebCore/rendering/RenderLayerFilters.cpp:
(WebCore::RenderLayerFilters::beginFilterEffect):
* Source/WebCore/rendering/RenderLayerFilters.h:
Canonical link: https://commits.webkit.org/313267@main
Canonical link: https://commits.webkit.org/305877.666@webkitglib/2.52
Commit: 3c9f9621a696c36bf1098993b19980f0f840fd2a
https://github.com/WebKit/WebKit/commit/3c9f9621a696c36bf1098993b19980f0f840fd2a
Author: Wenson Hsieh <[email protected]>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
A LayoutTests/fast/text-extraction/max-recursion-depth-cap-expected.html
A LayoutTests/fast/text-extraction/max-recursion-depth-cap.html
M Source/WebCore/page/text-extraction/TextExtraction.cpp
Log Message:
-----------
Cherry-pick 313243@main (26970a5ac7ec).
https://bugs.webkit.org/show_bug.cgi?id=314772
Web process sometimes crashes with excessive stack depth in
TextExtraction::extractRecursive
https://bugs.webkit.org/show_bug.cgi?id=314772
rdar://177009329
Reviewed by Abrar Rahman Protyasha.
Add a couple of mitigations to prevent crashes due to excessive stack depth:
- Avoid ever re-traversing the same element (which is theoretically
possible if layout is
triggered in the middle of recursive extraction).
- Enforce a maximum traversal depth and bail early if the stack grows too
deep.
Test: fast/text-extraction/max-recursion-depth-cap.html
* LayoutTests/fast/text-extraction/max-recursion-depth-cap-expected.html:
Added.
* LayoutTests/fast/text-extraction/max-recursion-depth-cap.html: Added.
* Source/WebCore/page/text-extraction/TextExtraction.cpp:
(WebCore::TextExtraction::extractRecursive):
Canonical link: https://commits.webkit.org/313243@main
Canonical link: https://commits.webkit.org/305877.667@webkitglib/2.52
Commit: f18d440eaafe7b9b9f4cdb7aa6ab598072b27a1e
https://github.com/WebKit/WebKit/commit/f18d440eaafe7b9b9f4cdb7aa6ab598072b27a1e
Author: Enrique Ocaña González <[email protected]>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp
Log Message:
-----------
Cherry-pick 308552@main (de98f6bb5014).
https://bugs.webkit.org/show_bug.cgi?id=308969
[GStreamer] Expose VIDEO_DECODING_LIMIT through an environment variable
https://bugs.webkit.org/show_bug.cgi?id=308969
Reviewed by Alicia Boya Garcia and Xabier Rodriguez-Calvar.
The RDK-E downstream platform would like to have a single unified build
for many kind of devices. For that reason, the platform compile-time
VIDEO_DECODING_LIMIT restriction aren't appropriate anymore, since the
same build can be used for devices with different runtime limits. A way
to specify the decoding limit ar runtime would be desirable.
An environment variable looks like a better way to do it than a runtime
setting, since the limit is unlikely to change at runtime and likely to
change per device (with a value consistent on every execution).
Moreover, having a setting would mean extra changes in the dependent
packages that embed WebKit, while having en environmente variable would
be less intrusive and would only mean a change in the (easier to
maintain) startup scripts.
This change adds WEBKIT_GST_VIDEO_DECODING_LIMIT env on top of
VIDEO_DECODING_LIMIT compile time option to limit video decoding
capabilities. WEBKIT_GST_VIDEO_DECODING_LIMIT can now be set in runtime
and it takes precedence over compile time definition
VIDEO_DECODING_LIMIT.
See: https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1625
https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1626
Original author: Andrzej Surdej <[email protected]>
* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
(videoDecoderLimitsDefaults): Deleted.
* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
(WebCore::parseVideoDecodingLimit): Use a StringView to prevent extra
copies.
(WebCore::resolveVideoDecodingLimits): Decide the right decoding limits
considering the build time option and the environment variable value.
(WebCore::GStreamerRegistryScanner::isContentTypeSupported const): Parse
env var and only require the build ifdefs when strictly needed.
(videoDecoderLimitsDefaults): Deleted.
Canonical link: https://commits.webkit.org/308552@main
Canonical link: https://commits.webkit.org/305877.668@webkitglib/2.52
Commit: ae3eaacd1b2d0ca42cb15da8eddbefbda9288843
https://github.com/WebKit/WebKit/commit/ae3eaacd1b2d0ca42cb15da8eddbefbda9288843
Author: Enrique Ocaña González <[email protected]>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
M Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp
Log Message:
-----------
Cherry-pick 309507@main (a8e8ac33b298).
https://bugs.webkit.org/show_bug.cgi?id=310192
[GStreamer] Respect video decoding limits in MediaCapa:bilites queries
https://bugs.webkit.org/show_bug.cgi?id=310192
Reviewed by Xabier Rodriguez-Calvar.
The video decoding limits were only had into account in
supportsFeatures() so far. They should also be enforced by the
GStreamerRegistryScanner in isConfigurationSupported() as well.
See: https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1639
This change checks the limits from isConfigurationSupported(), so it's
enforced from MediaCapabilities queries.
Original author: Andrzej Surdej (https://github.com/asurdej-comcast)
* Source/WebCore/platform/graphics/gstreamer/GStreamerRegistryScanner.cpp:
(WebCore::GStreamerRegistryScanner::isConfigurationSupported const): Check
the video decoding limits.
Canonical link: https://commits.webkit.org/309507@main
Canonical link: https://commits.webkit.org/305877.669@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/6e35a4f5513a...ae3eaacd1b2d
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
