Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: abfc2c72e8c87ea514c05336cbdcef456ada63e4
https://github.com/WebKit/WebKit/commit/abfc2c72e8c87ea514c05336cbdcef456ada63e4
Author: Antoine Quint <[email protected]>
Date: 2026-02-24 (Tue, 24 Feb 2026)
Changed paths:
M Source/WebCore/animation/AcceleratedEffectStackUpdater.cpp
M Source/WebCore/animation/AcceleratedEffectStackUpdater.h
M Source/WebCore/style/Styleable.h
Log Message:
-----------
Cherry-pick 307912@main (1415c430401b).
https://bugs.webkit.org/show_bug.cgi?id=308132
[threaded-animations] running Jetstream on iOS crashes under
`AcceleratedEffectStackUpdater::update()`
https://bugs.webkit.org/show_bug.cgi?id=308132
rdar://170636362
Reviewed by Ryosuke Niwa and Tim Nguyen.
Use `WeakStyleable` for the `HashSet` holding the targets pending an update
in `AcceleratedEffectStackUpdater`.
No new layout test but this issue was caught by Apple's automated
performance testing infrastructure.
* Source/WebCore/animation/AcceleratedEffectStackUpdater.cpp:
(WebCore::AcceleratedEffectStackUpdater::update):
(WebCore::AcceleratedEffectStackUpdater::scheduleUpdateForTarget):
* Source/WebCore/animation/AcceleratedEffectStackUpdater.h:
* Source/WebCore/style/Styleable.h:
(WebCore::WeakStyleableHashTraits::isWeakNullValue):
(WebCore::WeakStyleableHashTraits::constructDeletedValue):
(WebCore::WeakStyleableHashTraits::isDeletedValue):
(WebCore::WeakStyleableHash::hash):
(WebCore::WeakStyleableHash::equal):
Canonical link: https://commits.webkit.org/307912@main
Canonical link: https://commits.webkit.org/305877.95@webkitglib/2.52
Commit: 533ba9d7ce6c3824928edd2f48bb6384bd687bc8
https://github.com/WebKit/WebKit/commit/533ba9d7ce6c3824928edd2f48bb6384bd687bc8
Author: Fady Farag <[email protected]>
Date: 2026-02-24 (Tue, 24 Feb 2026)
Changed paths:
M Source/WebCore/svg/properties/SVGAnimationAdditiveListFunction.h
Log Message:
-----------
Cherry-pick 307876@main (eaa750d6361f).
https://bugs.webkit.org/show_bug.cgi?id=308250
Address Use-After-Move in svg/properties/SVGAnimationAdditiveListFunction
https://bugs.webkit.org/show_bug.cgi?id=308250
rdar://170757240
Reviewed by Chris Dumez and Darin Adler.
* Source/WebCore/svg/properties/SVGAnimationAdditiveListFunction.h:
(WebCore::SVGAnimationAdditiveListFunction::SVGAnimationAdditiveListFunction):
Canonical link: https://commits.webkit.org/307876@main
Canonical link: https://commits.webkit.org/305877.96@webkitglib/2.52
Commit: df1be82ddf503c0b92867771e36b693a381471b4
https://github.com/WebKit/WebKit/commit/df1be82ddf503c0b92867771e36b693a381471b4
Author: Simon Fraser <[email protected]>
Date: 2026-02-24 (Tue, 24 Feb 2026)
Changed paths:
M Source/WebCore/rendering/RenderLayerBacking.cpp
M Source/WebCore/rendering/RenderLayerBacking.h
Log Message:
-----------
Cherry-pick 307858@main (142b64feb347).
https://bugs.webkit.org/show_bug.cgi?id=308230
Null deref under RenderLayerBacking::updateOverflowControlsLayers()
https://bugs.webkit.org/show_bug.cgi?id=308230
rdar://150330340
Reviewed by Alan Baradlay.
Crash data suggest that we can hit a null de-ref under
`m_owningLayer.page().scrollingCoordinator()()`
in `RenderLayerBacking::updateOverflowControlsLayers()` when tearing down
the render tree.
Fix by avoid this call altogether. We know from the order in
`~RenderLayer()` that
we've always cleared the scrollable area before clearing the backing, thus
at teardown
this code will never hit `scrollableAreaScrollbarLayerDidChange()`. So add
a simpler
`clearOverflowControlsLayers()` to be called from `~RenderLayerBacking()`
that just
destroys the layers.
* Source/WebCore/rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::~RenderLayerBacking):
(WebCore::RenderLayerBacking::clearOverflowControlsLayers):
* Source/WebCore/rendering/RenderLayerBacking.h:
Canonical link: https://commits.webkit.org/307858@main
Canonical link: https://commits.webkit.org/305877.97@webkitglib/2.52
Commit: c35499564b18947f20c20849bf941d3c2a06aaf8
https://github.com/WebKit/WebKit/commit/c35499564b18947f20c20849bf941d3c2a06aaf8
Author: Yusuke Suzuki <[email protected]>
Date: 2026-02-24 (Tue, 24 Feb 2026)
Changed paths:
M Source/JavaScriptCore/runtime/ArrayConstructor.cpp
M Source/JavaScriptCore/runtime/ArrayPrototype.cpp
M Source/JavaScriptCore/runtime/JSArray.cpp
M Source/JavaScriptCore/runtime/ScopedArguments.cpp
Log Message:
-----------
Cherry-pick 307787@main (1f4abb51322e).
https://bugs.webkit.org/show_bug.cgi?id=308105
[JSC] A bit defensively adding DeferGC for Butterfly baking
https://bugs.webkit.org/show_bug.cgi?id=308105
rdar://170604854
Reviewed by Keith Miller.
Baking Butterfly is really complex. Butterfly itself is kept via GC.
But Butterfly elements are not scanned until it gets connected to owner
JSObject. This means that createWithButterfly function requires extra
care since we do GC for owner cell allocation, thus, we need to ensure
that content of Butterfly is also kept alive by someone. Currently, all
of JSArray::createWithButterfly's butterfly contents are copied from
some other objects, thus this object should keep them alive. But in some
cases like clang optimization for tail call to
JSArray::createWithButterfly, there is theoretical possibility that this
owner object is no longer kept when creating JSArray because it was the
last use. And in this case, we may destroy the content of these
butterflies. We are not 100% sure whether this can happen. But let's a
bit defensive against the current use by adding DeferGC to ensure that
we will not invoke GC for JSArray::createWithButterfly's owner cell
creation.
* Source/JavaScriptCore/runtime/ArrayConstructor.cpp:
(JSC::fastArrayOf):
(JSC::tryCreateArrayFromArguments):
(JSC::tryCreateArrayFromSet):
(JSC::tryCreateArrayFromMapIterator):
* Source/JavaScriptCore/runtime/ArrayPrototype.cpp:
(JSC::concatAppendArray):
* Source/JavaScriptCore/runtime/JSArray.cpp:
(JSC::JSArray::fastToReversed):
(JSC::JSArray::fastWith):
(JSC::JSArray::fastToSpliced):
(JSC::JSArray::fastSlice):
(JSC::tryCloneArrayFromFast):
(JSC::JSArray::fastFlat):
* Source/JavaScriptCore/runtime/ScopedArguments.cpp:
(JSC::ScopedArguments::fastSlice):
Canonical link: https://commits.webkit.org/307787@main
Canonical link: https://commits.webkit.org/305877.98@webkitglib/2.52
Commit: 18b9419d1bc3967ab14296cc3be28a9715d36288
https://github.com/WebKit/WebKit/commit/18b9419d1bc3967ab14296cc3be28a9715d36288
Author: Antoine Quint <[email protected]>
Date: 2026-02-24 (Tue, 24 Feb 2026)
Changed paths:
M Source/WebCore/animation/StyleOriginatedTimelinesController.cpp
Log Message:
-----------
Cherry-pick 307765@main (941c6f6db964).
https://bugs.webkit.org/show_bug.cgi?id=308128
[scroll-animations] crash under
`StyleOriginatedTimelinesController::unregisterNamedTimeline()`
https://bugs.webkit.org/show_bug.cgi?id=308128
rdar://170552068
Reviewed by Sam Weinig.
The `StyleOriginatedTimelinesController` class has the following member:
HashMap<AtomString, Vector<Ref<ScrollTimeline>>> m_nameToTimelineMap;
In that class's `unregisterNamedTimeline()` method we do a lookup to land on
one of the timelines held in this map and then proceed to do the following:
auto timeline = timelines.at(i);
// Make sure to remove the named timeline from our name-to-timelines
map first,
// such that re-syncing any CSS Animation previously registered with it
resolves
// their `animation-timeline` properly.
timelines.removeAt(i);
Since `Vector::at(size_t)` returns a `T&`, we're getting a `Ref&` for
`timeline`, and thus
the following call to `timelines.removeAt(i)` will remove that reference
from the map. We must
make sure to create a new counted reference to not fall into a case where
that map held the
last reference to that timeline.
This is a tentative crash fix and I do not have a test case to go with it.
* Source/WebCore/animation/StyleOriginatedTimelinesController.cpp:
(WebCore::StyleOriginatedTimelinesController::unregisterNamedTimeline):
Canonical link: https://commits.webkit.org/307765@main
Canonical link: https://commits.webkit.org/305877.99@webkitglib/2.52
Commit: 1d30181d64aa08fec39f72eebea06da1619b557b
https://github.com/WebKit/WebKit/commit/1d30181d64aa08fec39f72eebea06da1619b557b
Author: Yulun Wu <[email protected]>
Date: 2026-02-24 (Tue, 24 Feb 2026)
Changed paths:
A
LayoutTests/fast/replaced/image-percent-sizing-in-inline-block-expected.html
A LayoutTests/fast/replaced/image-percent-sizing-in-inline-block.html
M Source/WebCore/rendering/RenderReplaced.cpp
Log Message:
-----------
Cherry-pick 307751@main (6b3a23bbdc75).
https://bugs.webkit.org/show_bug.cgi?id=308080
[Render Replaced][youtube.com] Resolve percentage height for aspect ratio
adjusted widths.
https://bugs.webkit.org/show_bug.cgi?id=308080
<rdar://170270187>
Reviewed by Alan Baradlay.
This PR resolves percentage/calc heights for RenderImage when the used
(min, max, intrinsic)
height can be computed.
This fixes a bug where youtube.com shop ads were being rendered with
stretched images
because of incorrect logical widths.
*
LayoutTests/fast/replaced/image-percent-sizing-in-inline-block-expected.html:
Added.
* LayoutTests/fast/replaced/image-percent-sizing-in-inline-block.html:
Added.
* Source/WebCore/rendering/RenderReplaced.cpp:
(WebCore::RenderReplaced::paint):
Canonical link: https://commits.webkit.org/307751@main
Canonical link: https://commits.webkit.org/305877.100@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/0e539cf54fb8...1d30181d64aa
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
