Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 9750e8274bd1b8565a9b94b3ad5125b67ee0ed40
https://github.com/WebKit/WebKit/commit/9750e8274bd1b8565a9b94b3ad5125b67ee0ed40
Author: Youenn Fablet <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
A LayoutTests/http/wpt/webcodecs/frame-clone-and-convert-expected.txt
A LayoutTests/http/wpt/webcodecs/frame-clone-and-convert.html
M Source/WebCore/platform/mediastream/libwebrtc/VideoFrameLibWebRTC.cpp
M Source/WebCore/platform/mediastream/libwebrtc/VideoFrameLibWebRTC.h
Log Message:
-----------
Cherry-pick 316112@main (e7f7480061c3).
https://bugs.webkit.org/show_bug.cgi?id=313917
[WebCore] Data race on VideoFrameLibWebRTC::m_conversionCallback between
clone and pixelBuffer causes use-after-free
rdar://175482151
Reviewed by Jean-Yves Avenard.
We add a thread annotation to make sure the conversion callback cannot be
modified without the pixel buffer lock.
We update VideoFrameLibWebRTC::clone so that it holds the pixel buffer lock
to ensure it gets a correct conversion callback.
We also copy the pixel buffer with a lock, as it could be null on the
cloned video frame if the conversion callback has already been called.
Covered by LayoutTests/http/wpt/webcodecs/frame-clone-and-convert.html,
which does the following:
1. Create a LibWebRTC VideoFrame.
2. Encode it using VP8 so that the VideoFrame pixelBuffer method is
executed in a background queue.
3. In parallel, clone the VideoFrame to exercice the racy code path and
encode the cloned frame.
* LayoutTests/http/wpt/webcodecs/frame-clone-and-convert-expected.txt:
Added.
* LayoutTests/http/wpt/webcodecs/frame-clone-and-convert.html: Added.
* Source/WebCore/platform/mediastream/libwebrtc/VideoFrameLibWebRTC.cpp:
(WebCore::VideoFrameLibWebRTC::clone):
* Source/WebCore/platform/mediastream/libwebrtc/VideoFrameLibWebRTC.h:
Originally-landed-as: 305413.760@safari-7624-branch (f4c62c374952).
rdar://180436627
Canonical link: https://commits.webkit.org/316112@main
Canonical link: https://commits.webkit.org/305877.990@webkitglib/2.52
Commit: 9ae58bc021e6f1accb635634cc2b706d698b100d
https://github.com/WebKit/WebKit/commit/9ae58bc021e6f1accb635634cc2b706d698b100d
Author: Philippe Normand <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp
Log Message:
-----------
Cherry-pick 316053@main (abc2312528f8).
https://bugs.webkit.org/show_bug.cgi?id=317971
[WPE] media/media-source/media-source-real-play-after-eos.html is crashing
https://bugs.webkit.org/show_bug.cgi?id=317971
Reviewed by Alicia Boya Garcia and Xabier Rodriguez-Calvar.
Remove the assert on caps event push result otherwise we can get racy
crashes on post-commit bots
when a flush-start event is pushed downstream from another thread just
before a caps change has to
be notified.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
*
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:
(webKitMediaSrcLoop):
Canonical link: https://commits.webkit.org/316053@main
Canonical link: https://commits.webkit.org/305877.991@webkitglib/2.52
Commit: 599adacf7ce052864ad665a05e3a8a2c440eb907
https://github.com/WebKit/WebKit/commit/599adacf7ce052864ad665a05e3a8a2c440eb907
Author: Ahmad Saleem <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M Source/WebCore/platform/graphics/FontCascadeCache.h
Log Message:
-----------
Cherry-pick 316102@main (97d2c63b0b2b).
https://bugs.webkit.org/show_bug.cgi?id=318056
FontCascadeCacheKey has uninitialized fontSelectorId and
fontSelectorVersion members
https://bugs.webkit.org/show_bug.cgi?id=318056
rdar://180838174
Reviewed by Dan Glastonbury.
Add { 0 } initializers to both members to match the rest of the struct and
guarantee defined values for all default-constructed keys.
* Source/WebCore/platform/graphics/FontCascadeCache.h:
Canonical link: https://commits.webkit.org/316102@main
Canonical link: https://commits.webkit.org/305877.992@webkitglib/2.52
Commit: 0df5dc7316e2c527a873f6d1301e3af55f587bab
https://github.com/WebKit/WebKit/commit/0df5dc7316e2c527a873f6d1301e3af55f587bab
Author: Chris Dumez <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M Source/WebCore/page/ResourceUsageThread.cpp
M Source/WebCore/page/ResourceUsageThread.h
Log Message:
-----------
Cherry-pick 316090@main (ccf04bde4757).
https://bugs.webkit.org/show_bug.cgi?id=318087
ResourceUsageThread reads m_collectionMode off-thread without holding its
lock
https://bugs.webkit.org/show_bug.cgi?id=318087
Reviewed by Darin Adler.
m_collectionMode is written by recomputeCollectionMode() while holding
m_observersLock
(from addObserver()/removeObserver() on the main thread), but the dedicated
resource-usage
sampling thread read it in threadBody() without acquiring the lock.
waitUntilObservers()
releases the lock before threadBody() reaches the read, so the locked
main-thread write and
the unlocked background-thread read could run concurrently on a non-atomic
variable, which is
a data race / undefined behavior. The field was also not annotated, so
Clang's thread-safety
analysis could not catch the unguarded access.
Synchronize m_collectionMode with the same lock that already guards the
m_observers set it is
derived from: annotate it WTF_GUARDED_BY_LOCK(m_observersLock) so unguarded
accesses become a
build error, and read it under a short Locker scope in threadBody()
(without holding the lock
across the platformCollect* calls). recomputeCollectionMode() now
accumulates into a local and
performs a single store, which it already does under the lock.
* Source/WebCore/page/ResourceUsageThread.cpp:
(WebCore::ResourceUsageThread::recomputeCollectionMode):
(WebCore::ResourceUsageThread::threadBody):
* Source/WebCore/page/ResourceUsageThread.h:
(WebCore::ResourceUsageThread::WTF_GUARDED_BY_LOCK):
Canonical link: https://commits.webkit.org/316090@main
Canonical link: https://commits.webkit.org/305877.993@webkitglib/2.52
Commit: 3da834c0f1e96095f3d002977217467d139177ef
https://github.com/WebKit/WebKit/commit/3da834c0f1e96095f3d002977217467d139177ef
Author: Ahmad Saleem <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/multiline-last-baseline-item-count-expected.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/multiline-last-baseline-item-count-ref.html
A
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/multiline-last-baseline-item-count.html
M Source/WebCore/rendering/RenderFlexibleBox.cpp
Log Message:
-----------
Cherry-pick 316027@main (bcc89c676083).
https://bugs.webkit.org/show_bug.cgi?id=318069
Fix typo in RenderFlexibleBox::performFlexLayout(): last-line item count
read from first line
https://bugs.webkit.org/show_bug.cgi?id=318069
rdar://180869111
Reviewed by Alan Baradlay.
lastLineItemsCountInOriginalOrder was initialized from lineStates.first()
instead of lineStates.last() — a copy/paste typo from the line above. This
patch fixes it.
When the first and last lines of a wrapping flex container have a different
number of items, the count used to locate the container's last baseline was
wrong, so the baseline was taken from a baseline-aligned item on the first
line instead of an item on the last line. Added a reftest covering this case
(first line: two items, last line: one item); it failed before this change
and matches Chrome and Firefox now.
* Source/WebCore/rendering/RenderFlexibleBox.cpp:
(WebCore::RenderFlexibleBox::performFlexLayout):
*
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/multiline-last-baseline-item-count-expected.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/multiline-last-baseline-item-count-ref.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/multiline-last-baseline-item-count.html:
Added.
Canonical link: https://commits.webkit.org/316027@main
Canonical link: https://commits.webkit.org/305877.994@webkitglib/2.52
Commit: cb03aede6c74e6011d875d2882c9ccb77fe8d571
https://github.com/WebKit/WebKit/commit/cb03aede6c74e6011d875d2882c9ccb77fe8d571
Author: Ahmad Saleem <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M Source/WebCore/platform/graphics/ImageBuffer.cpp
Log Message:
-----------
Cherry-pick 315982@main (9ca4025a7330).
https://bugs.webkit.org/show_bug.cgi?id=318049
ImageBuffer::transferToNewContext() can null-deref backend()
https://bugs.webkit.org/show_bug.cgi?id=318049
rdar://180836227
Reviewed by Kimmo Kinnunen.
ImageBuffer::transferToNewContext() was the only method in ImageBuffer
that dereferenced backend() raw, while every sibling method guards with
`if (auto* backend = ensureBackend())`. Its sole caller,
RemoteRenderingBackend::moveToImageBuffer(), operates on a serialized
ImageBuffer taken from the resource cache. Backend allocation can
legitimately fail (size limits / OOM), leaving a live ImageBuffer whose
m_backend is null, so transferToNewContext() would null-deref.
Guard the access with ensureBackend(), matching the established pattern
used throughout ImageBuffer. When there is no backend there is nothing
to transfer, so skipping the call is correct.
* Source/WebCore/platform/graphics/ImageBuffer.cpp:
(WebCore::ImageBuffer::transferToNewContext):
Canonical link: https://commits.webkit.org/315982@main
Canonical link: https://commits.webkit.org/305877.995@webkitglib/2.52
Commit: 15f1bb526e04a337a0be8c6ca18fa5ee24414319
https://github.com/WebKit/WebKit/commit/15f1bb526e04a337a0be8c6ca18fa5ee24414319
Author: Ahmad Saleem <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M Source/WebCore/platform/graphics/ImageBuffer.h
Log Message:
-----------
Cherry-pick 315980@main (0a98e10bf354).
https://bugs.webkit.org/show_bug.cgi?id=317998
ImageBuffer::hasBackend() should be const
https://bugs.webkit.org/show_bug.cgi?id=317998
rdar://180785695
Reviewed by Kimmo Kinnunen.
ImageBuffer::hasBackend() only calls backend(), which is already a const
member function, so the method can be const itself. Mark it const for
const-correctness.
* Source/WebCore/platform/graphics/ImageBuffer.h:
(WebCore::ImageBuffer::hasBackend const):
(WebCore::ImageBuffer::hasBackend): Deleted.
Canonical link: https://commits.webkit.org/315980@main
Canonical link: https://commits.webkit.org/305877.996@webkitglib/2.52
Commit: ce741651319d46f201b9413796a451842efe180a
https://github.com/WebKit/WebKit/commit/ce741651319d46f201b9413796a451842efe180a
Author: Tim Horton <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M Source/WebCore/page/LocalFrameView.cpp
Log Message:
-----------
Cherry-pick 315876@main (3ca64a2480fa).
https://bugs.webkit.org/show_bug.cgi?id=317908
Rare null derefs under LocalFrameView::textFragmentIndicatorTimerFired()
https://bugs.webkit.org/show_bug.cgi?id=317908
rdar://180240279
Reviewed by Abrar Rahman Protyasha.
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::textFragmentIndicatorTimerFired):
Keep a local copy of m_pendingTextFragmentIndicatorRange when calling into
plainText(), because plainText() does layout, which can in turn result in
m_pendingTextFragmentIndicatorRange being reset, subsequently causing a
null deref.
Canonical link: https://commits.webkit.org/315876@main
Canonical link: https://commits.webkit.org/305877.997@webkitglib/2.52
Commit: 9e3bb9c3cd58dec94a4e1db35e0b18faffad65eb
https://github.com/WebKit/WebKit/commit/9e3bb9c3cd58dec94a4e1db35e0b18faffad65eb
Author: Jessica Lee <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M Source/WebCore/page/Navigation.cpp
Log Message:
-----------
Cherry-pick 315855@main (e505d4781740).
https://bugs.webkit.org/show_bug.cgi?id=317805
Null-check window in Navigation::hasEntriesAndEventsDisabled()
https://bugs.webkit.org/show_bug.cgi?id=317805
rdar://180575315
Reviewed by Basuke Suzuki.
There is a possibility that this->window() could be null when
Navigation::hasEntriesAndEventsDisabled(). Add a null-check.
No new tests needed.
* Source/WebCore/page/Navigation.cpp:
(WebCore::Navigation::hasEntriesAndEventsDisabled const):
Canonical link: https://commits.webkit.org/315855@main
Canonical link: https://commits.webkit.org/305877.998@webkitglib/2.52
Commit: b22fc77eb6521f20452c5624e9c8714a091b4e88
https://github.com/WebKit/WebKit/commit/b22fc77eb6521f20452c5624e9c8714a091b4e88
Author: Anand Srinivasan <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
A JSTests/stress/array-prototype-flat-reentrant-mutation.js
M Source/JavaScriptCore/runtime/JSArray.cpp
Log Message:
-----------
Cherry-pick 315760@main (77c66694dfbc).
https://bugs.webkit.org/show_bug.cgi?id=317695
Check if JSArray::fastFlat exceeds maximum legal length
https://bugs.webkit.org/show_bug.cgi?id=317695
rdar://178997662
Reviewed by Sosuke Suzuki and Yusuke Suzuki.
JSC::JSArray::fastFlat crashes if the flattened array exceeds the
maximum length of the vector holding it. This patch changes it to return
null and bail out to the slow path in JSC::arrayProtoFuncFlat instead of
crashing.
Test: JSTests/stress/array-prototype-flat-reentrant-mutation.js
* JSTests/stress/array-prototype-flat-reentrant-mutation.js: Added.
(try.array.Symbol.iterator):
(catch):
* Source/JavaScriptCore/runtime/JSArray.cpp:
(JSC::JSArray::fastFlat):
Canonical link: https://commits.webkit.org/315760@main
Canonical link: https://commits.webkit.org/305877.999@webkitglib/2.52
Commit: bce8040a062cf5d1ab6671eff036ac3e7f833d06
https://github.com/WebKit/WebKit/commit/bce8040a062cf5d1ab6671eff036ac3e7f833d06
Author: Nipun Shukla <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
A LayoutTests/fast/dom/MutationObserver/no-document-leak-expected.txt
A LayoutTests/fast/dom/MutationObserver/no-document-leak.html
A
LayoutTests/fast/dom/MutationObserver/resources/no-document-leak-frame.html
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/WindowEventLoop.cpp
M Source/WebCore/dom/WindowEventLoop.h
Log Message:
-----------
Cherry-pick 315752@main (cffe1bb49663).
https://bugs.webkit.org/show_bug.cgi?id=317618
Document leak in MutationObserver
https://bugs.webkit.org/show_bug.cgi?id=317618
rdar://178665935
Reviewed by Chris Dumez.
Previously, stopping a document didn't remove its MutationObservers from
the shared WindowEventLoop's observer sets, so an observer left parked there
with a pending mutation record keeps its target nodes, and therefore the
whole document, alive forever.
This is resolved by draining a stopped context's MutationObservers from
those
sets in Document::stopActiveDOMObjects().
Test: fast/dom/MutationObserver/no-document-leak.html
* LayoutTests/fast/dom/MutationObserver/no-document-leak-expected.txt:
Added.
* LayoutTests/fast/dom/MutationObserver/no-document-leak.html: Added.
*
LayoutTests/fast/dom/MutationObserver/resources/no-document-leak-frame.html:
Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::stopActiveDOMObjects):
* Source/WebCore/dom/WindowEventLoop.cpp:
(WebCore::WindowEventLoop::removeMutationObserversForContext):
* Source/WebCore/dom/WindowEventLoop.h:
Canonical link: https://commits.webkit.org/315752@main
Canonical link: https://commits.webkit.org/305877.1000@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/2ffc0136fa8b...bce8040a062c
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
