Branch: refs/heads/safari-7624.2.5.10-branch
Home: https://github.com/WebKit/WebKit
Commit: 42fe5d110dcb7906e83f5bba97441dd811f97be9
https://github.com/WebKit/WebKit/commit/42fe5d110dcb7906e83f5bba97441dd811f97be9
Author: Mohsin Qureshi <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning. WebKit-7624.2.5.10.1
Canonical link: https://commits.webkit.org/[email protected]
Commit: 2b8e64f52ded4b880c31fae675b50e6ba9958d54
https://github.com/WebKit/WebKit/commit/2b8e64f52ded4b880c31fae675b50e6ba9958d54
Author: Sihui Liu <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
M Source/WebCore/Modules/indexeddb/IDBKeyData.cpp
M Source/WebCore/Modules/indexeddb/IDBKeyData.h
M Tools/TestWebKitAPI/CMakeLists.txt
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebCore/IDBKeyData.cpp
Log Message:
-----------
Cherry-pick 3efb02c6bee1. rdar://174327363
[IndexedDB] IDBKeyData operator== and operator<=> define different
equivalence classes
rdar://174327363
Reviewed by Brady Eidson.
IDBKeyData::operator== and IDBKeyData::operator<=> currently disagree in
two cases:
1. String-typed keys: operator== (via WTF::String::operator==)
distinguishes null String from empty String, but
operator<=> (via codePointCompare) treats them as equivalent.
2. Invalid-typed keys: operator== checks isNull() to distinguish nullptr_t
from Invalid{}, but operator<=> treats all
Invalid-typed keys as equivalent.
This could cause inconsistency in containers of MemoryIDBBackingStore,
specifically HashMap keyed by operator== and
std::set ordered by operator<=>, and defeats cursor-invalidation guards
(which compare with operator== while erases use
operator<). This patch makes sure IDBKeyData::operator<=> match
IDBKeyData::operator== for equality check.
API tests: IDBKeyData.NullAndInvalidAreNotEquivalentInvalidKey
IDBKeyData.NullStringAndEmptyStringAreNotEquivalentStringKey
IDBKeyData.SetDistinguishesNullAndInvalid
IDBKeyData.SetDistinguishesNullStringAndEmptyString
* Source/WebCore/Modules/indexeddb/IDBKeyData.cpp:
(WebCore::operator<=>):
* Source/WebCore/Modules/indexeddb/IDBKeyData.h:
* Tools/TestWebKitAPI/CMakeLists.txt:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebCore/IDBKeyData.cpp: Added.
(TestWebKitAPI::TEST(IDBKeyData, NullAndInvalidAreNotEquivalentInvalidKey)):
(TestWebKitAPI::TEST(IDBKeyData,
NullStringAndEmptyStringAreNotEquivalentStringKey)):
(TestWebKitAPI::TEST(IDBKeyData, SetDistinguishesNullAndInvalid)):
(TestWebKitAPI::TEST(IDBKeyData, SetDistinguishesNullStringAndEmptyString)):
Identifier: 305413.663@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 6d96cdde3ebe76999b342a6f91e15b2b0b5e256a
https://github.com/WebKit/WebKit/commit/6d96cdde3ebe76999b342a6f91e15b2b0b5e256a
Author: Ryosuke Niwa <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
A LayoutTests/fast/text/fontface-setstatus-crash-expected.txt
A LayoutTests/fast/text/fontface-setstatus-crash.html
M Source/WebCore/css/CSSFontFaceSet.cpp
M Source/WebCore/css/CSSFontFaceSet.h
M Source/WebCore/css/FontFaceSet.cpp
Log Message:
-----------
Cherry-pick db05eacaeb0c. rdar://174525579
Use-after-free in CSSFontFace::setStatus and CSSFontFace::pump
https://bugs.webkit.org/show_bug.cgi?id=312202
rdar://174525579
Reviewed by Simon Fraser.
Fixed the bug by using Ref instead of std::reference_wrapper in the return
value of
CSSFontFaceSet::matchingFacesExcludingPreinstalledFonts and local variables
in
FontFaceSet::load to keep CSSFontFace objects alive long enough.
Test: fast/text/fontface-setstatus-crash.html
* LayoutTests/fast/text/fontface-setstatus-crash-expected.txt: Added.
* LayoutTests/fast/text/fontface-setstatus-crash.html: Added.
* Source/WebCore/css/CSSFontFaceSet.cpp:
(WebCore::CSSFontFaceSet::matchingFacesExcludingPreinstalledFonts):
* Source/WebCore/css/CSSFontFaceSet.h:
* Source/WebCore/css/FontFaceSet.cpp:
(WebCore::FontFaceSet::load):
Identifier: 305413.664@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 91cba9d45dbaab93889dda82f5f45c6319324f46
https://github.com/WebKit/WebKit/commit/91cba9d45dbaab93889dda82f5f45c6319324f46
Author: Ryosuke Niwa <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
A
LayoutTests/fast/dom/Range/range-create-contextual-fragment-trsuted-types-crash-expected.txt
A
LayoutTests/fast/dom/Range/range-create-contextual-fragment-trsuted-types-crash.html
M Source/WebCore/dom/Range.cpp
Log Message:
-----------
Cherry-pick 4966a0d102e7. rdar://174489535
Use-after-free of Node in Range::createContextualFragment
https://bugs.webkit.org/show_bug.cgi?id=312244
rdar://174489535
Reviewed by Chris Dumez.
Fixed the bug by deploying more smart pointers.
Test:
fast/dom/Range/range-create-contextual-fragment-trsuted-types-crash.html
*
LayoutTests/fast/dom/Range/range-create-contextual-fragment-trsuted-types-crash-expected.txt:
Added.
*
LayoutTests/fast/dom/Range/range-create-contextual-fragment-trsuted-types-crash.html:
Added.
* Source/WebCore/dom/Range.cpp:
(WebCore::Range::createContextualFragment):
Identifier: 305413.665@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: dcce34064eef64e2e8f80212aebd2580271502d9
https://github.com/WebKit/WebKit/commit/dcce34064eef64e2e8f80212aebd2580271502d9
Author: Shu-yu Guo <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
A JSTests/stress/dataview-bytelength-ic-stub-stack-desync.js
M Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp
Log Message:
-----------
Cherry-pick 68274fa2f297. rdar://174627873
[JSC] Move DataView null vector check in IC outside of register save/restore
https://bugs.webkit.org/show_bug.cgi?id=312218
rdar://174627873
Reviewed by Marcus Plutowski.
In the DataView byteLength getter IC, there is a null vector check which
executes before a preserveReusedRegistersByPushing, but jumps to a point
before
restoreReusedRegistersByPopping. In other words, causing a misbalanced push
and
pop of register state.
This PR fixes by making the null vector check jump to after the popping of
saved registers.
Test: JSTests/stress/dataview-bytelength-ic-stub-stack-desync.js
* JSTests/stress/dataview-bytelength-ic-stub-stack-desync.js: Added.
(hot):
* Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp:
(JSC::InlineCacheCompiler::emitIntrinsicGetter):
Identifier: 305413.668@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: bc4de3de55a4fc0b2d84212b49a0807ba35a1030
https://github.com/WebKit/WebKit/commit/bc4de3de55a4fc0b2d84212b49a0807ba35a1030
Author: Ryosuke Niwa <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
A
LayoutTests/fast/shadow-dom/named-slot-assignment-resolve-after-mutation-crash-expected.txt
A
LayoutTests/fast/shadow-dom/named-slot-assignment-resolve-after-mutation-crash.html
M Source/WebCore/dom/SlotAssignment.cpp
Log Message:
-----------
Cherry-pick cbcbdcfa297d. rdar://174493428
Use-after-free in NamedSlotAssignment::resolveSlotsAfterSlotMutation
https://bugs.webkit.org/show_bug.cgi?id=312247
rdar://174493428
Reviewed by Chris Dumez and Anne van Kesteren.
The bug was caused by hasAssignedNodes updating m_slots as a part of
resolving slot assignments while
we're iterating over m_slots in
NamedSlotAssignment::resolveSlotsAfterSlotMutation. Fixed the bug by
avoiding updating slot assignments upfront and simply checking
slot->assignedNodes.isEmpty() instead.
Test:
fast/shadow-dom/named-slot-assignment-resolve-after-mutation-crash.html
*
LayoutTests/fast/shadow-dom/named-slot-assignment-resolve-after-mutation-crash-expected.txt:
Added.
*
LayoutTests/fast/shadow-dom/named-slot-assignment-resolve-after-mutation-crash.html:
Added.
* Source/WebCore/dom/SlotAssignment.cpp:
(WebCore::NamedSlotAssignment::resolveSlotsAfterSlotMutation):
Identifier: 305413.669@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 5da60bcc4ae3bdc49cc6bfd35bd10fa3cc03419a
https://github.com/WebKit/WebKit/commit/5da60bcc4ae3bdc49cc6bfd35bd10fa3cc03419a
Author: Vassili Bykov <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
A JSTests/wasm/stress/tail-call-v128-ref-stack-overlap.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT.h
M Source/JavaScriptCore/wasm/WasmBBQJIT64.h
Log Message:
-----------
Cherry-pick 73c288dd8c72. rdar://174490087
[JSC] BBQJIT tail call shuffle should detect overlapping stack slots
https://bugs.webkit.org/show_bug.cgi?id=312288
rdar://174490087
Reviewed by Dan Hecht.
Because in a tail call the caller and the callee frames overlap,
BBQJIT::emitTailCall()
uses emitShuffle() to orchestrate the copying of call arguments into their
destination
locations in such a way that if a caller temp resides in the callee
argument space and is
itself passed as an argument, it is not clobbered before it's been moved to
its final
location.
The move hazard detection in emitShuffleMove() compares stack locations by
offset only
(via Location::operator==). The core assumption here is that source and
destination values
with different base addresses never overlap, so a write to a destination
address A never
clobbers a source value at address B.
This assumption does not always hold. Caller temps (source values) are
always 16-byte
aligned regardless of value type. Callee arguments (destination values) are
packed
contiguously. If an i64 argument at address B is followed by a v128
argument, the v128
argument occupies the address range [B+8, B+24). This range overlaps two
temp slots with
ranges [B, B+16) and [B+16, B+32). Because hazard detection currently only
considers the
base address, this overlap will go unnoticed and the shuffle may write the
v128 argument
before the values in the overlapping source slots have been moved.
This patch adds Location::overlaps() method which considers actual ranges
for Stack and
StackArgument locations. The method replaces Location::operator==() for
hazard detection.
The new method is also used in destination uniqueness assertion in
emitShuffle.
Test: JSTests/wasm/stress/tail-call-v128-ref-stack-overlap.js
Identifier: 305413.670@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 074e1c1feb87c5951f49bf07e16fb8e7a6af2876
https://github.com/WebKit/WebKit/commit/074e1c1feb87c5951f49bf07e16fb8e7a6af2876
Author: Ryosuke Niwa <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/UIProcess/WebProcessProxy.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebLocks.mm
Log Message:
-----------
Cherry-pick 4fcd36e3a363. rdar://174679141
REGRESSION(305413.548@safari-7624-branch): Crash in
WebProcessProxy::hasCommittedClientOrigin
https://bugs.webkit.org/show_bug.cgi?id=312335
rdar://174679141
Reviewed by Chris Dumez.
WebProcessProxy::hasCommittedClientOrigin has a code path for processes
running workers (isRunningWorkers())
that dereferences m_site as in *m_site. m_site is a
WTF::Expected<WebCore::Site, SiteState> — when it holds
the error value SiteState::MultipleSites, operator*() accesses the
non-existent value member, throwing
std::bad_variant_access. This propagates uncaught to the Objective-C run
loop boundary, triggering std::terminate().
The three conditions that must hold simultaneously for this crash to occur:
1. isRunningWorkers() is true — a service worker is running inside a web
content process (not a dedicated worker
process), so m_serviceWorkerInformation is set.
2. m_site holds MultipleSites — a cross-site navigation occurred in that
same web content process (no process swap),
so didStartProvisionalLoadForMainFrame set m_site =
makeUnexpected(SiteState::MultipleSites).
3. A RequestLock IPC from the service worker arrives after condition 2 —
the service worker's termination is
deferred (terminateRemoteWorkerContextConnectionWhenPossible instead
of the old disableRemoteWorkers), so
isRunningWorkers() remains true during a window where the worker can
still send IPCs.
Fixed the bug by adding a HashSet<WebCore::Site> m_committedSites to
WebProcessProxy, populated whenever m_site is
assigned a valid Site (in createForRemoteWorkers,
didStartProvisionalLoadForMainFrame, and
didStartUsingProcessForSiteIsolation). In hasCommittedClientOrigin, when
isRunningWorkers() is true but m_site does
not holds a value (it's MultipleSites), the check falls back to
m_committedSites instead of dereferencing m_site
in an error state. This correctly validates the worker's origin against the
sites the process has legitimately
committed — rather than crashing or incorrectly rejecting a legitimate lock
request and killing the web process.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/WebLocks.mm
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::createForRemoteWorkers):
(WebKit::WebProcessProxy::hasCommittedClientOrigin const):
(WebKit::WebProcessProxy::didStartProvisionalLoadForMainFrame):
(WebKit::WebProcessProxy::didStartUsingProcessForSiteIsolation):
* Source/WebKit/UIProcess/WebProcessProxy.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WebLocks.mm:
(TestWebKitAPI::enableWebLocksAPI):
(TestWebKitAPI::runSnapshotAcrossPagesTest):
(TestWebKitAPI::runLockRequestWaitingOnAnotherPage):
(TestWebKitAPI::TEST(WebLocks,
ServiceWorkerLockRequestAfterCrossSiteNavigationInSameProcess)):
Identifier: 305413.672@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 96c7239ec9dd9f7b298d24daa7d3674896f2039e
https://github.com/WebKit/WebKit/commit/96c7239ec9dd9f7b298d24daa7d3674896f2039e
Author: Chris Dumez <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
M Source/WebKit/WebProcess/WebProcess.cpp
Log Message:
-----------
Cherry-pick de77e9322dad. rdar://174830339
Null deref in WebProcess::refreshIDBConnectionForWorkers() during WebPage
construction
https://bugs.webkit.org/show_bug.cgi?id=312364
rdar://174762356
Reviewed by Ryosuke Niwa.
WebProcess::createWebPage() uses HashMap::ensure() to insert and construct
the WebPage in one step. During the WebPage constructor,
WebSocketProvider triggers ensureNetworkProcessConnection(), which may call
refreshIDBConnectionForWorkers(). That function iterates m_pageMap and
dereferences each Ref<WebPage> via operator->(). However, the Ref<WebPage>
for the page being constructed is still in its zeroed hash-table-empty
state (m_ptr == nullptr) because HashMap::ensure()'s translate function
evaluates the functor before assigning the result to the slot. This causes
a null dereference at offset 0x38 (the m_page member within WebPage).
Fix this by deferring refreshIDBConnectionForWorkers() to the next run loop
turn, matching the existing pattern used for
synchronizeCORSDisablingPatternsWithNetworkProcess() a few lines above.
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::ensureNetworkProcessConnection):
Canonical link: https://commits.webkit.org/311278@main
Canonical link: https://commits.webkit.org/[email protected]
Commit: 037f7dd5db7f91fc7554afe1a5166ec1c7becad3
https://github.com/WebKit/WebKit/commit/037f7dd5db7f91fc7554afe1a5166ec1c7becad3
Author: Ryosuke Niwa <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
A
LayoutTests/fast/events/blur-window-with-focus-in-shadow-tree-crash-expected.txt
A LayoutTests/fast/events/blur-window-with-focus-in-shadow-tree-crash.html
M Source/WebCore/page/FocusController.cpp
Log Message:
-----------
Cherry-pick f045966f731c. rdar://174646151
Use-after-free in Element::dispatchBlurEvent
https://bugs.webkit.org/show_bug.cgi?id=312365
rdar://174646151
Reviewed by Rupin Mittal, Chris Dumez, and Anne van Kesteren.
Deployed more smart pointers to fix the bug.
Test: fast/events/blur-window-with-focus-in-shadow-tree-crash.html
*
LayoutTests/fast/events/blur-window-with-focus-in-shadow-tree-crash-expected.txt:
Added.
* LayoutTests/fast/events/blur-window-with-focus-in-shadow-tree-crash.html:
Added.
* Source/WebCore/page/FocusController.cpp:
(WebCore::dispatchEventsOnWindowAndFocusedElement):
Identifier: 305413.673@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 5efffb9130c89fef4ca720812600f5e5e7557a83
https://github.com/WebKit/WebKit/commit/5efffb9130c89fef4ca720812600f5e5e7557a83
Author: Ryosuke Niwa <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
A LayoutTests/streams/readable-stream-fake-promise-crash-expected.txt
A LayoutTests/streams/readable-stream-fake-promise-crash.html
M Source/WebCore/Modules/streams/StreamPipeToUtilities.cpp
Log Message:
-----------
Cherry-pick 86716cafbc99. rdar://174652787
Type confusion in ReadableStream when cancel returns a fake Promise object
https://bugs.webkit.org/show_bug.cgi?id=312357
rdar://174652787
Reviewed by Chris Dumez.
Use jsDynamicCast in place of jsCast to avoid type confusion.
Test: streams/readable-stream-fake-promise-crash.html
* LayoutTests/streams/readable-stream-fake-promise-crash-expected.txt:
Added.
* LayoutTests/streams/readable-stream-fake-promise-crash.html: Added.
* Source/WebCore/Modules/streams/StreamPipeToUtilities.cpp:
(WebCore::cancelReadableStream):
(WebCore::StreamPipeToState::globalObject):
(WebCore::StreamPipeToState::handleSignal):
(WebCore::StreamPipeToState::errorsMustBePropagatedForward):
(WebCore::StreamPipeToState::closingMustBePropagatedBackward):
Identifier: 305413.674@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 12a27ca9b67a4f33054798078eee71bbc3be5337
https://github.com/WebKit/WebKit/commit/12a27ca9b67a4f33054798078eee71bbc3be5337
Author: Yijia Huang <[email protected]>
Date: 2026-04-15 (Wed, 15 Apr 2026)
Changed paths:
A JSTests/wasm/stress/deferred-work-timer-cancel-duplicate-ticket.js
M Source/JavaScriptCore/runtime/DeferredWorkTimer.cpp
Log Message:
-----------
Cherry-pick 09af279a99da. rdar://174738881
[JSC] Remove unneeded m_tasks append in
DeferredWorkTimer::cancelPendingWorkSafe
https://bugs.webkit.org/show_bug.cgi?id=312314
rdar://174738881
Reviewed by Keith Miller.
cancelPendingWorkSafe() was unconditionally appending a (ticket, noop)
entry to
m_tasks for every weak ticket of a dying global. This is unnecessary because
doWork() already has a removeIf(isCancelled) pass at the end that purges
cancelled
tickets from m_pendingTickets without needing a m_tasks entry, and
setTimeUntilFire(0_s) already ensures doWork() fires to run that cleanup.
Test: JSTests/wasm/stress/deferred-work-timer-cancel-duplicate-ticket.js
Identifier: 305413.677@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: d4384a97d1d075ef03aadbe63976e4b14878f13b
https://github.com/WebKit/WebKit/commit/d4384a97d1d075ef03aadbe63976e4b14878f13b
Author: Ryosuke Niwa <[email protected]>
Date: 2026-04-16 (Thu, 16 Apr 2026)
Changed paths:
A LayoutTests/fast/forms/radio-checked-detached-tree-gc-crash-expected.txt
A LayoutTests/fast/forms/radio-checked-detached-tree-gc-crash.html
M Source/WebCore/dom/ContainerNodeAlgorithms.cpp
M Source/WebCore/dom/Node.h
Log Message:
-----------
Cherry-pick 7058101b207d. rdar://174490518
Heap use-after-free in Node::rootNode via stale m_shadowIncludingRoot
https://bugs.webkit.org/show_bug.cgi?id=312426
rdar://174490518
Reviewed by Geoffrey Garen.
The bug was caused by Node::m_shadowIncludingRoot not getting reset in
removeDetachedChildrenInContainer. Fixed the bug by resetting it to this in
the function.
Test: fast/forms/radio-checked-detached-tree-gc-crash.html
* LayoutTests/fast/forms/radio-checked-detached-tree-gc-crash-expected.txt:
Added.
* LayoutTests/fast/forms/radio-checked-detached-tree-gc-crash.html: Added.
* Source/WebCore/dom/ContainerNodeAlgorithms.cpp:
(WebCore::removeDetachedChildrenInContainer):
* Source/WebCore/dom/Node.h:
(WebCore::Node::resetShadowIncludingRoot):
Identifier: 305413.681@safari-7624-branch
Commit: a23ed1a81f08da2042357e4d8d295cfdbb162a51
https://github.com/WebKit/WebKit/commit/a23ed1a81f08da2042357e4d8d295cfdbb162a51
Author: Kimmo Kinnunen <[email protected]>
Date: 2026-04-16 (Thu, 16 Apr 2026)
Changed paths:
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/BufferMtl.h
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/BufferMtl.mm
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ContextMtl.mm
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/VertexArrayMtl.h
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/VertexArrayMtl.mm
M Source/ThirdParty/ANGLE/src/tests/gl_tests/DrawElementsTest.cpp
Log Message:
-----------
Cherry-pick c82b95636797. rdar://173725274
Revert f195c858a918e813e4c67ee52452b4a1c35ec3c7. rdar://173725274
Reviewed by Cameron McCormack.
Revert "WebGL: consecutive UNSIGNED_BYTE drawElements() draw in wrong
location"
This reverts commit f195c858a918e813e4c67ee52452b4a1c35ec3c7.
The reverted commit fixed WebGL vertex array buffer failures where
the oversized buffer modifications caused the failure. Fix the cases
by using the BufferMtl::size() when calculating restart ranges.
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/BufferMtl.h:
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/BufferMtl.mm:
(rx::calculateRestartRanges):
(rx::BufferMtl::getRestartIndices):
(rx::BufferMtl::getRestartIndicesFromClientData):
(rx::CalculateRestartRanges): Deleted.
(rx::BufferMtl::GetRestartIndicesFromClientData): Deleted.
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ContextMtl.mm:
(rx::ContextMtl::drawElementsImpl):
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/VertexArrayMtl.h:
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/VertexArrayMtl.mm:
(rx::VertexArrayMtl::getDrawIndices):
* Source/ThirdParty/ANGLE/src/tests/gl_tests/DrawElementsTest.cpp:
(): Deleted.
Identifier: 305413.687@safari-7624-branch
Commit: 3e841a792c510283b23e9a6782f97f7819f3ce6a
https://github.com/WebKit/WebKit/commit/3e841a792c510283b23e9a6782f97f7819f3ce6a
Author: Mohsin Qureshi <[email protected]>
Date: 2026-04-17 (Fri, 17 Apr 2026)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning. WebKit-7624.2.5.10.2
Canonical link: https://commits.webkit.org/[email protected]
Commit: a377826694cc4609d220cda355b47b5a73121039
https://github.com/WebKit/WebKit/commit/a377826694cc4609d220cda355b47b5a73121039
Author: Mohsin Qureshi <[email protected]>
Date: 2026-04-17 (Fri, 17 Apr 2026)
Changed paths:
M
LayoutTests/fast/mediastream/RTCPeerConnection-setRemoteDescription-offer.html
M
LayoutTests/imported/w3c/web-platform-tests/webrtc/RTCPeerConnection-remote-track-properties.https-expected.txt
M
LayoutTests/platform/glib/fast/mediastream/RTCPeerConnection-setRemoteDescription-offer-expected.txt
M LayoutTests/webrtc/getDisplayMedia-pc.html
M LayoutTests/webrtc/utf8-sdp.html
M LayoutTests/webrtc/video-addTrack.html
M LayoutTests/webrtc/video-interruption.html
M LayoutTests/webrtc/video.html
M
Source/WebCore/Modules/mediastream/gstreamer/GStreamerPeerConnectionBackend.cpp
M
Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCPeerConnectionBackend.cpp
Log Message:
-----------
Revert 9e4178b110f6. rdar://175017545
Canonical link: https://commits.webkit.org/[email protected]
Commit: 81b1e18daaa50481c287358f0c87e0f18cb0bab8
https://github.com/WebKit/WebKit/commit/81b1e18daaa50481c287358f0c87e0f18cb0bab8
Author: Mohsin Qureshi <[email protected]>
Date: 2026-04-20 (Mon, 20 Apr 2026)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning. WebKit-7624.2.5.10.3
Canonical link: https://commits.webkit.org/[email protected]
Commit: bcf45e274e808701be1ee97072a7a402ffe56d48
https://github.com/WebKit/WebKit/commit/bcf45e274e808701be1ee97072a7a402ffe56d48
Author: Ryosuke Niwa <[email protected]>
Date: 2026-04-21 (Tue, 21 Apr 2026)
Changed paths:
M Source/WebCore/dom/ContainerNodeAlgorithms.cpp
M Source/WebCore/dom/Node.cpp
M Source/WebCore/dom/Node.h
Log Message:
-----------
Cherry-pick 5d07bda85f02. rdar://175103172
REGRESSION: Use-after-free in Node::m_shadowIncludingRoot via destructor
cascade not propagating into shadow roots
https://bugs.webkit.org/show_bug.cgi?id=312712
rdar://175103172
Reviewed by Geoffrey Garen.
When a document is torn down via Document::removedLastRef through
removeDetachedChildrenInContainer,
the <html> element is removed from the document. Since <html> is still in
tree scope at this point,
notifyChildNodeRemoved is called, which walks the entire subtree -
including shadow roots - and sets
m_shadowIncludingRoot to <html> for all descendants. This is correct at
that moment.
Then <html> is freed when the loop's RefPtr releases it (children don't
ref-count their parents -
m_parentNode is CheckedPtr). This triggers a destructor cascade:
~ContainerNode(<html>) via
removeDetachedChildrenInContainer(<html>) processes <body>, then
~ContainerNode(<body>) processes
the <video> element, and so on. Each step calls resetShadowIncludingRoot()
on the direct child,
fixing that node's cache. However, since IsConnected and IsInShadowTree
flags were cleared during
the initial notifyChildNodeRemoved walk, isInTreeScope() returns false, so
notifyChildNodeRemoved
is skipped in this case. This means the shadow root and its descendants are
never updated -
m_shadowIncludingRoot of these nodes still point to the now-freed <html>.
Nodes kept alive by mechanisms other than JS wrappers - such as
HTMLMediaElement which survives as
an ActiveDOMObject - retain their shadow DOM with dangling
m_shadowIncludingRoot pointers. When
these nodes are subsequently used (e.g., VTT cue display tree updates via
an event loop task), the
stale pointer is dereferenced, causing an use-after-free.
This PR fixes this use-after-free bug by updating m_shadowIncludingRoot for
removed subtrees when
the root's refCount is greater than 1 (i.e. there is an external reference
to the node beyond the
RefPtr in removeDetachedChildrenInContainer).
No new tests since existing media tests such as
media/track/webvtt-parser-does-not-leak.html would
hit debug assertions without this fix, and this bug requires a node to be
kept alive by C++ code.
* Source/WebCore/dom/ContainerNodeAlgorithms.cpp:
(WebCore::removeDetachedChildrenInContainer):
* Source/WebCore/dom/Node.cpp:
(WebCore::Node::updateShadowIncludingRootForSubtree):
* Source/WebCore/dom/Node.h:
Identifier: 305413.700@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: affab3756bed6b58a9b563da2b167ce151d68e50
https://github.com/WebKit/WebKit/commit/affab3756bed6b58a9b563da2b167ce151d68e50
Author: Russell Epstein <[email protected]>
Date: 2026-04-22 (Wed, 22 Apr 2026)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7624.2.5.10.4
Canonical link: https://commits.webkit.org/[email protected]
Commit: eafd2a9b97765b0d8a84e74f3ec5096bcd335723
https://github.com/WebKit/WebKit/commit/eafd2a9b97765b0d8a84e74f3ec5096bcd335723
Author: Ryosuke Niwa <[email protected]>
Date: 2026-04-22 (Wed, 22 Apr 2026)
Changed paths:
A LayoutTests/streams/pipeTo-removed-iframe-crash-expected.txt
A LayoutTests/streams/pipeTo-removed-iframe-crash.html
M Source/WebCore/Modules/streams/StreamPipeToUtilities.cpp
M Source/WebCore/bindings/js/InternalReadableStreamDefaultReader.cpp
M Source/WebCore/bindings/js/InternalWritableStreamWriter.cpp
Log Message:
-----------
Cherry-pick 90e48031ed4d. rdar://175084445
REGRESSION(305413.674@safari-7624-branch): Crash in
StreamPipeToState::globalObject
https://bugs.webkit.org/show_bug.cgi?id=312938
rdar://175084445
Reviewed by Chris Dumez.
The crash was caused by StreamPipeToState::globalObject calling
jsDynamicCast<JSDOMGlobalObject*>
on context->globalObject() without a nullptr check. Fixed the crash by
adding a nullptr check.
The newly written test revealed a related bug that we were calling
DOMPromise::status even when
active DOM objects had been stopped. Added a bunch of early returns to
functions in
InternalReadableStreamDefaultReader and InternalWritableStreamWriter to
avoid debug assertions
in these cases, one of which is hit by the new test.
Test: streams/pipeTo-removed-iframe-crash.html
* LayoutTests/streams/pipeTo-removed-iframe-crash-expected.txt: Added.
* LayoutTests/streams/pipeTo-removed-iframe-crash.html: Added.
* Source/WebCore/Modules/streams/StreamPipeToUtilities.cpp:
(WebCore::StreamPipeToState::globalObject):
* Source/WebCore/bindings/js/InternalReadableStreamDefaultReader.cpp:
(WebCore::InternalReadableStreamDefaultReader::onClosedPromiseRejection):
(WebCore::InternalReadableStreamDefaultReader::onClosedPromiseResolution):
* Source/WebCore/bindings/js/InternalWritableStreamWriter.cpp:
(WebCore::InternalWritableStreamWriter::onClosedPromiseRejection):
(WebCore::InternalWritableStreamWriter::onClosedPromiseResolution):
(WebCore::InternalWritableStreamWriter::whenReady):
Identifier: 305413.711@safari-7624-branch
Canonical link: https://commits.webkit.org/[email protected]
Compare: https://github.com/WebKit/WebKit/compare/42fe5d110dcb%5E...eafd2a9b9776
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
