Branch: refs/heads/safari-7625.1.29.11-branch
Home: https://github.com/WebKit/WebKit
Commit: 9552a43369eba6b5e487803f4f728f6d11b236fc
https://github.com/WebKit/WebKit/commit/9552a43369eba6b5e487803f4f728f6d11b236fc
Author: Mohsin Qureshi <[email protected]>
Date: 2026-08-12 (Wed, 12 Aug 2026)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning. WebKit-7625.1.29.11.23
Canonical link: https://commits.webkit.org/[email protected]
Commit: 4419e762ae14ae1d4bcd5f588fbfea1b04f0bad3
https://github.com/WebKit/WebKit/commit/4419e762ae14ae1d4bcd5f588fbfea1b04f0bad3
Author: Matthew Finkel <[email protected]>
Date: 2026-08-12 (Wed, 12 Aug 2026)
Changed paths:
M
Source/WebKit/NetworkProcess/webtransport/cocoa/NetworkTransportSessionCocoa.mm
Log Message:
-----------
Cherry-pick 669fce73f5f9. rdar://184420964
[cocoa] uiProcessBundleIdentifier may mark the WebTransport connection
incorrectly
https://bugs.webkit.org/show_bug.cgi?id=321381
rdar://184420964
Reviewed by Mike Wyrzykowski.
The original fix for rdar://184076013 used the NetworkProcess's
uiProcessBundleIdentifier(). That is too strict for what we want. There are
some cases where we don't want the literal UI Process' bundle ID, and
instead
we have a substitute. The NetworkSession owns that substitute, and we use
that
alternative bundle ID in all other cases where we mark connections. This
aligns
the WebTransport connections with the other connections.
*
Source/WebKit/NetworkProcess/webtransport/cocoa/NetworkTransportSessionCocoa.mm:
(WebKit::createParameters):
Identifier: 316606.352@safari-7625-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 2bcc4befc4a46eceda6eb53aff4c776156ab2d02
https://github.com/WebKit/WebKit/commit/2bcc4befc4a46eceda6eb53aff4c776156ab2d02
Author: Pouneh Bahrami <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
A
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-lax-not-sent-cross-site-expected.txt
A
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-lax-not-sent-cross-site.html
A
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-none-sent-cross-site-expected.txt
A
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-none-sent-cross-site.html
A
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-sent-same-site-expected.txt
A
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-sent-same-site.html
A
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-strict-not-sent-cross-site-expected.txt
A
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-strict-not-sent-cross-site.html
M Source/WebKit/NetworkProcess/cocoa/WebSocketTaskCocoa.mm
Log Message:
-----------
Cherry-pick 7450aff7426d. rdar://184747688
WebSocket requests bypass SameSite Strict and Lax Cookies
https://bugs.webkit.org/show_bug.cgi?id=309567
rdar://172188734
Reviewed by Charlie Wolfe.
HTTP requests go through willPerformHTTPRedirection() on each
request/redirect, where updateTaskWithFirstPartyForSameSiteCookies()
sets task._siteForCookies and task._isTopLevelNavigation on the
NSURLSessionTask. This gives CFNetwork the same-site context needed
to filter SameSite=Strict and SameSite=Lax cookies on cross-site
requests.
WebSocket tasks (NSURLSessionWebSocketTask) bypass the
willPerformHTTPRedirection() path entirely. Neither _siteForCookies nor
_isTopLevelNavigation was ever set, so
CFNetwork had no same-site context and attached all matching cookies
regardless of their SameSite attribute.
In WebSocketTask::WebSocketTask(), we call
updateTaskWithFirstPartyForSameSiteCookies()
on the NSURLSessionWebSocketTask immediately after it is created and before
it is resumed. This mirrors the pattern already used for HTTP tasks in
willPerformHTTPRedirection() and for partitioned cookie identifiers in
updateTaskWithStoragePartitionIdentifier().
Tests:
http/tests/websocket/tests/hybi/websocket-samesite-lax-not-sent-cross-site.html
http/tests/websocket/tests/hybi/websocket-samesite-none-sent-cross-site.html
http/tests/websocket/tests/hybi/websocket-samesite-sent-same-site.html
http/tests/websocket/tests/hybi/websocket-samesite-strict-not-sent-cross-site.html
*
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-lax-not-sent-cross-site-expected.txt:
Added.
*
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-lax-not-sent-cross-site.html:
Added.
*
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-none-sent-cross-site-expected.txt:
Added.
*
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-none-sent-cross-site.html:
Added.
*
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-sent-same-site-expected.txt:
Added.
*
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-sent-same-site.html:
Added.
*
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-strict-not-sent-cross-site-expected.txt:
Added.
*
LayoutTests/http/tests/websocket/tests/hybi/websocket-samesite-strict-not-sent-cross-site.html:
Added.
* Source/WebKit/NetworkProcess/cocoa/WebSocketTaskCocoa.mm:
(WebKit::WebSocketTask::WebSocketTask):
Identifier: 305413.769@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 9bab5691399246d3f2da2fbeeb2ecf3f9564def8
https://github.com/WebKit/WebKit/commit/9bab5691399246d3f2da2fbeeb2ecf3f9564def8
Author: Chris Dumez <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
A
LayoutTests/fast/dom/trusted-types-execCommand-insertHTML-case-insensitive-expected.txt
A
LayoutTests/fast/dom/trusted-types-execCommand-insertHTML-case-insensitive.html
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 0e4f1956aff4. rdar://184747341
Trusted Types enforcement in Document.execCommand should be case-insensitive
https://bugs.webkit.org/show_bug.cgi?id=314183
rdar://175852496
Reviewed by Anne van Kesteren and Ryosuke Niwa.
The Trusted Types check in Document::execCommand() was using a
case-sensitive
comparison (commandName != "insertHTML"_s) to decide whether to enforce
TrustedHTML. Since execCommand command names are case-insensitive per spec,
passing a differently-cased variant like "InsertHTML" or "inserthtml" would
bypass the Trusted Types enforcement entirely.
Fix by using equalIgnoringASCIICase() for the comparison.
Test: fast/dom/trusted-types-execCommand-insertHTML-case-insensitive.html
*
LayoutTests/fast/dom/trusted-types-execCommand-insertHTML-case-insensitive-expected.txt:
Added.
*
LayoutTests/fast/dom/trusted-types-execCommand-insertHTML-case-insensitive.html:
Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::execCommand):
Identifier: 305413.846@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 8a4095680fd6ff7645a5c2cc3401ca0c4f6d3c74
https://github.com/WebKit/WebKit/commit/8a4095680fd6ff7645a5c2cc3401ca0c4f6d3c74
Author: Youenn Fablet <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
A
LayoutTests/http/wpt/webcodecs/configure-encoder-big-frame-size-expected.txt
A LayoutTests/http/wpt/webcodecs/configure-encoder-big-frame-size.html
M Source/WebCore/Modules/webcodecs/WebCodecsVideoEncoder.cpp
Log Message:
-----------
Cherry-pick b8eb06fa26e8. rdar://184747533
Heap Buffer Overflow in WebRTC VP9 Encoder
rdar://177719944
Reviewed by Jean-Yves Avenard.
We restrict video encoder support to frames of size below 32767.
This aligns with Chrome so should not be a compat issue.
Test: http/wpt/webcodecs/configure-encoder-big-frame-size.html
*
LayoutTests/http/wpt/webcodecs/configure-encoder-big-frame-size-expected.txt:
Added.
* LayoutTests/http/wpt/webcodecs/configure-encoder-big-frame-size.html:
Added.
* Source/WebCore/Modules/webcodecs/WebCodecsVideoEncoder.cpp:
(WebCore::isSupportedEncoderCodec):
(WebCore::WebCodecsVideoEncoder::configure):
(WebCore::WebCodecsVideoEncoder::isConfigSupported):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: a437eb823d4ee2e225f5b42ef2c6630980b73b0f
https://github.com/WebKit/WebKit/commit/a437eb823d4ee2e225f5b42ef2c6630980b73b0f
Author: Brent Fulgham <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
Log Message:
-----------
Cherry-pick 2f7b2e8b7f9f. rdar://184747440
Escape key no longer guarantees cancelling fullscreen (with keyboard lock)
(311660)
https://bugs.webkit.org/show_bug.cgi?id=311660
rdar://problem/174251766
Reviewed by Brandon Stewart.
Revert 303093@main since the User Interface information to instruct the
user to hold
the ESC key for 1.5 seconds (or longer) was not completed. This can lead to
confusion
and the possibility of spoofing users. We will reland the enablement when
the UI portion
is available.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: a3c24c941fd0dbd0fa12f8c778c79522d686fa3f
https://github.com/WebKit/WebKit/commit/a3c24c941fd0dbd0fa12f8c778c79522d686fa3f
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
A
LayoutTests/fast/canvas/offscreen-isPointInStroke-svg-stroke-bounds-race-crash-expected.txt
A
LayoutTests/fast/canvas/offscreen-isPointInStroke-svg-stroke-bounds-race-crash.html
M Source/WebCore/platform/graphics/cg/PathCG.cpp
Log Message:
-----------
Cherry-pick 6ab6f0e16b4d. rdar://184747421
PathCG should use thread-safe scratchContext
https://bugs.webkit.org/show_bug.cgi?id=316567
rdar://178176596
Reviewed by Darin Adler.
The fix of bug 313935 was incomplete. The fix was done by adding two static
Locks
to PathCG::strokeContains() and PathCG::strokeBoundingRect(). This fix
makes these
two functions be thread-safe independently. But this is not enough. It is
possible
to call PathCG::strokeContains() and PathCG::strokeBoundingRect() from two
different threads at the same time.
The fix is to make scratchContext() return a thread-specific graphics
context.
So two threads can't access the same context at the same time.
Test:
fast/canvas/offscreen-isPointInStroke-svg-stroke-bounds-race-crash.html
*
LayoutTests/fast/canvas/offscreen-isPointInStroke-svg-stroke-bounds-race-crash-expected.txt:
Added.
*
LayoutTests/fast/canvas/offscreen-isPointInStroke-svg-stroke-bounds-race-crash.html:
Added.
* Source/WebCore/platform/graphics/cg/PathCG.cpp:
(WebCore::scratchContext):
(WebCore::PathCG::strokeContains const):
(WebCore::PathCG::strokeBoundingRect const):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: 07423f9a300aebe794efb6ae4d142a95dbbc8b08
https://github.com/WebKit/WebKit/commit/07423f9a300aebe794efb6ae4d142a95dbbc8b08
Author: Kai Tamkun <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
A
JSTests/stress/ftl-osr-exit-materialize-phantom-array-with-live-butterfly.js
M Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp
Log Message:
-----------
Cherry-pick 883cc7576689. rdar://184747346
[JSC] FTL OSR exit: handle DataFormatStorage in reboxAccordingToFormat
https://bugs.webkit.org/show_bug.cgi?id=314579
rdar://176131036
Reviewed by Marcus Plutowski.
300523@main relaxed validation so that PhantomNewArrayWithButterfly may
reference a non-phantom NewButterflyWithSize, and taught
FTLLowerDFGToB3::exitValueForNode to emit an ExitArgument with
DataFormatStorage for the live butterfly. However, the FTL OSR exit
compiler's reboxAccordingToFormat() was never updated, so when such an
exit is compiled it falls into RELEASE_ASSERT_NOT_REACHED().
The recovered storage value is the raw butterfly pointer that
operationMaterializeObjectInOSR(PhantomNewArrayWithButterfly) consumes
via std::bit_cast<Butterfly*>, so no boxing is required; treat it the
same as DataFormatJS and pass it through unchanged.
Test:
JSTests/stress/ftl-osr-exit-materialize-phantom-array-with-live-butterfly.js
*
JSTests/stress/ftl-osr-exit-materialize-phantom-array-with-live-butterfly.js:
Added.
(check):
(main.v2):
(main):
* Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::reboxAccordingToFormat):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: 873e617ab59f5e2c7b8d287611fea52563322a16
https://github.com/WebKit/WebKit/commit/873e617ab59f5e2c7b8d287611fea52563322a16
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
A
LayoutTests/http/tests/canvas/canvas-tainted-image-capture-video-frame-expected.html
A
LayoutTests/http/tests/canvas/canvas-tainted-image-capture-video-frame.html
A
LayoutTests/http/tests/canvas/resources/cross-origin-image-capture-video-frame.html
M Source/WebCore/Modules/mediastream/CanvasCaptureMediaStreamTrack.cpp
Log Message:
-----------
Cherry-pick 723dbeacf061. rdar://184747381
When captured as a video frame, canvas has to be tainted if cross-origin
image are drawn into it
https://bugs.webkit.org/show_bug.cgi?id=316594
rdar://171846032
Reviewed by Simon Fraser.
HTMLCanvasElement::captureStream() allows streaming a canvas's output to a
<video>
element. The track frames of this video is obtained from
CanvasCaptureMediaStreamTrack
::grabFrame(). This function unconditionally gets a VideoFrame by calling
HTMLCanvasElement::toVideoFrame().
If cross-origin images are drawn into the canvas, this canvas has to be
tainted.
So no getImageData() can see the pixels of the cross-origin images.
*
LayoutTests/http/tests/canvas/canvas-tainted-image-capture-video-frame-expected.html:
Added.
*
LayoutTests/http/tests/canvas/canvas-tainted-image-capture-video-frame.html:
Added.
*
LayoutTests/http/tests/canvas/resources/cross-origin-image-capture-video-frame.html:
Added.
* Source/WebCore/Modules/mediastream/CanvasCaptureMediaStreamTrack.cpp:
(WebCore::CanvasCaptureMediaStreamTrack::Source::grabFrame):
(WebCore::CanvasCaptureMediaStreamTrack::Source::captureCanvas):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: 352eeb67a26c4083065429849bd6453825415c04
https://github.com/WebKit/WebKit/commit/352eeb67a26c4083065429849bd6453825415c04
Author: David Kilzer <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebCore/platform/graphics/mac/controls/ControlFactoryMac.mm
Log Message:
-----------
Cherry-pick 4620ee2b5925. rdar://184747807
GPU process crash in
WebCore::ControlFactoryMac::servicesRolloverButtonCell() drawing image controls
<https://bugs.webkit.org/show_bug.cgi?id=316849>
<rdar://177901870>
Reviewed by Simon Fraser.
The GPU process can crash while drawing the image-controls (services
rollover) button on its per-connection RemoteRenderingBackend work
queues. Each RemoteGraphicsContext installs its own per-context
ControlFactory override for the duration of a draw, so the factory
itself is not shared across work-queue threads.
`ControlFactoryMac::servicesRolloverButtonCell()` is the one cell
accessor that defeats that isolation. It caches the cell returned by
`+[NSServicesRolloverButtonCell serviceRolloverButtonCellForStyle:]`,
which is a process-wide singleton, so every per-context factory ends up
caching and drawing the SAME AppKit cell. Configuring that shared cell
on one work-queue thread races with drawing it on another, and `NSCell`
is not thread-safe.
Give each factory a private copy of the cell, so it is only ever touched
by that factory's single work-queue thread. `-[NSButtonCell
copyWithZone:]` gives the copy a nil visual provider -- the state whose
concurrent mutation crashes -- so the copy shares nothing mutable with
the shared cell, and drawing it needs no lock.
The copy itself must be serialized under a process-wide lock because
`-[NSButtonCell copyWithZone:]` transiently mutates its source, so
concurrent first-access copies of the shared cell would otherwise race.
No new tests since this change is not directly testable.
* Source/WebCore/platform/graphics/mac/controls/ControlFactoryMac.mm:
(WebCore::ControlFactoryMac::servicesRolloverButtonCell const):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: 29413e13a2b40670c70d2344ff713557a1fb4868
https://github.com/WebKit/WebKit/commit/29413e13a2b40670c70d2344ff713557a1fb4868
Author: David Kilzer <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebKit/WebProcess/WebStorage/WebStorageNamespaceProvider.cpp
Log Message:
-----------
Cherry-pick 6254fe9499a7. rdar://184747436
REGRESSION (259876@main): Check for end iterator in
WebStorageNamespaceProvider::decrementUseCount()
<https://bugs.webkit.org/show_bug.cgi?id=317082>
<rdar://179209792>
Reviewed by Zak Ridouh.
Guard against a missing entry before dereferencing the result of
`HashMap::find()` in `decrementUseCount()`. The function relies on
`ASSERT(iterator != ...end())`, which compiles to nothing in release
builds, then reads `iterator->value` unconditionally. When the
identifier is absent, `find()` returns `end()`, and reading
`end()->value` accesses memory one entry past the table's backing
buffer.
The absent-entry case became reachable in 259876@main, which replaced
the page-group-keyed owning map of providers with a single weakly-held
provider (`existingStorageNameSpaceProvider()`). The provider is now
destroyed when the last page in a Web Content process goes away and
recreated empty for the next page, so a `WebPage` torn down after that
point decrements against a provider that never held its identifier.
Return early when the iterator is `end()`, matching the existing guard
in the sibling accessor `sessionStorageNamespace()`. The
`ASSERT(sessionStorageNamespaces.useCount)` is retained so debug builds
still flag a use-count imbalance.
No new tests since this path is reached only during web page teardown
when the session storage namespace entry has already been removed, and
is not directly testable through public API.
* Source/WebKit/WebProcess/WebStorage/WebStorageNamespaceProvider.cpp:
(WebKit::WebStorageNamespaceProvider::decrementUseCount):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: 9612058bbdf17ba8077cd67d59d06c1221997a7e
https://github.com/WebKit/WebKit/commit/9612058bbdf17ba8077cd67d59d06c1221997a7e
Author: Chris Dumez <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
A
LayoutTests/fast/shadow-dom/manual-slot-assign-renderer-teardown-crash-expected.txt
A
LayoutTests/fast/shadow-dom/manual-slot-assign-renderer-teardown-crash.html
M Source/WebCore/dom/SlotAssignment.cpp
Log Message:
-----------
Cherry-pick ddc8b3fae09f. rdar://184747565
UAF in ManualSlotAssignment via WeakHashMap rehash during reentrant
composed-tree teardown
https://bugs.webkit.org/show_bug.cgi?id=REDACTED
rdar://179729192
Reviewed by Anne van Kesteren.
ManualSlotAssignment::slotManualAssignmentDidChange computed
effectiveCurrent
by calling assignedNodesForSlot, which returns a raw pointer to the
cachedAssignment Vector inside a Slot value stored directly in the m_slots
WeakHashMap bucket array. It then called
RenderTreeUpdater::tearDownRenderersAfterSlotChange, whose composed-tree
traversal can call HTMLSlotElement::assignedNodes on a sibling slot and
re-enter ManualSlotAssignment::assignedNodesForSlot. The reentrant
m_slots.ensure call may invoke the WeakHashMap amortized cleanup, sweep
null-keyed entries left by previously inserted, removed and GC-collected
slot
elements, and rehash the table, freeing the bucket array effectiveCurrent
points into. The stale pointer was then dereferenced in
scheduleSlotChangeEventIfNeeded.
Compute effectiveCurrent as a local Vector via effectiveAssignedNodes,
mirroring effectivePrevious, so no pointer into m_slots is held across the
render-tree teardown.
*
LayoutTests/fast/shadow-dom/manual-slot-assign-renderer-teardown-crash-expected.txt:
Added.
*
LayoutTests/fast/shadow-dom/manual-slot-assign-renderer-teardown-crash.html:
Added.
* Source/WebCore/dom/SlotAssignment.cpp:
(WebCore::ManualSlotAssignment::slotManualAssignmentDidChange):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: dac388883172be98f5fc7eb748b89a136659a69d
https://github.com/WebKit/WebKit/commit/dac388883172be98f5fc7eb748b89a136659a69d
Author: David Kilzer <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebCore/platform/graphics/avfoundation/objc/QueuedVideoOutput.mm
Log Message:
-----------
Cherry-pick f53714d59190. rdar://184747772
[Cocoa] Hold a strong reference to QueuedVideoOutput in its main run loop
callbacks
<rdar://181438985>
Reviewed by Jonathan Bedard.
The WebQueuedVideoOutputDelegate callbacks and the AVFoundation time
observer blocks hop their work to the main run loop capturing only a
WeakPtr to the QueuedVideoOutput, then dereference it as a raw pointer
after a plain null check. The null check does not keep the object
alive: addVideoFrameEntries() fires the current-image-changed
observers, which can synchronously tear down the media player and
release the last strong reference to the QueuedVideoOutput while the
callback is still on the stack, so the trailing member access reads
freed memory.
Promote the captured WeakPtr to a RefPtr inside each block before use
so the object is kept alive for the duration of the call. The sole
strong owner only ever runs on the main thread, so the non-atomic
RefPtr is sufficient and no ThreadSafeRefCounted change is needed.
No new tests since this change is not directly testable.
* Source/WebCore/platform/graphics/avfoundation/objc/QueuedVideoOutput.mm:
(-[WebQueuedVideoOutputDelegate outputMediaDataWillChange:]):
(-[WebQueuedVideoOutputDelegate outputSequenceWasFlushed:]):
(-[WebQueuedVideoOutputDelegate
observeValueForKeyPath:ofObject:change:context:]):
(WebCore::QueuedVideoOutput::QueuedVideoOutput):
(WebCore::QueuedVideoOutput::configureNextImageTimeObserver):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Commit: b1f23c3e17bc61720f60bacf58d6eb7bc9abd53d
https://github.com/WebKit/WebKit/commit/b1f23c3e17bc61720f60bacf58d6eb7bc9abd53d
Author: Tyler Wilcock <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebCore/platform/PlatformSpeechSynthesizer.cpp
M Source/WebCore/platform/PlatformSpeechSynthesizer.h
M Source/WebCore/platform/cocoa/PlatformSpeechSynthesizerCocoa.mm
M Source/WebCore/platform/gstreamer/PlatformSpeechSynthesizerGStreamer.cpp
M Source/WebCore/platform/mock/PlatformSpeechSynthesizerMock.cpp
M Source/WebCore/platform/spiel/PlatformSpeechSynthesizerSpiel.cpp
M Source/WebCore/testing/Internals.cpp
Log Message:
-----------
Cherry-pick 71471a83ed2d. rdar://184747782
PlatformSpeechSynthesizerClient should prevent use-after-free via weak
back-reference to client
https://bugs.webkit.org/show_bug.cgi?id=312793
rdar://172854014
Reviewed by Joshua Hoffman.
PlatformSpeechSynthesizer held a raw C++ reference
(PlatformSpeechSynthesizerClient&) back to its client
(SpeechSynthesis). When cancel() was made asynchronous via
callOnMainThread in 309349@main, the deferred lambda could fire after
SpeechSynthesis had been destroyed, dereferencing freed memory. ASan
caught this as a heap-use-after-free in 131 media/track layout tests.
This commit makes PlatformSpeechSynthesizerClient inherit from
AbstractRefCountedAndCanMakeWeakPtr so it supports both WeakPtr (for
the non-owning back-reference) and RefPtr (for strong promotion at
call sites). Convert the raw reference member to a WeakPtr, and update
all ~29 call sites across all platform implementations to promote to
RefPtr before calling through the client.
This also fixes two latent async bugs with the same pattern: the Cocoa
voicesDidChange async callback and the Spiel initializeVoiceList
lambda both accessed the client in a deferred context without lifetime
protection.
* Source/WebCore/platform/PlatformSpeechSynthesizer.cpp:
(WebCore::PlatformSpeechSynthesizer::voicesDidChange):
* Source/WebCore/platform/PlatformSpeechSynthesizer.h:
* Source/WebCore/platform/cocoa/PlatformSpeechSynthesizerCocoa.mm:
(-[WebSpeechSynthesisWrapper speakUtterance:]):
(-[WebSpeechSynthesisWrapper speechSynthesizer:didStartSpeechUtterance:]):
(-[WebSpeechSynthesisWrapper speechSynthesizer:didFinishSpeechUtterance:]):
(-[WebSpeechSynthesisWrapper speechSynthesizer:didPauseSpeechUtterance:]):
(-[WebSpeechSynthesisWrapper
speechSynthesizer:didContinueSpeechUtterance:]):
(-[WebSpeechSynthesisWrapper speechSynthesizer:didCancelSpeechUtterance:]):
(-[WebSpeechSynthesisWrapper
speechSynthesizer:willSpeakRangeOfSpeechString:utterance:]):
(WebCore::PlatformSpeechSynthesizer::initializeVoiceList):
* Source/WebCore/platform/gstreamer/PlatformSpeechSynthesizerGStreamer.cpp:
(WebCore::GstSpeechSynthesisWrapper::pause):
(WebCore::GstSpeechSynthesisWrapper::resume):
(WebCore::GstSpeechSynthesisWrapper::speakUtterance):
(WebCore::GstSpeechSynthesisWrapper::cancel):
* Source/WebCore/platform/mock/PlatformSpeechSynthesizerMock.cpp:
(WebCore::PlatformSpeechSynthesizerMock::speakingFinished):
(WebCore::PlatformSpeechSynthesizerMock::speak):
(WebCore::PlatformSpeechSynthesizerMock::cancel):
(WebCore::PlatformSpeechSynthesizerMock::pause):
(WebCore::PlatformSpeechSynthesizerMock::resume):
* Source/WebCore/platform/spiel/PlatformSpeechSynthesizerSpiel.cpp:
(WebCore::SpielSpeechWrapper::finishSpeakerInitialization):
(WebCore::SpielSpeechWrapper::speakUtterance):
(WebCore::PlatformSpeechSynthesizer::initializeVoiceList):
* Source/WebCore/testing/Internals.cpp:
(WebCore::Internals::simulateSpeechSynthesizerVoiceListChange):
Identifier: 305413.715@safari-7624-branch
(cherry picked from commit a9e3e8ac8256cb388e44e0376d92e8ebebf0c311)
Canonical link: https://commits.webkit.org/[email protected]
Commit: c5eb5fc55318c0c5c2a26af90eea8634f3912aa1
https://github.com/WebKit/WebKit/commit/c5eb5fc55318c0c5c2a26af90eea8634f3912aa1
Author: Sihui Liu <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/IndexedDBPersistence.mm
Log Message:
-----------
Cherry-pick 01cef20028da. rdar://184747400
indexedDB.databases() leaks database names across storage partitions due to
swapped ClientOrigin
rdar://176596477
Reviewed by Chris Dumez.
IDBConnectionProxy::getAllDatabaseNamesAndVersions constructs a
ClientOrigin with topOrigin and clientOrigin swapped.
ClientOrigin expects {topOrigin, clientOrigin}, but the code was passing
{securityOrigin (client), topOrigin} instead.
Test: IndexedDB.IndexedDBGetDatabasesFromCrossOriginIframe
* Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.cpp:
(WebCore::IDBClient::IDBConnectionProxy::getAllDatabaseNamesAndVersions):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/IndexedDBPersistence.mm:
((IndexedDB, IndexedDBGetDatabasesFromCrossOriginIframe)):
Identifier: 305413.871@safari-7624-branch
(cherry picked from commit ea034a5eefd5a03c31c040354048f6d1fc3e1038)
Canonical link: https://commits.webkit.org/[email protected]
Commit: 7828ac81654aaaf85a12f28fb7714c3fec05dff1
https://github.com/WebKit/WebKit/commit/7828ac81654aaaf85a12f28fb7714c3fec05dff1
Author: Tyler Wilcock <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebKit/WebProcess/WebPage/mac/WKAccessibilityWebPageObjectBase.mm
Log Message:
-----------
Cherry-pick cea3c1e1af92. rdar://184747479
AX: Fix use-after-free of accessibilityRootObjectWrapper
https://bugs.webkit.org/show_bug.cgi?id=316410
rdar://178730472
Reviewed by Chris Fleizach and Dominic Mazzoni.
The off-main-thread short-circuit in -[WKAccessibilityWebPageObjectBase
accessibilityRootObjectWrapper:] returned root->wrapper() as a raw +0
WebAccessibilityObjectWrapper*. The wrapper's only strong reference at that
moment was AXIsolatedObject::m_wrapper, kept alive transitively by the
local RefPtr<AXIsolatedTree>. Once the function returned, that RefPtr (and
the `root` it kept alive) went out of scope, freeing the wrapper before
the secondary AX thread's caller could retain it. AppKit subsequently
walked the autoreleased single-element NSArray returned by
-[WKAccessibilityWebPageObject accessibilityChildren] and called
objc_retain on the wrapper (and on the array) inside
-[__NSSingleObjectEnumerator initWithObject:collection:], crashing on
freed memory.
Wrap the returned wrapper in RetainPtr<id> { ... }.autorelease()
so it is retained synchronously while `tree`, `root`, and m_wrapper are
all still alive, and then deposited into the secondary thread's
autorelease pool. The pool keeps the wrapper alive for the rest of the
secondary thread's runloop iteration, long enough for AppKit's
ConvertOutgoingValueForElement -> objectEnumerator ->
initWithObject:collection: -> objc_retain sequence to finish safely.
* Source/WebKit/WebProcess/WebPage/mac/WKAccessibilityWebPageObjectBase.mm:
(-[WKAccessibilityWebPageObjectBase accessibilityRootObjectWrapper:]):
Identifier: [email protected]
(cherry picked from commit 74bb47f23c411623b4d4e29d641277b81b118de8)
Canonical link: https://commits.webkit.org/[email protected]
Commit: 9adcd997870d189976d265985ec566edd5cca168
https://github.com/WebKit/WebKit/commit/9adcd997870d189976d265985ec566edd5cca168
Author: Gerald Squelart <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebCore/platform/graphics/cocoa/IOSurface.h
M Source/WebCore/platform/graphics/cocoa/IOSurface.mm
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Tools/TestWebKitAPI/Tests/WebCore/cocoa/IOSurfaceTests.mm
Log Message:
-----------
Cherry-pick 5126b6a5a9e2. rdar://184747345
In WebPageProxy::takeSnapshot(), validate IOSurface from MachSendRight
rdar://176886608
Reviewed by Mike Wyrzykowski.
WebPageProxy::takeSnapshot() now uses the new
IOSurface::createFromUntrustedSendRight(), which has stronger checks of
the MachSendRight-provided IOSurface, expecting a valid IOSurface as
produced uncompressed and uni-planar from IOSurface::create().
Test: Tools/TestWebKitAPI/Tests/WebCore/cocoa/IOSurfaceTests.mm
* Source/WebCore/platform/graphics/cocoa/IOSurface.h:
* Source/WebCore/platform/graphics/cocoa/IOSurface.mm:
(WebCore::validateAndCreateFromUntrustedSurface):
(WebCore::IOSurface::createFromUntrustedUncompressedWebKitSendRight):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::takeSnapshot):
* Tools/TestWebKitAPI/Tests/WebCore/cocoa/IOSurfaceTests.mm:
(TestWebKitAPI::TEST(IOSurfaceTest,
createFromUntrustedUncompressedWebKitSendRightSRGB)):
(TestWebKitAPI::TEST(IOSurfaceTest,
createFromUntrustedUncompressedWebKitSendRightRGBA16F)):
(TestWebKitAPI::TEST(IOSurfaceTest,
createFromUntrustedUncompressedWebKitSendRightYUV422)):
Identifier: [email protected]
(cherry picked from commit ad19c98423d04bb3602ca9a961d99e53b933948b)
Canonical link: https://commits.webkit.org/[email protected]
Commit: 0c54d370df8b8f2d7aadb6e2f02944083926aced
https://github.com/WebKit/WebKit/commit/0c54d370df8b8f2d7aadb6e2f02944083926aced
Author: Charlie Wolfe <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick 8d9bf389bc0f. rdar://184747528
Validate several ITP and storage access IPC messages
https://bugs.webkit.org/show_bug.cgi?id=318244
rdar://180785498
Reviewed by Matthew Finkel.
This relands the validation that was reverted in rdar://180738421.
Telemetry indicates the
LogUserInteraction MESSAGE_CHECK could rarely fail. It is unclear how this
could happen, so it has
been replaced with an early return and assertion to avoid crashing the
WebContent process.
Test: ipc/forged-resource-load-statistics-storage-access.html
*
LayoutTests/ipc/forged-resource-load-statistics-storage-access-expected.txt:
Added.
* LayoutTests/ipc/forged-resource-load-statistics-storage-access.html:
Added.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::logUserInteraction):
(WebKit::resourceLoadStatisticsContainsOnlyObservableFields):
(WebKit::NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated):
(WebKit::NetworkConnectionToWebProcess::requestStorageAccessUnderOpener):
Identifier: [email protected]
(cherry picked from commit a810bf736945dea451085f03f561ef8718b91a43)
Canonical link: https://commits.webkit.org/[email protected]
Commit: 94873b9cc94ed14f3b2e8a796a6e1ccacf655514
https://github.com/WebKit/WebKit/commit/94873b9cc94ed14f3b2e8a796a6e1ccacf655514
Author: Matthew Finkel <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
A
LayoutTests/http/tests/cookies/same-site/fetch-in-srcdoc-iframe-inside-cross-origin-iframe-expected.txt
A
LayoutTests/http/tests/cookies/same-site/fetch-in-srcdoc-iframe-inside-cross-origin-iframe.html
A
LayoutTests/http/tests/cookies/same-site/img-from-srcdoc-iframe-inside-cross-origin-iframe-expected.txt
A
LayoutTests/http/tests/cookies/same-site/img-from-srcdoc-iframe-inside-cross-origin-iframe.html
A LayoutTests/http/tests/cookies/same-site/resources/record-image-cookies.py
A
LayoutTests/http/tests/cookies/same-site/resources/srcdoc-creator-img-inside-cross-origin-iframe.html
A
LayoutTests/http/tests/cookies/same-site/resources/srcdoc-creator-inside-cross-origin-iframe.html
M Source/WebCore/loader/FrameLoader.cpp
Log Message:
-----------
Cherry-pick edd74642a6ef. rdar://184747426
Srcdoc iframes bypass SameSite Strict and Lax cookies
https://bugs.webkit.org/show_bug.cgi?id=313220
rdar://175498842
Reviewed by Charlie Wolfe.
When we set firstPartyForCookies on a subframe, we check if either:
1) shouldInheritSecurityOriginFromOwner is true for the current document's
URL, or
2) if the current document's URL is same-registrable-domain as the
top-level document URL
In the case of an iframe with srcdoc, shouldInheritSecurityOriginFromOwner
returns true (as documented), and this causes us to set the page's
mainFrameURL
as the firstPartyForCookies. We need a conditional exception for
shouldInheritSecurityOriginFromOwner, but it should take nested iframes into
account. This patch adjusts the logic so we inherit the ancestor frame's
siteForCookies instead of the page's URL. The same-registrable-domain check
remains unchanged.
Test:
http/tests/cookies/same-site/fetch-in-srcdoc-iframe-inside-cross-origin-iframe.html
*
LayoutTests/http/tests/cookies/same-site/fetch-in-srcdoc-iframe-inside-cross-origin-iframe-expected.txt:
Added.
*
LayoutTests/http/tests/cookies/same-site/fetch-in-srcdoc-iframe-inside-cross-origin-iframe.html:
Added.
*
LayoutTests/http/tests/cookies/same-site/img-from-srcdoc-iframe-inside-cross-origin-iframe-expected.txt:
Added.
*
LayoutTests/http/tests/cookies/same-site/img-from-srcdoc-iframe-inside-cross-origin-iframe.html:
Added.
*
LayoutTests/http/tests/cookies/same-site/resources/record-image-cookies.py:
Added.
*
LayoutTests/http/tests/cookies/same-site/resources/srcdoc-creator-img-inside-cross-origin-iframe.html:
Added.
*
LayoutTests/http/tests/cookies/same-site/resources/srcdoc-creator-inside-cross-origin-iframe.html:
Added.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::setFirstPartyForCookies):
Identifier: [email protected]
(cherry picked from commit 5020fc768893ba78bd86481ddd288097d2e41808)
Canonical link: https://commits.webkit.org/[email protected]
Commit: f0e7c2c4eb0f57729c0a9ac91d4e431110a5d9be
https://github.com/WebKit/WebKit/commit/f0e7c2c4eb0f57729c0a9ac91d4e431110a5d9be
Author: Sihui Liu <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h
Log Message:
-----------
Cherry-pick b2b34862739c. rdar://184747515
Enable storage site validation
rdar://172706201
Reviewed by Chris Dumez.
Enable WebsiteDataStore::m_storageSiteValidationEnabled by default so
NetworkStorageManager validates the site on
messages it receives.
Replace MESSAGE_CHECK with STORAGE_MESSAGE_CHECK for site validation
checks. STORAGE_MESSAGE_CHECK generates a simulated
crash and returns an error instead of terminating the sender process. This
blocks storage access from compromised
processes while allowing us to monitor for false positives before upgrading
to MESSAGE_CHECK.
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::persisted):
(WebKit::NetworkStorageManager::persist):
(WebKit::NetworkStorageManager::estimate):
(WebKit::NetworkStorageManager::fileSystemGetDirectory):
(WebKit::NetworkStorageManager::connectToStorageArea):
(WebKit::NetworkStorageManager::cancelConnectToStorageArea):
(WebKit::NetworkStorageManager::disconnectFromStorageArea):
(WebKit::NetworkStorageManager::setItem):
(WebKit::NetworkStorageManager::removeItem):
(WebKit::NetworkStorageManager::clear):
(WebKit::NetworkStorageManager::openDBRequestCancelled):
(WebKit::NetworkStorageManager::deleteDatabase):
(WebKit::NetworkStorageManager::databaseConnectionClosed):
(WebKit::NetworkStorageManager::getAllDatabaseNamesAndVersions):
(WebKit::NetworkStorageManager::cacheStorageOpenCache):
(WebKit::NetworkStorageManager::cacheStorageRemoveCache):
(WebKit::NetworkStorageManager::cacheStorageAllCaches):
(WebKit::NetworkStorageManager::cacheStorageReference):
(WebKit::NetworkStorageManager::cacheStorageDereference):
(WebKit::NetworkStorageManager::lockCacheStorage):
(WebKit::NetworkStorageManager::unlockCacheStorage):
(WebKit::NetworkStorageManager::cacheStorageRetrieveRecords):
(WebKit::NetworkStorageManager::cacheStorageRemoveRecords):
(WebKit::NetworkStorageManager::cacheStoragePutRecords):
(WebKit::NetworkStorageManager::cacheStorageClearMemoryRepresentation):
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h:
Identifier: 305413.905@safari-7624-branch
(cherry picked from commit 8a2c164606499ac2c14a259b18055655d7316772)
Canonical link: https://commits.webkit.org/[email protected]
Commit: 25e9eda8245141c4d82dc38680dbce481253581d
https://github.com/WebKit/WebKit/commit/25e9eda8245141c4d82dc38680dbce481253581d
Author: Ryosuke Niwa <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebCore/html/track/TrackBase.cpp
M Source/WebCore/html/track/TrackBase.h
Log Message:
-----------
Cherry-pick 33be61fed07c. rdar://184747619
Data race in TrackBase::opaqueRoot during GC leading to use-after-free
https://bugs.webkit.org/show_bug.cgi?id=311800
rdar://173766033
Reviewed by Jer Noble.
Store the opaque root value separately from m_trackList to avoid data race
during GC.
No new tests since there is no reliable way to test this data race.
* Source/WebCore/html/track/TrackBase.cpp:
(WebCore::TrackBase::setTrackList):
(WebCore::TrackBase::clearTrackList):
(WebCore::TrackBase::opaqueRoot): Deleted.
* Source/WebCore/html/track/TrackBase.h:
(WebCore::TrackBase::opaqueRoot const):
Identifier: 305413.636@safari-7624-branch
(cherry picked from commit 8d086397730a901ec402b1467c21c5ef06b381e3)
Canonical link: https://commits.webkit.org/[email protected]
Commit: 6faeed0391a2561638757775223a1b5677a8e1b5
https://github.com/WebKit/WebKit/commit/6faeed0391a2561638757775223a1b5677a8e1b5
Author: Roberto Rodriguez <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/inheritance/about-blank-from-javascript-url-inherits-csp-from-initiator.sub-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/inheritance/about-blank-from-javascript-url-inherits-csp-from-initiator.sub.html
A
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/inheritance/support/page-with-csp-marker.html
A
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/inheritance/support/page-with-csp-marker.html.headers
M LayoutTests/platform/ios-site-isolation/TestExpectations
M LayoutTests/platform/mac-site-isolation/TestExpectations
M Source/WebCore/loader/NavigationRequester.cpp
Log Message:
-----------
Cherry-pick 45512c517789. rdar://184747598
about:blank inherits cross-origin policy container due to empty document URL
https://bugs.webkit.org/show_bug.cgi?id=316512
rdar://176188073
Reviewed by Alex Christensen.
Documents created via javascript: URL have an empty internal URL.
Document::setURL() would
normally normalize this to aboutBlankURL(), but the call is conditionally
skipped during
document creation.
When one of these documents creates a cross-origin iframe and then
navigates it to about:blank,
the empty URL passes through NavigationRequester into
NavigationAction::isEmpty(), which
mistakes it for an action that was never set. The fallback in
FrameLoader::loadWithDocumentLoader
incorrectly rebuilds the action from the target frame's cross-origin
document rather than the
original initiator (the javascript: URL document). The about:blank then
inherits that document's
policy container instead of the initiator's, leaking its CSP and referrer
via
SecurityPolicyViolationEvent.
Fix by normalizing empty document URLs to aboutBlankURL() in
NavigationRequester::from(),
matching what Document::setURL() and Document::urlForBindings() already do.
Tests:
imported/w3c/web-platform-tests/content-security-policy/inheritance/about-blank-from-javascript-url-inherits-csp-from-initiator.sub.html
imported/w3c/web-platform-tests/content-security-policy/inheritance/support/page-with-csp-marker.html
*
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/inheritance/about-blank-from-javascript-url-inherits-csp-from-initiator.sub-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/inheritance/about-blank-from-javascript-url-inherits-csp-from-initiator.sub.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/inheritance/support/page-with-csp-marker.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/inheritance/support/page-with-csp-marker.html.headers:
Added.
* LayoutTests/platform/ios-site-isolation/TestExpectations:
* LayoutTests/platform/mac-site-isolation/TestExpectations:
* Source/WebCore/loader/NavigationRequester.cpp:
(WebCore::NavigationRequester::from):
Identifier: [email protected]
(cherry picked from commit 1bff10b94fdfbc5a4ae88d723bdf1d482465b18e)
Canonical link: https://commits.webkit.org/[email protected]
Commit: e22b7b47d4761f77fdad8d57d03253a3583e858f
https://github.com/WebKit/WebKit/commit/e22b7b47d4761f77fdad8d57d03253a3583e858f
Author: Mohsin Qureshi <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebCore/html/track/TrackBase.cpp
M Source/WebCore/html/track/TrackBase.h
Log Message:
-----------
Revert 33be61fed07c. rdar://184747619
This reverts commit 259686c37cedbe51d5344e403facc083c3b5a0f3.
Canonical link: https://commits.webkit.org/[email protected]
Commit: c955355cb5911e8dbe7dfb672385c9b7c9273863
https://github.com/WebKit/WebKit/commit/c955355cb5911e8dbe7dfb672385c9b7c9273863
Author: Mohsin Qureshi <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WTF/wtf/PlatformEnableCocoa.h
M Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h
M Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.mm
M Source/WTF/wtf/spi/darwin/dyldSPI.h
M Source/WebKit/NetworkProcess/cocoa/NetworkProcessCocoa.mm
M Source/WebKit/NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in
M Source/WebKit/Scripts/process-entitlements.sh
Log Message:
-----------
Cherry-pick 8f582cb. rdar://184747435
[macOS] The Networking process sandbox should inherit network access from
the UI process
https://bugs.webkit.org/show_bug.cgi?id=311807
rdar://171541375
Reviewed by Chris Dumez.
This was already fixed for iOS in rdar://159116963. This patch enables the
feature on macOS
with an additional link check.
No new tests, since both WebKitTestRunner and TestWebKitAPI are not
blocking network access.
* Source/WTF/wtf/PlatformEnableCocoa.h:
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h:
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.mm:
(WTF::computeSDKAlignedBehaviors):
* Source/WTF/wtf/spi/darwin/dyldSPI.h:
* Source/WebKit/NetworkProcess/cocoa/NetworkProcessCocoa.mm:
(WebKit::blockNetworkAccessIfNeeded):
(WebKit::NetworkProcess::platformInitializeNetworkProcessCocoa):
* Source/WebKit/NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in:
* Source/WebKit/Scripts/process-entitlements.sh:
Identifier: 305413.701@safari-7624-branch
* Source/WTF/wtf/PlatformEnableCocoa.h:
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.h:
* Source/WTF/wtf/cocoa/RuntimeApplicationChecksCocoa.mm:
(WTF::computeSDKAlignedBehaviors):
* Source/WTF/wtf/spi/darwin/dyldSPI.h:
* Source/WebKit/NetworkProcess/cocoa/NetworkProcessCocoa.mm:
(WebKit::blockNetworkAccessIfNeeded):
(WebKit::NetworkProcess::platformInitializeNetworkProcessCocoa):
* Source/WebKit/NetworkProcess/mac/com.apple.WebKit.NetworkProcess.sb.in:
* Source/WebKit/Scripts/process-entitlements.sh:
(cherry picked from commit 4efb9daa5f616b57bc3904b50ffc6035ac5d10ff)
Canonical link: https://commits.webkit.org/[email protected]
Commit: ee41eb64cf795a2e3081c3f50283896eda077967
https://github.com/WebKit/WebKit/commit/ee41eb64cf795a2e3081c3f50283896eda077967
Author: Sihui Liu <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebKit/NetworkProcess/storage/FileSystemStorageHandle.cpp
M Source/WebKit/NetworkProcess/storage/FileSystemStorageHandle.h
M Source/WebKit/NetworkProcess/storage/FileSystemStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/FileSystemStorageManager.h
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h
M Source/WebKit/NetworkProcess/storage/OriginStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/OriginStorageManager.h
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/IPCTestingAPI.mm
Log Message:
-----------
Cherry-pick 9945ade1f70a. rdar://184747450
Validate connection access to FileSystem storage with
FileSystemHandleIdentifier
rdar://176773267
Reviewed by Chris Dumez.
Many FileSystem-related messages sent to NetworkStorageManager only carries
FileSystemHandleIdentifier when asking to
operate on FileSystem storage, and NetworkStorageManager does not check
whether the sender process actually has access
to requested handle. This lets a compromised process forge
FileSystemHandleIdentifier and access data from other
origins. To fix it, this patch stores the origin in
FileSystemStorageManager and adding an origin accessor to
FileSystemStorageHandle, so that NetworkStorageManager can run
isSiteAllowedForConnection in FileSystem-related message
handlers.
API test: IPCTestingAPI.FileSystemForgedHandleIdentifierRejected
* Source/WebKit/NetworkProcess/storage/FileSystemStorageHandle.cpp:
(WebKit::FileSystemStorageHandle::origin const):
* Source/WebKit/NetworkProcess/storage/FileSystemStorageHandle.h:
* Source/WebKit/NetworkProcess/storage/FileSystemStorageManager.cpp:
(WebKit::FileSystemStorageManager::create):
(WebKit::FileSystemStorageManager::FileSystemStorageManager):
* Source/WebKit/NetworkProcess/storage/FileSystemStorageManager.h:
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::fileSystemGetDirectory):
(WebKit::NetworkStorageManager::closeHandle):
(WebKit::NetworkStorageManager::isSameEntry):
(WebKit::NetworkStorageManager::move):
(WebKit::NetworkStorageManager::getFileHandle):
(WebKit::NetworkStorageManager::getDirectoryHandle):
(WebKit::NetworkStorageManager::removeEntry):
(WebKit::NetworkStorageManager::resolve):
(WebKit::NetworkStorageManager::getFile):
(WebKit::NetworkStorageManager::createSyncAccessHandle):
(WebKit::NetworkStorageManager::closeSyncAccessHandle):
(WebKit::NetworkStorageManager::requestNewCapacityForSyncAccessHandle):
(WebKit::NetworkStorageManager::createWritable):
(WebKit::NetworkStorageManager::closeWritable):
(WebKit::NetworkStorageManager::executeCommandForWritable):
(WebKit::NetworkStorageManager::getHandleNames):
(WebKit::NetworkStorageManager::getHandle):
(WebKit::NetworkStorageManager::canConnectionAccessFileSystemHandle const):
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h:
* Source/WebKit/NetworkProcess/storage/OriginStorageManager.cpp:
(WebKit::OriginStorageManager::StorageBucket::fileSystemStorageManager):
(WebKit::OriginStorageManager::fileSystemStorageManager):
* Source/WebKit/NetworkProcess/storage/OriginStorageManager.h:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/IPCTestingAPI.mm:
(function):
((IPCTestingAPI, FileSystemForgedHandleIdentifierRejected)):
Identifier: [email protected]
(cherry picked from commit bdb293f4b35d0e6654a9fe1088cab27ab4834c15)
Canonical link: https://commits.webkit.org/[email protected]
Commit: 1c98ad93b1c580417a969a577b267935897addcf
https://github.com/WebKit/WebKit/commit/1c98ad93b1c580417a969a577b267935897addcf
Author: Pascoe <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebCore/loader/FrameLoader.cpp
M
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/VerifyUserGestureFromUIProcess.mm
Log Message:
-----------
Cherry-pick 2057f457fb75. rdar://184747505
Popunder bypass via overlappping transient activations
https://bugs.webkit.org/show_bug.cgi?id=316816
rdar://177442177
Reviewed by Charlie Wolfe and Abrar Rahman Protyasha.
We should consume transient activations to avoid popunders.
Test:
Tools/TestWebKitAPI/Tests/WebKitCocoa/VerifyUserGestureFromUIProcess.mm
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::createWindow):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/VerifyUserGestureFromUIProcess.mm:
(TestWebKitAPI::TEST(VerifyUserGesture,
PopunderPreventedViaDualEventListeners)):
Identifier: [email protected]
(cherry picked from commit 8179d5db9408e9fb3636a2a6b64229e21d5f7a45)
Canonical link: https://commits.webkit.org/[email protected]
Commit: 74b907798b6f66006da5c0940cf6f728897a8492
https://github.com/WebKit/WebKit/commit/74b907798b6f66006da5c0940cf6f728897a8492
Author: Ryosuke Niwa <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebCore/Modules/mediasource/SourceBuffer.cpp
M Source/WebCore/Modules/mediasource/SourceBuffer.h
M Source/WebCore/Sources.txt
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
A Source/WebCore/bindings/js/JSHTMLMediaElementCustom.cpp
M Source/WebCore/html/HTMLMediaElement.cpp
M Source/WebCore/html/HTMLMediaElement.h
M Source/WebCore/html/HTMLMediaElement.idl
M Source/WebCore/html/track/TextTrackList.cpp
M Source/WebCore/html/track/TextTrackList.h
M Source/WebCore/html/track/TrackBase.cpp
M Source/WebCore/html/track/TrackBase.h
M Source/WebCore/html/track/TrackListBase.cpp
M Source/WebCore/html/track/TrackListBase.h
A Source/WebCore/html/track/TrackOpaqueRoot.h
Log Message:
-----------
Cherry-pick 3cbf2f5adfe0. rdar://184747619
Data race in TrackBase::opaqueRoot during GC leading to use-after-free
https://bugs.webkit.org/show_bug.cgi?id=311800
rdar://176058579
Reviewed by Geoffrey Garen.
To fix the data race, we introduce SourceBuffer and HTMLMediaElement as
opaque roots for Track* classes
and *TrackList classes instead of using the root node of HTMLMediaElement
which can change over time.
We introduce TrackOpaqueRoot, which is a thin ThreadSafeRefCounted wrapper
around WebCoreOpaqueRoot,
and initialize it with WebCoreOpaqueRoot pointing to SourceBuffer or
HTMLMediaElement.
Each Track and TrackList class will have RefPtr<TrackOpaqueRoot> and reads
the opaque root directly
from a GC thread without relying on any pointer indirections.
No new tests since there is no reliable way to test this data race.
* Source/WebCore/Modules/mediasource/SourceBuffer.cpp:
(WebCore::SourceBuffer::SourceBuffer):
(WebCore::SourceBuffer::~SourceBuffer):
(WebCore::SourceBuffer::videoTracks):
(WebCore::SourceBuffer::audioTracks):
(WebCore::SourceBuffer::textTracks):
(WebCore::m_logIdentifier): Deleted.
* Source/WebCore/Modules/mediasource/SourceBuffer.h:
* Source/WebCore/Sources.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/bindings/js/JSHTMLMediaElementCustom.cpp: Added.
(WebCore::JSHTMLMediaElement::visitAdditionalChildren):
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::m_trackOpaqueRoot):
(WebCore::HTMLMediaElement::~HTMLMediaElement):
(WebCore::HTMLMediaElement::ensureAudioTracks):
(WebCore::HTMLMediaElement::ensureTextTracks):
(WebCore::HTMLMediaElement::ensureVideoTracks):
(WebCore::m_opaqueRootProvider): Deleted.
* Source/WebCore/html/HTMLMediaElement.h:
(WebCore::HTMLMediaElement::trackOpaqueRoot):
* Source/WebCore/html/HTMLMediaElement.idl:
* Source/WebCore/html/track/TextTrackList.cpp:
(WebCore::TextTrackList::setOpaqueRoot):
* Source/WebCore/html/track/TextTrackList.h:
* Source/WebCore/html/track/TrackBase.cpp:
(WebCore::TrackBase::setOpaqueRoot):
(WebCore::TrackBase::opaqueRoot):
(WebCore::TrackBase::setTrackList):
(WebCore::TrackBase::clearTrackList):
* Source/WebCore/html/track/TrackBase.h:
* Source/WebCore/html/track/TrackListBase.cpp:
(WebCore::TrackListBase::setOpaqueRoot):
(WebCore::TrackListBase::opaqueRoot):
* Source/WebCore/html/track/TrackListBase.h:
(WebCore::TrackListBase::trackOpaqueRoot):
(WebCore::TrackListBase::setOpaqueRootObserver): Deleted.
* Source/WebCore/html/track/TrackOpaqueRoot.h: Added.
(WebCore::TrackOpaqueRoot::create):
(WebCore::TrackOpaqueRoot::opaqueRoot const):
(WebCore::TrackOpaqueRoot::clear):
(WebCore::TrackOpaqueRoot::TrackOpaqueRoot):
Identifier: [email protected]
* Source/WebCore/Modules/mediasource/SourceBuffer.cpp:
(WebCore::SourceBuffer::SourceBuffer):
(WebCore::SourceBuffer::~SourceBuffer):
(WebCore::SourceBuffer::videoTracks):
(WebCore::SourceBuffer::audioTracks):
(WebCore::SourceBuffer::textTracks):
(WebCore::m_logIdentifier): Deleted.
* Source/WebCore/Modules/mediasource/SourceBuffer.h:
* Source/WebCore/Sources.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/bindings/js/JSHTMLMediaElementCustom.cpp: Added.
(WebCore::JSHTMLMediaElement::visitAdditionalChildrenInGCThread):
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::m_trackOpaqueRoot):
(WebCore::HTMLMediaElement::~HTMLMediaElement):
(WebCore::HTMLMediaElement::ensureAudioTracks):
(WebCore::HTMLMediaElement::ensureTextTracks):
(WebCore::HTMLMediaElement::ensureVideoTracks):
(WebCore::m_opaqueRootProvider): Deleted.
* Source/WebCore/html/HTMLMediaElement.h:
(WebCore::HTMLMediaElement::trackOpaqueRoot):
* Source/WebCore/html/HTMLMediaElement.idl:
* Source/WebCore/html/track/TextTrackList.cpp:
(WebCore::TextTrackList::setOpaqueRoot):
* Source/WebCore/html/track/TextTrackList.h:
* Source/WebCore/html/track/TrackBase.cpp:
(WebCore::TrackBase::setOpaqueRoot):
(WebCore::TrackBase::opaqueRoot const):
(WebCore::TrackBase::setTrackList):
(WebCore::TrackBase::clearTrackList):
* Source/WebCore/html/track/TrackBase.h:
* Source/WebCore/html/track/TrackListBase.cpp:
(WebCore::TrackListBase::setOpaqueRoot):
(WebCore::TrackListBase::opaqueRoot const):
* Source/WebCore/html/track/TrackListBase.h:
(WebCore::TrackListBase::trackOpaqueRoot):
(WebCore::TrackListBase::setOpaqueRootObserver): Deleted.
* Source/WebCore/html/track/TrackOpaqueRoot.h: Added.
(WebCore::TrackOpaqueRoot::create):
(WebCore::TrackOpaqueRoot::opaqueRoot const):
(WebCore::TrackOpaqueRoot::clear):
(WebCore::TrackOpaqueRoot::TrackOpaqueRoot):
(cherry picked from commit ed5961bd18f9cba1b74106052b07e09513d5ae3c)
Canonical link: https://commits.webkit.org/[email protected]
Commit: 5763c199620dd79b211a8bf4aad3197f7fba3343
https://github.com/WebKit/WebKit/commit/5763c199620dd79b211a8bf4aad3197f7fba3343
Author: Sihui Liu <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp
M Source/WebKit/NetworkProcess/storage/CacheStorageCache.h
M Source/WebKit/NetworkProcess/storage/CacheStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/CacheStorageManager.h
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h
M Source/WebKit/NetworkProcess/storage/OriginStorageManager.cpp
Log Message:
-----------
Cherry-pick d4dc872e5bf9. rdar://184747554
Validate connection access to DOMCache with DOMCacheIdentifier
rdar://176470206
Reviewed by Chris Dumez.
Many CacheStorage-related messages sent to NetworkStorageManager only
carries DOMCacheIdentifier when asking to operate
on DOMCache storage, and NetworkStorageManager does not check whether the
sender process actually has access to
requested cache. This lets a compromised process forge DOMCacheIdentifier
and access data from other origins. To fix it,
this patch stores the origin in CacheStorageManager and adding an origin
accessor to CacheStorageCache, so that
NetworkStorageManager can run isSiteAllowedForConnection in
CacheStorage-related message handlers.
* Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp:
(WebKit::CacheStorageCache::origin const):
* Source/WebKit/NetworkProcess/storage/CacheStorageCache.h:
* Source/WebKit/NetworkProcess/storage/CacheStorageManager.cpp:
(WebKit::CacheStorageManager::create):
(WebKit::CacheStorageManager::CacheStorageManager):
* Source/WebKit/NetworkProcess/storage/CacheStorageManager.h:
(WebKit::CacheStorageManager::origin const):
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::cacheStorageRemoveCache):
(WebKit::NetworkStorageManager::cacheStorageReference):
(WebKit::NetworkStorageManager::cacheStorageRetrieveRecords):
(WebKit::NetworkStorageManager::cacheStorageRemoveRecords):
(WebKit::NetworkStorageManager::cacheStoragePutRecords):
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h:
* Source/WebKit/NetworkProcess/storage/OriginStorageManager.cpp:
(WebKit::OriginStorageManager::StorageBucket::cacheStorageManager):
Identifier: [email protected]
(cherry picked from commit 116b1f39484f1822a7ccb064e879ef00aab04dac)
Canonical link: https://commits.webkit.org/[email protected]
Commit: db1a243a7a2b15b8812e5d598b0487c558b9cf6f
https://github.com/WebKit/WebKit/commit/db1a243a7a2b15b8812e5d598b0487c558b9cf6f
Author: Shu-yu Guo <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
A JSTests/stress/spread-set-cross-realm-symbol-iterator-side-effects.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
Cherry-pick 62860f03b72a. rdar://184821678
[JSC] Fix cross-realm DFG Set spread optimization
https://bugs.webkit.org/show_bug.cgi?id=321705
rdar://184821678
Reviewed by Keith Miller and Mark Lam.
The DFG optimization for spreading a Set depends on the Set iterator
protocol
being intact. This is guarded by a watchpoint. This watchpoint is armed on
the
global of the set itself, which is node->child1(). Subsequent optimization
passes incorrectly depends on the Set structure of node, which corresponds
to
the spread operation itself and may be in a different realm than the set.
This PR fixes this by using child1() everywhere to determine the global.
Test: JSTests/stress/spread-set-cross-realm-symbol-iterator-side-effects.js
* JSTests/stress/spread-set-cross-realm-symbol-iterator-side-effects.js:
Added.
(shouldBe):
* Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
Identifier: 316606.361@safari-7625-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 8505dacafe53f0b9df5a4ed70a15176a818fba3f
https://github.com/WebKit/WebKit/commit/8505dacafe53f0b9df5a4ed70a15176a818fba3f
Author: Mohsin Qureshi <[email protected]>
Date: 2026-08-13 (Thu, 13 Aug 2026)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning. WebKit-7625.1.29.11.24
Canonical link: https://commits.webkit.org/[email protected]
Commit: 84167bbed406d46e25dd0dda890703480995c66b
https://github.com/WebKit/WebKit/commit/84167bbed406d46e25dd0dda890703480995c66b
Author: Mohsin Qureshi <[email protected]>
Date: 2026-08-18 (Tue, 18 Aug 2026)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning. WebKit-7625.1.29.11.25
Canonical link: https://commits.webkit.org/[email protected]
Commit: 8223308782106393f42923844db5b83ef7e9250c
https://github.com/WebKit/WebKit/commit/8223308782106393f42923844db5b83ef7e9250c
Author: Timothy Hatcher <[email protected]>
Date: 2026-08-18 (Tue, 18 Aug 2026)
Changed paths:
M Source/WebKit/UIProcess/Extensions/WebExtensionContext.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WKWebExtensionAPIScripting.mm
Log Message:
-----------
Cherry-pick 7f6a77dee81b. rdar://176067024
Extension scripts/style sheets are injected into denied domains if Other
Websites are set to allow.
https://webkit.org/b/309516
rdar://171724038
Reviewed by Brian Weinstein.
During Objective-C++ to C++ conversion, NSMutableSet's unionSet: (modifies
in place) was incorrectly
translated to HashSet::unionWith() (returns new set). Changed to addAll()
to match original semantics.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIScripting.mm
* Source/WebKit/UIProcess/Extensions/WebExtensionContext.cpp:
(WebKit::WebExtensionContext::addInjectedContent): Use addAll() instead of
unionWith().
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebExtensionAPIScripting.mm:
(TestWebKitAPI::TEST(WKWebExtensionAPIScripting,
ContentScriptsRespectDeniedMatchPatterns)): Added.
Identifier: 305413.426@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: b66f95ce0af20de075effe2c3784e3cc81fc7f35
https://github.com/WebKit/WebKit/commit/b66f95ce0af20de075effe2c3784e3cc81fc7f35
Author: Mohsin Qureshi <[email protected]>
Date: 2026-08-25 (Tue, 25 Aug 2026)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning. WebKit-7625.1.29.11.26
Canonical link: https://commits.webkit.org/[email protected]
Commit: 9bbc2aeed8b8509903aaff39b559d91b07824bc5
https://github.com/WebKit/WebKit/commit/9bbc2aeed8b8509903aaff39b559d91b07824bc5
Author: Jer Noble <[email protected]>
Date: 2026-08-25 (Tue, 25 Aug 2026)
Changed paths:
M Source/WebKit/GPUProcess/media/RemoteAudioVideoRendererProxyManager.cpp
Log Message:
-----------
Cherry-pick 5173c0afd8a3. rdar://185754413
[macOS] YouTube.com audio continues to play after tab is closed
rdar://185505597
https://bugs.webkit.org/show_bug.cgi?id=322448
Reviewed by Jean-Yves Avenard and Abrar Rahman Protyasha.
User reports indicate YouTube.com audio playback is continuing under some
circumstances, even after
the tab containing the YouTube.com page is closed. Subsequent analysis of
users' logs reveals that
the AudioVideoRenderAVFObjC object continues playback until it runs out of
enqueued buffers and
stalls. The teardown path inside
RemoteAudioVideoRendererProxyManager::shutdown() is being called,
and in fact the RemoteAudioVideoRendererProxyManager itself is being
destroyed. But if
RemoteAudioVideoRendererProxyManager is not the lone holder of the
AudioVideoRenderer RefPtr, its
refcount will not drop to zero and audio will continue until either buffers
run dry or the last
remaining RefPtr is destroyed.
Rather than rely on the refcount dropping to zero to end playback,
explicitly pause() and flush
() the renderer when shutting down a player, and do the same to all
outstanding renderers when the
Manager itself is destroyed.
* Source/WebKit/GPUProcess/media/RemoteAudioVideoRendererProxyManager.cpp:
(WebKit::RemoteAudioVideoRendererProxyManager::~RemoteAudioVideoRendererProxyManager):
(WebKit::RemoteAudioVideoRendererProxyManager::shutdown):
Canonical link: https://commits.webkit.org/319759@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: cdad99beae8e57a172c57f4bbe877b0fada9a855
https://github.com/WebKit/WebKit/commit/cdad99beae8e57a172c57f4bbe877b0fada9a855
Author: Jer Noble <[email protected]>
Date: 2026-08-25 (Tue, 25 Aug 2026)
Changed paths:
M Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp
M Source/WebKit/GPUProcess/media/RemoteAudioVideoRendererProxyManager.cpp
M Source/WebKit/GPUProcess/media/RemoteAudioVideoRendererProxyManager.h
Log Message:
-----------
Cherry-pick 1018e6f4e438. rdar://185754413
[macOS] YouTube.com audio continues to play after tab is closed
rdar://185505597
https://bugs.webkit.org/show_bug.cgi?id=322533
Reviewed by Eric Carlson and Andy Estes.
In 319759@main, RemoteAudioVideoRendererProxyManager was modified to
explicitly
pause and flush all renderers when the manager was destroyed, and to
explicitly
pause and flush individual renderers in shutdown(). However, this was not
sufficient to completely eliminate the behavior in question. Logging showed
that both a) the WebContent process was being destroyed before a pause() IPC
could be sent b) the GPUConnectionToWebContent process destructor wasn't
being
called This means the pause behavior added to
RemoteAudioVideoRendererProxyManager's destructor wasn't being called
either.
Rather than relying on the RefCounted GPUConnectionToWebContent object being
fully destroyed before tearing down all our audio and video renderers, adopt
the same mechanism used for other objects owned by the connection:
GPUConnectionToWebProcess::didClose(). Logging shows this method is called
while reproducing the bug, even when the GPUConnectionToWebProcess itself is
not subsequently destroyed.
* Source/WebKit/GPUProcess/media/RemoteAudioVideoRendererProxyManager.cpp:
(WebKit::RemoteAudioVideoRendererProxyManager::connectionToWebProcessClosed):
* Source/WebKit/GPUProcess/media/RemoteAudioVideoRendererProxyManager.h:
* Source/WebKit/GPUProcess/GPUConnectionToWebProcess.cpp
(WebKit::GPUConnectionToWebProcess::didClose):
Canonical link: https://commits.webkit.org/319842@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 9b39c5ef574210fa6f22e93cd786d5a701521d64
https://github.com/WebKit/WebKit/commit/9b39c5ef574210fa6f22e93cd786d5a701521d64
Author: Matthew Finkel <[email protected]>
Date: 2026-09-02 (Wed, 02 Sep 2026)
Changed paths:
M Source/WebCore/platform/network/DNS.cpp
M Source/WebCore/platform/network/DNS.h
M Source/WebCore/platform/network/DNSResolveQueue.h
M Source/WebCore/platform/network/cf/DNSResolveQueueCFNet.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.h
M Source/WebKit/NetworkProcess/NetworkProcess.messages.in
M Source/WebKit/NetworkProcess/NetworkSession.h
M Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.h
M Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm
M Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h
M Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp
M Source/WebKit/UIProcess/Network/NetworkProcessProxy.h
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/Proxy.mm
Log Message:
-----------
Cherry-pick b3ceae24569e. rdar://186475843
DNS Prefetch is performed when proxy is configured, bypassing proxy
https://bugs.webkit.org/show_bug.cgi?id=321155
rdar://184085806
Reviewed by Alex Christensen.
A website can request that a domain name is preemptively looked up and
cached
for future use. WebKit support this behavior, but we don't consider whether
the
embedder configured a proxy. As a result, the hostname is resolved using the
system's resolver and this may bypass the proxy. This patch takes the easy
solution and avoids performing the prefetch is we have a proxy
configuration.
This patch adds two new tests with supporting test SPI. The first test
queries
the "canProxy" logic, and the second test monitors the DNS code to ensure
that
we never reach that code path when the proxy is configured.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::prefetchDNS):
* Source/WebKit/NetworkProcess/NetworkSession.h:
(WebKit::NetworkSession::canPrefetchDNS):
(WebKit::NetworkSession::canPrefetchDNS const):
* Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.h:
* Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm:
(WebKit::NetworkSessionCocoa::prefetchDNS):
(WebKit::NetworkSessionCocoa::canPrefetchDNS):
(WebKit::NetworkSessionCocoa::canPrefetchDNS const):
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::canPrefetchDNSForTesting):
(WebKit::NetworkProcess::prefetchedDNSHostnameCountForTesting const):
* Source/WebKit/NetworkProcess/NetworkProcess.h:
* Source/WebCore/platform/network/DNS.cpp:
(WebCore::prefetchedHostnameCountForTesting):
* Source/WebCore/platform/network/DNS.h:
* Source/WebCore/platform/network/DNSResolveQueue.h:
(WebCore::DNSResolveQueue::prefetchedHostnameCountForTesting const):
* Source/WebKit/NetworkProcess/NetworkProcess.messages.in:
* Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStore.mm:
(-[WKWebsiteDataStore _canPrefetchDNSForTesting:]):
(-[WKWebsiteDataStore _prefetchedDNSHostnameCountForTesting:]):
* Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:
* Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:
(WebKit::NetworkProcessProxy::canPrefetchDNSForTesting):
(WebKit::NetworkProcessProxy::prefetchedDNSHostnameCountForTesting):
* Source/WebKit/UIProcess/Network/NetworkProcessProxy.h:
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:
(WebKit::WebsiteDataStore::canPrefetchDNSForTesting const):
(WebKit::WebsiteDataStore::prefetchedDNSHostnameCountForTesting const):
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h:
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/Proxy.mm:
(TestWebKitAPI::TEST(WebKit, CanPrefetchDNSWithProxyConfigured)):
(TestWebKitAPI::TEST(WebKit, PrefetchDNSSkippedWhenProxyConfigured)):
* Source/WebCore/platform/network/cf/DNSResolveQueueCFNet.cpp:
(WebCore::DNSResolveQueueCFNet::performDNSLookup):
Identifier: 316606.353@safari-7625-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: da2d2a5748473a20d03d654e383b91c1b578c22b
https://github.com/WebKit/WebKit/commit/da2d2a5748473a20d03d654e383b91c1b578c22b
Author: Matthew Finkel <[email protected]>
Date: 2026-09-02 (Wed, 02 Sep 2026)
Changed paths:
M Source/WebCore/PAL/pal/spi/cf/CFNetworkSPI.h
M Source/WebKit/Configurations/AllowedSPI.toml
M Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.h
M Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm
M
Source/WebKit/NetworkProcess/webtransport/cocoa/NetworkTransportSessionCocoa.mm
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WebTransport.mm
Log Message:
-----------
Cherry-pick 1a56dddcac89. rdar://186475749
[cocoa] WebTransport doesn't consider when proxy is configured, bypassing
proxy
https://bugs.webkit.org/show_bug.cgi?id=321159
rdar://184195209
Reviewed by Alex Christensen.
WebTransport connections are created directly using API from Network
Framework,
and WebKit must configure the proxies we know about on these connections.
This
patch resolves the issue where the proxies weren't configured, and
WebTransport
connections could bypass them.
* Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.h:
* Source/WebKit/NetworkProcess/cocoa/NetworkSessionCocoa.mm:
(WebKit::NetworkSessionCocoa::applyProxyConfigurationToNWParameters):
(isProxyTypeTCPOnly):
(WebKit::NetworkSessionCocoa::proxyConfigurationRequiresTCPProtocols const):
(WebKit::NetworkSessionCocoa::applyWebTransportProxyConfigurationToNWParameters):
(WebKit::NetworkSessionCocoa::applyProxyConfigurationToNWParametersForWebTransport):
*
Source/WebKit/NetworkProcess/webtransport/cocoa/NetworkTransportSessionCocoa.mm:
(WebKit::createParameters):
(WebKit::NetworkTransportSession::create):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WebTransport.mm:
(TestWebKitAPI::BlockedBySOCKS5Proxy)):
(TestWebKitAPI::BlockedByHTTPConnectProxy)):
(TestWebKitAPI::NotBlockedWithoutProxy)):
* Source/WebCore/PAL/pal/spi/cf/CFNetworkSPI.h:
* Source/WebKit/Configurations/AllowedSPI.toml:
Identifier: 316606.354@safari-7625-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 2682441cf51ac5d17f32c2aff61ce56597dad6fb
https://github.com/WebKit/WebKit/commit/2682441cf51ac5d17f32c2aff61ce56597dad6fb
Author: Ishaan Kohli <[email protected]>
Date: 2026-09-02 (Wed, 02 Sep 2026)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning. WebKit-7625.1.29.11.27
Canonical link: https://commits.webkit.org/[email protected]
Commit: 2756e8be58521b10c8e8bff8da1f13d97f2eae27
https://github.com/WebKit/WebKit/commit/2756e8be58521b10c8e8bff8da1f13d97f2eae27
Author: Pascoe <[email protected]>
Date: 2026-09-02 (Wed, 02 Sep 2026)
Changed paths:
M Source/WebCore/Headers.cmake
A Source/WebCore/Modules/webauthn/WellKnownOriginList.cpp
A Source/WebCore/Modules/webauthn/WellKnownOriginList.h
M Source/WebCore/Sources.txt
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebKit/Sources.txt
M Source/WebKit/UIProcess/API/APIUIClient.h
M Source/WebKit/UIProcess/API/Cocoa/WKUIDelegatePrivate.h
M Source/WebKit/UIProcess/Cocoa/UIDelegate.h
M Source/WebKit/UIProcess/Cocoa/UIDelegate.mm
M
Source/WebKit/UIProcess/WebAuthentication/Cocoa/WebAuthenticatorCoordinatorProxy.mm
A Source/WebKit/UIProcess/WebAuthentication/RelatedOriginsValidator.cpp
A Source/WebKit/UIProcess/WebAuthentication/RelatedOriginsValidator.h
M
Source/WebKit/UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp
M
Source/WebKit/UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.h
A Source/WebKit/UIProcess/WellKnownResourceFetcher.cpp
A Source/WebKit/UIProcess/WellKnownResourceFetcher.h
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Tools/Scripts/webkitpy/api_tests/allowlist.txt
M Tools/TestWebKitAPI/CMakeLists.txt
M Tools/TestWebKitAPI/Helpers/cocoa/HTTPServer.h
M Tools/TestWebKitAPI/Helpers/cocoa/HTTPServer.mm
M Tools/TestWebKitAPI/SourcesCocoa.txt
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebCore/WellKnownOriginList.cpp
A Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WebAuthnRelatedOriginsFetch.mm
Log Message:
-----------
Cherry-pick 86e957015e02. rdar://186477323
[WebAuthn] Perform validation of related origins
https://bugs.webkit.org/show_bug.cgi?id=321380
rdar://problem/184430447
Reviewed by Abrar Rahman Protyasha.
Validate related origins in WebKit by fetching the RP's well-known resource
on the page's
network session.
The rules live in WebCore as WellKnownOriginList, which takes the endpoint
path and JSON
member name as arguments so that another feature can reuse them. The fetch
is
WellKnownResourceFetcher, bounded in both directions since the host is page
controlled.
33 unit tests cover the parsing and matching logic (label limits, malformed
JSON, scheme
validation, redirect policy). 15 API tests cover the fetch lifecycle
including timeout,
size limits, redirects, MIME enforcement, and the delegate receiving
validated origins.
* Source/WebCore/Headers.cmake:
* Source/WebCore/Modules/webauthn/WellKnownOriginList.cpp: Added.
(WebCore::wellKnownURL):
(WebCore::isWellKnownResponseAcceptable):
(WebCore::isWellKnownRedirectAllowed):
(WebCore::findOriginInWellKnownList):
(WebCore::parseOriginsFromWellKnownList):
* Source/WebCore/Modules/webauthn/WellKnownOriginList.h: Added.
* Source/WebCore/Sources.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebKit/Sources.txt:
* Source/WebKit/UIProcess/API/APIUIClient.h:
* Source/WebKit/UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
* Source/WebKit/UIProcess/Cocoa/UIDelegate.h:
* Source/WebKit/UIProcess/Cocoa/UIDelegate.mm:
*
Source/WebKit/UIProcess/WebAuthentication/Cocoa/WebAuthenticatorCoordinatorProxy.mm:
(WebKit::WebAuthenticatorCoordinatorProxy::performRequest):
(WebKit::WebAuthenticatorCoordinatorProxy::performRequestWithValidatedRelyingPartyIdentifier):
* Source/WebKit/UIProcess/WebAuthentication/RelatedOriginsValidator.cpp:
Added.
(WebKit::RelatedOriginsValidation::validate):
* Source/WebKit/UIProcess/WebAuthentication/RelatedOriginsValidator.h:
Added.
*
Source/WebKit/UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp:
(WebKit::WebAuthenticatorCoordinatorProxy::handleRequest):
*
Source/WebKit/UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.h:
* Source/WebKit/UIProcess/WellKnownResourceFetcher.cpp: Added.
(WebKit::WellKnownResourceFetcher::fetch):
* Source/WebKit/UIProcess/WellKnownResourceFetcher.h: Added.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Tools/Scripts/webkitpy/api_tests/allowlist.txt:
* Tools/TestWebKitAPI/CMakeLists.txt:
* Tools/TestWebKitAPI/SourcesCocoa.txt:
* Tools/TestWebKitAPI/Tests/WebCore/WellKnownOriginList.cpp: Added.
*
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WebAuthnRelatedOriginsFetch.mm:
Added.
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
Canonical link: https://commits.webkit.org/319973@main
Canonical link:
https://commits.webkit.org/316606.321@integration/conflict/86e957015e02_86e957015e02_safari-7625.1.29.10-branch
Identifier: [email protected]
(cherry picked from commit 862f17dcae0aace47ea0ec16e209d960abfd553c)
Canonical link: https://commits.webkit.org/[email protected]
Compare: https://github.com/WebKit/WebKit/compare/9552a43369eb%5E...2756e8be5852
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
