Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 9bb8e6006c96b6ef224b0b7b836dbe50fd527674
https://github.com/WebKit/WebKit/commit/9bb8e6006c96b6ef224b0b7b836dbe50fd527674
Author: Matthew Finkel <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/Navigation.mm
Log Message:
-----------
Cherry-pick 315043@main (39679d6a6e43).
https://bugs.webkit.org/show_bug.cgi?id=316066
Partitioned cookies may not be sent on resource requests
https://bugs.webkit.org/show_bug.cgi?id=316066
rdar://175507450
Reviewed by Charlie Wolfe.
There is a problem with how we compute and synchronize across processes the
preference's state that controls whether partitioned cookies are enabled.
There
is a case where we can erroneously disable partitioned cookies if we are in
a
situation where we don't have any WebPageProxy, but we have an active
provisional load. That gap may result in some resource requests where a
partitioned cookie is absent.
The current behavior relies on a WebPageProxy existing. This patch resolves
that issue, and a couple others, by calling propagateSettingUpdates() when a
page is added or removed from a WebsiteDataStore, and immediately after a
network process is created.
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:
(WebKit::WebsiteDataStore::networkProcess):
(WebKit::WebsiteDataStore::addPage):
(WebKit::WebsiteDataStore::removePage):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/Navigation.mm:
(TEST(WKNavigation, PartitionedCookieSentOnTopLevelRedirect)):
(TEST(WKNavigation,
PartitionedCookieSentWhenNetworkProcessExistsBeforePage)):
(TEST(WKNavigation, PartitionedCookieAfterRedirect)):
Canonical link: https://commits.webkit.org/315043@main
Canonical link: https://commits.webkit.org/305877.764@webkitglib/2.52
Commit: 3dfa3aa802ac3a4c05f6bbca536ac50549e770ca
https://github.com/WebKit/WebKit/commit/3dfa3aa802ac3a4c05f6bbca536ac50549e770ca
Author: Sihui Liu <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/html/HTMLMediaElement.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebsitePolicies.mm
A Tools/TestWebKitAPI/Tests/WebKitCocoa/autoplay-quirk-pause-fires-once.html
Log Message:
-----------
Cherry-pick 314984@main (412a8234329f).
https://bugs.webkit.org/show_bug.cgi?id=316746
Prevent re-entrant calls to dispatchPlayPauseEventsIfNeedsQuirks()
https://bugs.webkit.org/show_bug.cgi?id=316746
rdar://179191475
Reviewed by Ryosuke Niwa.
dispatchPlayPauseEventsIfNeedsQuirks() dispatches synthesized `playing` and
`pause` events to satisfy sites whose JS
player state machines rely on these events to detect that autoplay was
prevented (SynthesizedPauseEvents), or to
recover after being restored from the back/forward cache (rdar://68938833).
The function was not re-entrant-safe because a common JS pattern is to call
video.play() from a `pause` event handler to
retry playback. When autoplay was blocked, the sequence was:
1. setAutoplayEventPlaybackState(PreventedAutoplay) =>
dispatchPlayPauseEventsIfNeedsQuirks() // schedule playing +
pause events
2. `pause` event fires, JS handler calls video.play() // autoplay blocked
again
3. setAutoplayEventPlaybackState(PreventedAutoplay) =>
dispatchPlayPauseEventsIfNeedsQuirks() // schedule playing +
pause events again, and cause infinite loop
This can produce hundreds of log entries per millisecond and could trigger
logd's per-process quarantine on affected
pages. To fix this, this patch adds a bool guard
m_isDispatchingAutoplayPlayPauseQuirkEvents and consolidates two
scheduleEvent() calls into a single queued task that ispatches both events
synchronously via dispatchEvent(). A
SetForScope sets the guard for the duration of the task, covering the
entire JS execution window. Any re-entrant call to
dispatchPlayPauseEventsIfNeedsQuirks() during that window — whether from
the `playing` or the `pause` handler — returns
immediately.
API Test: WebpagePreferences.WebsitePoliciesSynthesizedPauseEventFiresOnce
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::dispatchPlayPauseEventsIfNeedsQuirks):
* Source/WebCore/html/HTMLMediaElement.h:
* Tools/TestWebKitAPI/Resources/cocoa/autoplay-quirk-pause-fires-once.html:
Added.
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WebsitePolicies.mm:
(TEST(WebpagePreferences, WebsitePoliciesSynthesizedPauseEventFiresOnce)):
Canonical link: https://commits.webkit.org/314984@main
Canonical link: https://commits.webkit.org/305877.765@webkitglib/2.52
Commit: 194d83a90fe7ba39393b0eec9c1066b79ef596a5
https://github.com/WebKit/WebKit/commit/194d83a90fe7ba39393b0eec9c1066b79ef596a5
Author: Tyler Wilcock <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
A
LayoutTests/accessibility/aria-owns-crash-after-subtree-update-expected.txt
A LayoutTests/accessibility/aria-owns-crash-after-subtree-update.html
M Source/WebCore/accessibility/AXObjectCache.cpp
M Source/WebCore/accessibility/AccessibilityNodeObject.cpp
Log Message:
-----------
Cherry-pick 314865@main (5472527c2f96).
https://bugs.webkit.org/show_bug.cgi?id=316542
AX: In rare circumstances, WebKit can loop infinitely downstream of
updateOwnedChildrenIfNecessary(), causing stack overflow crashes
https://bugs.webkit.org/show_bug.cgi?id=316542
rdar://172763724
Reviewed by Dominic Mazzoni and Andres Gonzalez.
For a long while now, we have observed rare stack overflow crashes
originating from updateOwnedChildrenIfNecessary(). It's unclear how
these crashes are ocurring, since existing function relationCausesCycle
should (and does in all known situations) prevent an aria-owns
relationship from being established if it would cause a cycle.
The current theory is that these crashes happen when the tree is dirty and
in the process of being rebuilt after dynamic DOM changes (which may
introduce
cycles that relationCausesCycle didn't and couldn't possibly have
checked for at relations-creation time). But I haven't been able to
construct markup that actually reproduces this, including the new layout
test, which passes with and without the newly added guard (described below).
The speculative fix taken by this commit is the addition of a per-traversal
visited
set in updateOwnedChildrenIfNecessary, breaking if we encounter a node
we've already seen.
*
LayoutTests/accessibility/aria-owns-crash-after-subtree-update-expected.txt:
Added.
* LayoutTests/accessibility/aria-owns-crash-after-subtree-update.html:
Added.
* Source/WebCore/accessibility/AccessibilityNodeObject.cpp:
(WebCore::AccessibilityNodeObject::updateOwnedChildrenIfNecessary):
Canonical link: https://commits.webkit.org/314865@main
Canonical link: https://commits.webkit.org/305877.766@webkitglib/2.52
Commit: b0b779d817465f425cec02e725370251f2536409
https://github.com/WebKit/WebKit/commit/b0b779d817465f425cec02e725370251f2536409
Author: Chris Dumez <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M
Source/WebKit/WebProcess/Storage/WebSharedWorkerContextManagerConnection.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/CustomUserAgent.mm
Log Message:
-----------
Cherry-pick 314858@main (fbd2160cf1ac).
https://bugs.webkit.org/show_bug.cgi?id=316637
SharedWorker's navigator.userAgent ignores per-navigation _customUserAgent
https://bugs.webkit.org/show_bug.cgi?id=316637
Reviewed by Youenn Fablet.
WebSharedWorkerContextManagerConnection::launchSharedWorker() applied an
inverted user-agent fallback:
```
if (!initializationData.userAgent.isEmpty())
initializationData.userAgent = m_userAgent;
```
The intent (matching the parallel logic in WebSWContextManagerConnection's
installServiceWorker, which uses `if (effectiveUserAgent.isNull())`) is to
fall back to the host's m_userAgent only when the value supplied by the
network process is empty. The condition was negated, so a non-empty
page-supplied UA was overwritten by the host's default, while an empty UA
was left empty.
The page-level WKWebView.customUserAgent path masks the bug because
WebProcessPool::updateRemoteWorkerUserAgent pushes that UA to every remote-
worker host via
Messages::WebSharedWorkerContextManagerConnection::SetUserAgent,
keeping the host's m_userAgent in sync with the page UA so the buggy
assignment becomes a no-op. The bug is observable through any UA path that
does NOT round-trip through WebPageProxy::setUserAgent — most notably
WKWebpagePreferences._customUserAgent (per-navigation), which is stored on
the page's DocumentLoader and flows into WorkerScriptLoader::
userAgentForSharedWorker() but never updates the host process. In that
configuration the SharedWorker's navigator.userAgent reported the host's
standard UA instead of the per-navigation override.
Invert the condition so initializationData.userAgent is preserved when
non-empty and only filled in from m_userAgent when empty.
*
Source/WebKit/WebProcess/Storage/WebSharedWorkerContextManagerConnection.cpp:
(WebKit::WebSharedWorkerContextManagerConnection::launchSharedWorker):
Fall back to m_userAgent only when initializationData.userAgent is empty.
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/CustomUserAgent.mm:
(TEST(CustomUserAgent, SharedWorkerNavigatorUserAgent)):
Add a regression test that uses WKWebpagePreferences._customUserAgent so
the page UA diverges from the host's m_userAgent, and asserts that a
SharedWorker created from that page observes the per-navigation UA via
navigator.userAgent.
Canonical link: https://commits.webkit.org/314858@main
Canonical link: https://commits.webkit.org/305877.767@webkitglib/2.52
Commit: 8c84f914883d3389dea52e339f500a0e389d4e92
https://github.com/WebKit/WebKit/commit/8c84f914883d3389dea52e339f500a0e389d4e92
Author: Chris Dumez <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/WebCore/platform/graphics/Region.cpp
M Tools/TestWebKitAPI/Tests/WebCore/RegionTests.cpp
Log Message:
-----------
Cherry-pick 314594@main (5eacd591f79b).
https://bugs.webkit.org/show_bug.cgi?id=316188
Region::totalArea overflows when a single rect's area exceeds INT_MAX
https://bugs.webkit.org/show_bug.cgi?id=316188
Reviewed by Kimmo Kinnunen.
Region::totalArea() accumulates rect.width() * rect.height() into a
uint64_t. Both width() and height() return int, so the multiplication
is performed in int and only the result is widened. Any rect whose
area exceeds INT_MAX (e.g. 50000 x 50000 == 2,500,000,000) overflows
the int multiplication before the assignment, then sign-extends into
uint64_t and corrupts the running total.
Cast one operand to uint64_t so the multiplication itself happens in
64 bits. Add an API test that exercises the overflow case.
Test: RegionTests.TotalAreaDoesNotOverflowSignedInt
* Source/WebCore/platform/graphics/Region.cpp:
(WebCore::Region::totalArea const):
* Tools/TestWebKitAPI/Tests/WebCore/RegionTests.cpp:
(TestWebKitAPI::TEST(RegionTests, TotalAreaDoesNotOverflowSignedInt)):
Canonical link: https://commits.webkit.org/314594@main
Canonical link: https://commits.webkit.org/305877.768@webkitglib/2.52
Commit: fd9fc45e167ca00a6681945f23f6e59db8e3e6e7
https://github.com/WebKit/WebKit/commit/fd9fc45e167ca00a6681945f23f6e59db8e3e6e7
Author: Brady Eidson <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/WebCore/dom/MessagePort.cpp
M Source/WebCore/dom/MessagePort.h
M Source/WebKit/WebProcess/WebCoreSupport/WebMessagePortChannelProvider.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebMessagePortChannelProvider.h
M Source/WebKit/WebProcess/WebProcess.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/MessagePortSecurity.mm
Log Message:
-----------
Cherry-pick 314573@main (67117c4975bb).
https://bugs.webkit.org/show_bug.cgi?id=315221
MessagePorts a WebContent process already has should be invalidated if the
Networking process disconnects
rdar://177440317
https://bugs.webkit.org/show_bug.cgi?id=315221
Reviewed by Basuke Suzuki.
The scenario is:
1 - A MessageChannel is created, and therefore registered with the
networking process.
2 - The Networking process disconnects (crash, jetsam, suspend, etc)
3 - A new Networking process is fired up and connects to the old WebContent
process
4 - The WebContent process tries a message channel operation in the new
Networking process on a port
the new Networking process doesn't know about.
https://commits.webkit.org/305413.547@safari-7624-branch added more
aggressive MESSAGE_CHECKs to the
networking process to protect against message port spoofs from compromised
web content processes.
The above scenario is WebKit in normal operation and unfortunately
triggering those MESSAGE_CHECKs
So this PR teaches web content processes to invalidate current message
ports if the Networking process
goes away. It handles normal message port operation, worker use, and works
with site isolation.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/MessagePortSecurity.mm
* Source/WebCore/dom/MessagePort.cpp:
(WebCore::MessagePort::notifyAllConnectionsClosed):
* Source/WebCore/dom/MessagePort.h:
* Source/WebKit/WebProcess/WebCoreSupport/WebMessagePortChannelProvider.cpp:
(WebKit::WebMessagePortChannelProvider::createNewMessagePortChannel):
(WebKit::WebMessagePortChannelProvider::entangleLocalPortInThisProcessToRemote):
(WebKit::WebMessagePortChannelProvider::messagePortDisentangled):
(WebKit::WebMessagePortChannelProvider::networkProcessConnectionClosed):
(WebKit::WebMessagePortChannelProvider::messagePortClosed):
(WebKit::WebMessagePortChannelProvider::takeAllMessagesForPort):
* Source/WebKit/WebProcess/WebCoreSupport/WebMessagePortChannelProvider.h:
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::networkProcessConnectionClosed):
* Tools/TestWebKitAPI/Resources/cocoa/MessagePortSecurity.mm:
((MessagePortSecurity, CrossProcessMessageTheftViaTakeAllMessagesForPort)):
((MessagePortSecurity, MessagePortsSurviveNetworkProcessRestart)):
((MessagePortSecurity,
MessagePortsSurviveNetworkProcessRestartWithSiteIsolation)):
((MessagePortSecurity, WorkerMessagePortsSurviveNetworkProcessRestart)):
Originally-landed-as: 305413.972@safari-7624-branch (b90cdae5a91d).
rdar://178741244
Canonical link: https://commits.webkit.org/314573@main
Canonical link: https://commits.webkit.org/305877.769@webkitglib/2.52
Commit: 521b55ce447f0c74798387c5633c5dd576764c0d
https://github.com/WebKit/WebKit/commit/521b55ce447f0c74798387c5633c5dd576764c0d
Author: Rupin Mittal <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick 314583@main (e30ca29fe973).
https://bugs.webkit.org/show_bug.cgi?id=314298
Add cookie access validation to startDownload() and
convertMainResourceLoadToDownload() to prevent CSRF
https://bugs.webkit.org/show_bug.cgi?id=314298
rdar://173378006
Reviewed by Alex Christensen.
NetworkConnectionToWebProcess::startDownload() and
NetworkConnectionToWebProcess::convertMainResourceLoadToDownload() do not
validate the firstPartyForCookies in the requests sent to them by the web
process. So a web process could send in a cross-site origin, leading to
requests being sent to this cross-site origin that contain the cookies for
this origin. So these requests would be seen as legitimate even though they
did not come from the user. We fix this by adding message checks to confirm
that the web process indeed has cookie access to the origin it is sending
as the firstPartyForCookies.
This breaks a number of tests. For example,
TEST(_WKDownload, DownloadRequestOriginalURLDirectDownload), crashes at the
ASSERT_NOT_REACHED(); in NetworkProcess::allowsFirstPartyForCookies because
the web process hasn't been added to the map (Since the policy decision is
PolicyAction::Download and that codepath doesn't add the web process to the
map. So we modify the MESSAGE_CHECK to only occur if the passed in request
contains a non-empty firstPartyForCookies. That way, we guard against an
arbitrary domain being used.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::startDownload):
(WebKit::NetworkConnectionToWebProcess::convertMainResourceLoadToDownload):
Originally-landed-as: 305413.882@safari-7624-branch (12dccb08af3d).
rdar://173378006
Canonical link: https://commits.webkit.org/314583@main
Canonical link: https://commits.webkit.org/305877.770@webkitglib/2.52
Commit: 406a3327db30ca4021b8d2608e18348594556cfb
https://github.com/WebKit/WebKit/commit/406a3327db30ca4021b8d2608e18348594556cfb
Author: Rupin Mittal <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp
Log Message:
-----------
Cherry-pick 314550@main (28ea4d7f92e5).
https://bugs.webkit.org/show_bug.cgi?id=316231
WebCookieJar contains duplicate shouldBlockCookies() call
https://bugs.webkit.org/show_bug.cgi?id=316231
rdar://178655565
Reviewed by Charlie Wolfe.
There is no need to recompute shouldBlockCookies. We can reuse the stored
result.
* Source/WebKit/WebProcess/WebPage/WebCookieJar.cpp:
(WebKit::WebCookieJar::cookiesEnabled):
Canonical link: https://commits.webkit.org/314550@main
Canonical link: https://commits.webkit.org/305877.771@webkitglib/2.52
Commit: eac069eefa82ab673c295a255926056728823d2e
https://github.com/WebKit/WebKit/commit/eac069eefa82ab673c295a255926056728823d2e
Author: Chris Dumez <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any.html
A
LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any.js
A
LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any.worker-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any.worker.html
M Source/WebCore/Modules/fetch/FetchBody.cpp
Log Message:
-----------
Cherry-pick 314442@main (5d8c7f0a38c9).
https://bugs.webkit.org/show_bug.cgi?id=316159
FetchBody::clone() leaves m_data and m_readableStream desynchronized
https://bugs.webkit.org/show_bug.cgi?id=316159
Reviewed by Anne van Kesteren.
When cloning a FetchBody whose body is a ReadableStream, only the
m_readableStream field was updated to point at the new tee branches;
m_data still held the original (now disturbed) stream on the source,
and was left as the default nullptr variant on the clone. This broke
the invariant established by FetchBody(Ref<ReadableStream>&&) that
m_data and m_readableStream refer to the same stream, causing
isReadableStream() and hasReadableStream() to disagree.
The visible consequence is that constructing a new Request from a
cloned Request silently dropped the body: FetchBody::createProxy()
keys off isReadableStream(), which returned false on the clone, so
the proxy short-circuited before piping the readable stream through.
Set m_data alongside m_readableStream on both branches of the tee
to keep the two fields in sync.
This aligns our behavior with Chrome.
Tests:
imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any.html
imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any.worker.html
*
LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any.js:
Added.
(promise_test.async const):
(promise_test):
*
LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any.worker-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/fetch/api/request/request-clone-readable-stream-body.any.worker.html:
Added.
* Source/WebCore/Modules/fetch/FetchBody.cpp:
(WebCore::FetchBody::clone):
Canonical link: https://commits.webkit.org/314442@main
Canonical link: https://commits.webkit.org/305877.772@webkitglib/2.52
Commit: e6197d2b43346da3a512830a0f412e44ec6a232d
https://github.com/WebKit/WebKit/commit/e6197d2b43346da3a512830a0f412e44ec6a232d
Author: Zak Ridouh <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
A
LayoutTests/http/tests/site-isolation/remove-iframe-while-process-launching-crash-expected.txt
A
LayoutTests/http/tests/site-isolation/remove-iframe-while-process-launching-crash.html
M Source/WebKit/UIProcess/WebProcessProxy.cpp
Log Message:
-----------
Cherry-pick 314426@main (9d6056753754).
https://bugs.webkit.org/show_bug.cgi?id=316154
Fix use-after-free in ~WebProcessProxy() when replying to pending IPC
messages
https://bugs.webkit.org/show_bug.cgi?id=316154
rdar://178478856
Reviewed by Chris Dumez.
When a WebProcessProxy is torn down while its process is still launching,
~AuxiliaryProcessProxy() calls replyToPendingMessages() after
WebProcessProxy's
own members have already been destroyed. Those reply handlers (e.g. the one
queued
by sendPageCloseMessage()) upgrade a WeakPtr<WebProcessProxy> that is still
live —
the WeakPtrFactory lives in a base class destroyed later — and read freed
members
such as m_pagesPendingClose, causing a heap-use-after-free.
Reply to the pending messages at the top of ~WebProcessProxy(), while our
members
are still intact. The later base-class call then finds an empty queue and
is a no-op.
*
LayoutTests/http/tests/site-isolation/remove-iframe-while-process-launching-crash-expected.txt:
Added.
*
LayoutTests/http/tests/site-isolation/remove-iframe-while-process-launching-crash.html:
Added.
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::~WebProcessProxy):
Canonical link: https://commits.webkit.org/314426@main
Canonical link: https://commits.webkit.org/305877.773@webkitglib/2.52
Commit: 1f39a3c35acf07a422650fe1f81966c9638f2aa8
https://github.com/WebKit/WebKit/commit/1f39a3c35acf07a422650fe1f81966c9638f2aa8
Author: Claudio Saavedra <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/WebCore/Modules/webaudio/AudioNodeInput.cpp
Log Message:
-----------
Cherry-pick 314410@main (7ff2120302f0).
https://bugs.webkit.org/show_bug.cgi?id=316093
webaudio/AudioBufferSource/audiobuffersource-playbackrate.html is a flaky
crash
https://bugs.webkit.org/show_bug.cgi?id=316093
Reviewed by Philippe Normand and Chris Dumez.
AudioDestinationNode::renderQuantum() runs the audio thread inside a
ForbidMallocUseForCurrentThreadScope, which extends through
handlePostRenderTasks() and the node-deletion bookkeeping it performs. The
fallback in AudioNodeInput::disconnect() calls m_disabledOutputs.remove()
without a DisableMallocRestrictionsForCurrentThreadScope; HashSet::remove()
may shrink and rehash, allocating, and trips the assertion.
AudioSummingJunction::removeOutput() and AudioNodeInput::disable() /
enable()
already wrap their hash-set mutations the same way; do the same for the
disabled-list fallback in disconnect().
* Source/WebCore/Modules/webaudio/AudioNodeInput.cpp:
(WebCore::AudioNodeInput::disconnect):
Canonical link: https://commits.webkit.org/314410@main
Canonical link: https://commits.webkit.org/305877.774@webkitglib/2.52
Commit: ff4bc7858b3e61f4fa9bcbd5ff011615562ce9f4
https://github.com/WebKit/WebKit/commit/ff4bc7858b3e61f4fa9bcbd5ff011615562ce9f4
Author: Philippe Normand <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp
Log Message:
-----------
Cherry-pick 314369@main (afa9356bdfb2).
https://bugs.webkit.org/show_bug.cgi?id=316096
REGRESSION(314285@main): [GStreamer]
imported/w3c/web-platform-tests/webrtc/RTCPeerConnection-addTransceiver-renegotiation.https.html
crashes
https://bugs.webkit.org/show_bug.cgi?id=316096
Reviewed by Claudio Saavedra.
The transceiver codec-preferences can be un-set, so that should be checked
before usage.
* Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp:
(WebCore::GStreamerMediaEndpoint::trackWasReplaced):
Canonical link: https://commits.webkit.org/314369@main
Canonical link: https://commits.webkit.org/305877.775@webkitglib/2.52
Commit: c9159513d8793809cc2d30906b7e96f12c9b2d43
https://github.com/WebKit/WebKit/commit/c9159513d8793809cc2d30906b7e96f12c9b2d43
Author: Sosuke Suzuki <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/bmalloc/libpas/src/libpas/pas_bitfit_directory.c
M Source/bmalloc/libpas/src/libpas/pas_race_test_hooks.h
M Source/bmalloc/libpas/src/test/BitfitTests.cpp
Log Message:
-----------
Cherry-pick 312830@main (6e299de4c1ae).
https://bugs.webkit.org/show_bug.cgi?id=314271
[libpas] Fix race in `pas_bitfit_directory_take_last_empty`
https://bugs.webkit.org/show_bug.cgi?id=314271
Reviewed by Marcus Plutowski.
pas_bitfit_directory_take_last_empty read last_empty_plus_one with
pas_versioned_field_read instead of pas_versioned_field_read_to_watch,
so the final pas_versioned_field_try_write could not detect a
concurrent view_did_become_empty_at_index between the scan and the
write. The try_write succeeded on a stale version and zeroed
last_empty_plus_one with empty bits still set, stranding the page.
The matching segregated-directory path already uses read_to_watch.
Add a regression test that uses pas_race_test_hooks to inject the
empty event between the scan and the write.
* Source/bmalloc/libpas/src/libpas/pas_bitfit_directory.c:
(pas_bitfit_directory_take_last_empty):
* Source/bmalloc/libpas/src/libpas/pas_race_test_hooks.h:
(pas_race_test_hook_kind_get_string):
* Source/bmalloc/libpas/src/test/BitfitTests.cpp:
(std::takeLastEmptyRaceHook):
(std::testTakeLastEmptyLastEmptyPlusOneWatchRace):
(addBitfitTests):
Canonical link: https://commits.webkit.org/312830@main
Canonical link: https://commits.webkit.org/305877.776@webkitglib/2.52
Commit: 22c6d14dfc28f504ff95012bf027fae54d8d9f5d
https://github.com/WebKit/WebKit/commit/22c6d14dfc28f504ff95012bf027fae54d8d9f5d
Author: David Kilzer <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/WebCore/workers/WorkerMessagingProxy.cpp
Log Message:
-----------
Cherry-pick 312256@main (80cc99fb32cb).
https://bugs.webkit.org/show_bug.cgi?id=313389
WorkerMessagingProxy objects leak after calling worker.terminate() from
JavaScript
<https://bugs.webkit.org/show_bug.cgi?id=313389>
<rdar://175652847>
Reviewed by Chris Dumez.
Handle the case in `workerObjectDestroyed()` where
`workerGlobalScopeDestroyedInternal()` has already run. When
that happens, the proxy's thread, context, and identifier are
already cleaned up -- the only remaining work is releasing the
initial construction ref via `deref()`. Without this,
`workerObjectDestroyed()` returns early on the nullopt
identifier, leaving the ref permanently held.
Also clear `m_queuedEarlyTasks` in
`workerGlobalScopeDestroyedInternal()` because tasks queued
before the worker thread is created capture `Ref { *this }`,
forming a retain cycle through the proxy's own member vector
that prevents destruction even after `deref()` is called.
The leak was introduced in Bug 22723 (254597@main) which added
the null-context early return to `workerObjectDestroyed()` and
added `m_scriptExecutionContext = nullptr` to
`workerGlobalScopeDestroyedInternal()` as part of implementing
nested dedicated workers.
Test using `run-webkit-tests --leaks` with:
- workers/worker-set-delete-terminate-crash.html
- workers/worker-terminate-crash.html
* Source/WebCore/workers/WorkerMessagingProxy.cpp:
(WebCore::WorkerMessagingProxy::workerObjectDestroyed):
(WebCore::WorkerMessagingProxy::workerGlobalScopeDestroyedInternal):
Canonical link: https://commits.webkit.org/312256@main
Canonical link: https://commits.webkit.org/305877.777@webkitglib/2.52
Commit: 0480a37c76c81dbfee40160990e3442f5cd5bf5c
https://github.com/WebKit/WebKit/commit/0480a37c76c81dbfee40160990e3442f5cd5bf5c
Author: Youenn Fablet <[email protected]>
Date: 2026-06-21 (Sun, 21 Jun 2026)
Changed paths:
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.h
Log Message:
-----------
Cherry-pick 311277@main (5205050c09a9).
https://bugs.webkit.org/show_bug.cgi?id=312253
Callers of WebSWServerConnection::checkTopOrigin should return early if
check fails
https://bugs.webkit.org/show_bug.cgi?id=312253
rdar://174495602
Reviewed by Chris Dumez.
We make checkTopOrigin return false if a MESSAGE_CHECK fails and make
callers of checkTopOrigin bail out if it returns false.
* Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp:
(WebKit::WebSWServerConnection::resolveUnregistrationJobInClient):
* Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.h:
Canonical link: https://commits.webkit.org/311277@main
Canonical link: https://commits.webkit.org/305877.778@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/bc22e64695c7...0480a37c76c8
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
