Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 645f2545c306af1c004bada76604c67f92842867
https://github.com/WebKit/WebKit/commit/645f2545c306af1c004bada76604c67f92842867
Author: Shu-yu Guo <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/direct-eval-cache-rope.js
M Source/JavaScriptCore/interpreter/Interpreter.cpp
Log Message:
-----------
Cherry-pick 305413.520@safari-7624-branch (f84884541bfb).
https://bugs.webkit.org/show_bug.cgi?id=310146
[JSC] Defer GC while using the direct eval CacheLookupKey
https://bugs.webkit.org/show_bug.cgi?id=310146
rdar://172708456
Reviewed by Yusuke Suzuki.
DirectEvalCodeCache::CacheLookupKey holds a raw StringImpl* for performance.
This StringImpl* can be the contents of a fiber of an on-stack rope
JSString.
Though that JSString is live on the stack, it can be mutated in place due to
rope flattening, which means its fiber JSString, whose contents are
referenced
in the key, can become unrooted and swept by the GC and consequently deref
the
String whose raw pointer is in the key. This PR fixes by deferring GC during
while the lookup key is live on the stack.
Test: JSTests/stress/direct-eval-cache-rope.js
* JSTests/stress/direct-eval-cache-rope.js: Added.
(getRope):
(main):
* Source/JavaScriptCore/interpreter/Interpreter.cpp:
(JSC::eval):
Identifier: 305413.520@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.547@webkitglib/2.52
Commit: be2676f7e19ea989dc8dbd30304568b71c1319dc
https://github.com/WebKit/WebKit/commit/be2676f7e19ea989dc8dbd30304568b71c1319dc
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A
LayoutTests/performance-api/event-timing-target-retarget-shadow-dom-expected.txt
A LayoutTests/performance-api/event-timing-target-retarget-shadow-dom.html
M Source/WebCore/page/LocalDOMWindow.cpp
Log Message:
-----------
Cherry-pick 305413.521@safari-7624-branch (b6884036db8c).
https://bugs.webkit.org/show_bug.cgi?id=309910
PerformanceEventTiming.target returns un-retargeted node for pointer events
without a DOM listener
https://bugs.webkit.org/show_bug.cgi?id=309910
rdar://172516264
Reviewed by Wenson Hsieh.
This PR fixes a bug that PerformanceEventTiming would expose a node in a UA
shadow trees.
Test: performance-api/event-timing-target-retarget-shadow-dom.html
*
LayoutTests/performance-api/event-timing-target-retarget-shadow-dom-expected.txt:
Added.
* LayoutTests/performance-api/event-timing-target-retarget-shadow-dom.html:
Added.
* Source/WebCore/page/LocalDOMWindow.cpp:
(WebCore::LocalDOMWindow::finalizeEventTimingEntry):
Identifier: 305413.521@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.548@webkitglib/2.52
Commit: de89b43dc382968e24a9a6387b69c91775ae77fb
https://github.com/WebKit/WebKit/commit/de89b43dc382968e24a9a6387b69c91775ae77fb
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/WebCore/dom/ContainerNodeInlines.h
M Source/WebCore/dom/Element.cpp
M Source/WebCore/dom/Node.cpp
M Source/WebCore/dom/Node.h
M Source/WebCore/dom/NodeInlines.h
M Source/WebCore/dom/ShadowRoot.cpp
M Source/WebCore/dom/ShadowRoot.h
Log Message:
-----------
Cherry-pick 305413.522@safari-7624-branch (76bd64baa59e).
https://bugs.webkit.org/show_bug.cgi?id=310029
Race condition in Node::traverseToOpaqueRoot
https://bugs.webkit.org/show_bug.cgi?id=310029
<rdar://172327427>
Reviewed by Anne van Kesteren.
Store the opaque root in Node instead of computing it during a marking
phase of GC
to avoid the race condition. Also optimize a few DOM functions.
No new tests since there should be no observable behavior differences other
than
the fix to the race condition and the race condition is hard to test
reliably.
* Source/WebCore/dom/ContainerNodeInlines.h:
(WebCore::ContainerNode::rootNode const):
* Source/WebCore/dom/Element.cpp:
(WebCore::ShadowRoot::setHost):
(WebCore::Element::addShadowRoot):
* Source/WebCore/dom/Node.cpp:
(WebCore::Node::Node):
(WebCore::Node::isDescendantOf const): Added an optimization to avoid tree
traversal if the root node of two trees differ.
(WebCore::Node::isShadowIncludingDescendantOf const): Ditto.
(WebCore::Node::isComposedTreeDescendantOf const): Ditto.
(WebCore::traverseToShadowIncludingRoot):
(WebCore::Node::updateShadowIncludingRoot):
(WebCore::Node::insertedIntoAncestor):
(WebCore::Node::removedFromAncestor):
(WebCore::Node::shadowIncludingRoot const): Deleted.
(WebCore::Node::traverseToOpaqueRoot const): Deleted.
* Source/WebCore/dom/Node.h:
(WebCore::Node::shadowIncludingRoot const):
* Source/WebCore/dom/NodeInlines.h:
(WebCore::Node::opaqueRoot const):
(WebCore::Node::rootNode const):
* Source/WebCore/dom/ShadowRoot.cpp:
(WebCore::ShadowRoot::ShadowRoot):
* Source/WebCore/dom/ShadowRoot.h:
Identifier: 305413.522@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.549@webkitglib/2.52
Commit: 52ffea76b712c0ac378b69dc4c83fab8cbf94e43
https://github.com/WebKit/WebKit/commit/52ffea76b712c0ac378b69dc4c83fab8cbf94e43
Author: Brady Eidson <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Tools/TestWebKitAPI/SourcesCocoa.txt
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WebKitCocoa/MessagePortSecurity.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/PasteHTML.mm
Log Message:
-----------
Cherry-pick 305413.547@safari-7624-branch (a9b7107ffbd9).
https://bugs.webkit.org/show_bug.cgi?id=310029
Compromised web content process unauthorized access to pending MessagePort
messages
rdar://172706670
Reviewed by Chris Dumez.
Specially crafted IPC from a web content process can ask for pending
MessagePort messages
that don't belong to it by either guessing or otherwise establishing the
internal
identifier for the given MessagePort.
This patch adds a MESSAGE_CHECK that always returns empty results on such
an attempt.
Tests: Tools/TestWebKitAPI/Tests/WebKitCocoa/MessagePortSecurity.mm
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::takeAllMessagesForPort):
* Tools/TestWebKitAPI/SourcesCocoa.txt:
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/MessagePortSecurity.mm: Added.
(enableIPCTestingAPI):
(addEventListener):
(function):
((MessagePortSecurity, CrossProcessMessageTheftViaTakeAllMessagesForPort)):
Identifier: 305413.547@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.550@webkitglib/2.52
Commit: 784f7fde71f3c755341dc213cc45f6f1abb563e9
https://github.com/WebKit/WebKit/commit/784f7fde71f3c755341dc213cc45f6f1abb563e9
Author: Chris Dumez <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A
LayoutTests/fast/speechsynthesis/speech-synthesis-cancel-on-navigation-expected.txt
A
LayoutTests/fast/speechsynthesis/speech-synthesis-cancel-on-navigation.html
M Source/WebCore/Modules/speech/SpeechSynthesis.cpp
M Source/WebCore/Modules/speech/SpeechSynthesis.h
M Source/WebCore/Modules/speech/SpeechSynthesisUtterance.cpp
Log Message:
-----------
Cherry-pick 305413.549@safari-7624-branch (26fa1088eb27).
https://bugs.webkit.org/show_bug.cgi?id=310260
Audio from SpeechSynthesis may leak to the next page on cross-origin
navigation
https://bugs.webkit.org/show_bug.cgi?id=310260
rdar://171777671
Reviewed by Brady Eidson.
Audio from SpeechSynthesis may leak to the next page on cross-origin
navigation. Address the issue by calling SpeechSynthesis::cancel()
when the script execution context is going away or getting suspended for
back/forward cache.
*
LayoutTests/fast/speechsynthesis/speech-synthesis-cancel-on-navigation-expected.txt:
Added.
*
LayoutTests/fast/speechsynthesis/speech-synthesis-cancel-on-navigation.html:
Added.
* Source/WebCore/Modules/speech/SpeechSynthesis.cpp:
(WebCore::SpeechSynthesis::suspend):
(WebCore::SpeechSynthesis::stop):
* Source/WebCore/Modules/speech/SpeechSynthesis.h:
* Source/WebCore/Modules/speech/SpeechSynthesisUtterance.cpp:
(WebCore::SpeechSynthesisUtterance::eventOccurred):
(WebCore::SpeechSynthesisUtterance::errorEventOccurred):
Identifier: 305413.549@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.551@webkitglib/2.52
Commit: 659a025c2fc3eae637a6938ac69a1efcd04dc746
https://github.com/WebKit/WebKit/commit/659a025c2fc3eae637a6938ac69a1efcd04dc746
Author: Kimmo Kinnunen <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A LayoutTests/webgl/webgl-timerquery-querycounter-gc-nocrash-expected.txt
A LayoutTests/webgl/webgl-timerquery-querycounter-gc-nocrash.html
M Source/WebCore/SaferCPPExpectations/UncheckedCallArgsCheckerExpectations
M Source/WebCore/SaferCPPExpectations/UncountedCallArgsCheckerExpectations
M Source/WebCore/html/canvas/EXTDisjointTimerQuery.cpp
M Source/WebCore/html/canvas/WebGL2RenderingContext.cpp
M Source/WebCore/html/canvas/WebGLObject.h
Log Message:
-----------
Cherry-pick 305413.551@safari-7624-branch (479526084676).
https://bugs.webkit.org/show_bug.cgi?id=310345
WebGL: Crash in EXTDisjointTimerQuery::queryCounterEXT task
https://bugs.webkit.org/show_bug.cgi?id=310345
rdar://172499466
Reviewed by Dan Glastonbury.
Take a ref of the query in the task EXTDisjointTimerQuery schedules
for making the query result available.
EXTDisjointTimerQueryWebGL2 was fixed in bug 303348.
Test: webgl/webgl-timerquery-querycounter-gc-nocrash.html
* LayoutTests/webgl/webgl-timerquery-querycounter-gc-nocrash-expected.txt:
Added.
* LayoutTests/webgl/webgl-timerquery-querycounter-gc-nocrash.html: Added.
* Source/WebCore/SaferCPPExpectations/UncheckedCallArgsCheckerExpectations:
* Source/WebCore/SaferCPPExpectations/UncountedCallArgsCheckerExpectations:
* Source/WebCore/html/canvas/EXTDisjointTimerQuery.cpp:
(WebCore::EXTDisjointTimerQuery::endQueryEXT):
(WebCore::EXTDisjointTimerQuery::queryCounterEXT):
* Source/WebCore/html/canvas/WebGL2RenderingContext.cpp:
(WebCore::WebGL2RenderingContext::endQuery):
* Source/WebCore/html/canvas/WebGLObject.h:
(WebCore::WebGLBindingPoint::releaseNonNull):
Identifier: 305413.551@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.552@webkitglib/2.52
Commit: 6bfdb5ac59045e27cc3bbcfcac96d866ade31751
https://github.com/WebKit/WebKit/commit/6bfdb5ac59045e27cc3bbcfcac96d866ade31751
Author: Kimmo Kinnunen <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M
LayoutTests/fast/canvas/webgl/draw-elements-out-of-bounds-uint-index-expected.txt
M LayoutTests/fast/canvas/webgl/draw-elements-out-of-bounds-uint-index.html
M Source/ThirdParty/ANGLE/src/libANGLE/validationES.h
M Source/ThirdParty/ANGLE/src/tests/gl_tests/WebGLCompatibilityTest.cpp
Log Message:
-----------
Cherry-pick 305413.413@safari-7624-branch (a3d82cd35967).
https://bugs.webkit.org/show_bug.cgi?id=309120
WebGL: UNSIGNED_INT drawElements() does not validate large indexes correctly
https://bugs.webkit.org/show_bug.cgi?id=309120
rdar://171292767
Reviewed by Dan Glastonbury.
Fix by removing the explicit static cast. The range type is uint32 and
can be converted to GLint64 implicitly and correctly. If the type is
changed to incompatible type (size_t), the implicit cast will warn.
* Source/ThirdParty/ANGLE/src/libANGLE/validationES.h:
(gl::ValidateDrawElementsCommon):
* Source/ThirdParty/ANGLE/src/tests/gl_tests/WebGLCompatibilityTest.cpp:
Identifier: 305413.413@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.553@webkitglib/2.52
Commit: 5757cbd7ad5386ba70226aa823055d06b1fa10a1
https://github.com/WebKit/WebKit/commit/5757cbd7ad5386ba70226aa823055d06b1fa10a1
Author: Kai Tamkun <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/JavaScriptCore/runtime/ClonedArguments.cpp
Log Message:
-----------
Cherry-pick 305413.436@safari-7624-branch (14747bdb368d).
https://bugs.webkit.org/show_bug.cgi?id=309185
[JSC] Incorrect loop condition in ClonedArguments::copyToArguments with
non-zero offset
https://bugs.webkit.org/show_bug.cgi?id=309185
rdar://171157543
Reviewed by Yusuke Suzuki.
This patch fixes an incorrect loop condition in
ClonedArguments::copyToArguments.
No tests are added because it appears there is no possible path to call
ClonedArguments::copyToArguments with a nonzero offset. None of the tests
under
JSTests call copyToArguments with a nonzero offset at any point and various
attempts to create a PoC that does so through op_call_varargs proved
unsuccessful.
* Source/JavaScriptCore/runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::copyToArguments):
Identifier: 305413.436@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.554@webkitglib/2.52
Commit: 0db2b6584d1b78050c359867b71cb5bebc957344
https://github.com/WebKit/WebKit/commit/0db2b6584d1b78050c359867b71cb5bebc957344
Author: Vassili Bykov <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/wasm/regress/309628.js
M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp
Log Message:
-----------
Cherry-pick 305413.442@safari-7624-branch (b5a9b035e465).
https://bugs.webkit.org/show_bug.cgi?id=309628
WebAssembly IPInt Stack Check Undercount
https://bugs.webkit.org/show_bug.cgi?id=309628
rdar://172141532
Reviewed by Yusuke Suzuki.
When IPIntGenerator::finalize() computes m_maxFrameSizeInV128, it divides
both m_numLocals
and m_numAlignedRethrowSlots by 2. This calculation would be correct if
locals and rethrow
slots were 64 bits wide. However, all slots in IPInt are 128 bits wide, as
expressed by
the constant LocalSize in InPlaceInterpreter.asm. Thus they already are in
units of V128.
The division by 2 leads to IPInt frames being sized incorrectly.
The patch removes the division by 2.
A related issue I'm leaving unaddressed in this patch is that in a number
of places
IPIntGenerator rounds up locals and rethrow slot counts to a multiple of 2.
This feature
together with the division by 2 seems to be an artifact of an earlier
implementation with
64-bit locals. Rounding up to a multiple of 2 would properly align such
locals on the
stack at the 16 byte boundary. None of that is necessary now with 128-bit
locals.
I'm leaving this other feature unaddressed to keep this security patch
focused. The
unnecessary rounding up is harmless, but removing it perturbs more logic,
and we can do it
at a later time as a polish.
Test: JSTests/wasm/regress/309628.js (I'm intentionally keeping the name
non-descriptive
to not call out the repercussions)
* JSTests/wasm/regress/309628.js: Added.
* Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp:
(JSC::Wasm::IPIntGenerator::finalize):
Identifier: 305413.442@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.555@webkitglib/2.52
Commit: 8dec1abcbadf18aec7e07168dc374325668840c7
https://github.com/WebKit/WebKit/commit/8dec1abcbadf18aec7e07168dc374325668840c7
Author: Antti Koivisto <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/WebCore/inspector/agents/InspectorCSSAgent.cpp
Log Message:
-----------
Cherry-pick 305413.602@safari-7624-branch (5233199dcb0c).
https://bugs.webkit.org/show_bug.cgi?id=310880
Style resolver crash with Inspector attach
https://bugs.webkit.org/show_bug.cgi?id=310880
rdar://171826901
Reviewed by Alan Baradlay.
No test, this requires real Inspector attached.
* Source/WebCore/inspector/agents/InspectorCSSAgent.cpp:
(WebCore::InspectorCSSAgent::getMatchedStylesForNode):
Ref the style resolver and also re-fetch it before use.
Identifier: 305413.602@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.556@webkitglib/2.52
Commit: 0c2827ebfdbcee2f5b1ad7b5f14305efd9a936ff
https://github.com/WebKit/WebKit/commit/0c2827ebfdbcee2f5b1ad7b5f14305efd9a936ff
Author: Youenn Fablet <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/webrtc/p2p/base/packet_transport_internal.cc
M
Source/ThirdParty/libwebrtc/Source/webrtc/p2p/base/packet_transport_internal.h
M Source/ThirdParty/libwebrtc/Source/webrtc/p2p/dtls/dtls_transport.cc
Log Message:
-----------
Cherry-pick 305413.603@safari-7624-branch (5112c9dc3525).
https://bugs.webkit.org/show_bug.cgi?id=310880
[WebRTC] Heap-use-after-free in `DtlsTransportInternalImpl` when RTCP-mux
is negotiated after initial non-mux session
rdar://173510839
Reviewed by Jer Noble.
DTLSTransport is not unregistering itself from receive/send callbacks,
which can trigger a a UAF.
We fix this by adding API to register/unregister a specific listener, and
use that API in DtlsTransportInternalImpl destructor and in
DtlsTransportInternalImpl::ConnectToIceTransport
We manually validated the fix using a specific STUN server.
We should upgrade our testing infra to support running the test with the
STUN server.
Identifier: 305413.603@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.557@webkitglib/2.52
Commit: b47d5961b0345a7184e4f9d3ee5c253ceb3c5232
https://github.com/WebKit/WebKit/commit/b47d5961b0345a7184e4f9d3ee5c253ceb3c5232
Author: Dan Hecht <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/bmalloc/libpas/src/libpas/pas_enumerator.c
M Source/bmalloc/libpas/src/test/EnumerationTests.cpp
Log Message:
-----------
Cherry-pick 305413.604@safari-7624-branch (0c474e5f1172).
https://bugs.webkit.org/show_bug.cgi?id=311232
[libpas] pas_enumerator_create should check validity of compact heap bump
https://bugs.webkit.org/show_bug.cgi?id=311232
rdar://173763464
Reviewed by Marcus Plutowski.
In case the pas root is corrupted, let's be defensive and check
the consistency of the compact heap parameters.
Added test case to EnumerationTests.cpp to verify this path.
* Source/bmalloc/libpas/src/libpas/pas_enumerator.c:
(pas_enumerator_create):
* Source/bmalloc/libpas/src/test/EnumerationTests.cpp:
(std::testEnumerationInvalidCompactHeapBump):
(addEnumerationTests):
Identifier: 305413.604@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.558@webkitglib/2.52
Commit: ef5778f33e3b897774f4aa103881cdf283695bbe
https://github.com/WebKit/WebKit/commit/ef5778f33e3b897774f4aa103881cdf283695bbe
Author: Charlie Wolfe <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/WebCore/loader/FrameLoader.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKHTTPCookieStore.mm
Log Message:
-----------
Cherry-pick 305413.605@safari-7624-branch (52a76d6c003e).
https://bugs.webkit.org/show_bug.cgi?id=311228
Initiator-omitted samesite classification can lead to SameSite=Strict
cookie cross-site leakage
https://bugs.webkit.org/show_bug.cgi?id=311228
rdar://171546575
Reviewed by Brent Fulgham.
FrameLoader::load called addSameSiteInfoToRequestIfNeeded without an
initiator document,
unconditionally forcing isSameSite=true on requests. This prevented the
later initiator-aware
recomputation in updateRequestAndAddExtraFields from running (gated on
isSameSiteUnspecified),
causing cross-site navigations to include SameSite=Strict cookies.
Pass the FrameLoadRequest's requester document as the initiator so the
SameSite disposition is
computed correctly. When the requester is an initial document
(about:blank/empty), pass nullptr to
preserve the same-site default for fresh navigations.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/WKHTTPCookieStore.mm
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::load):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKHTTPCookieStore.mm:
(TEST(WKHTTPCookieStore, SameSiteStrictCookieNotSentOnCrossSiteNavigation)):
Identifier: 305413.605@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.559@webkitglib/2.52
Commit: 208b9c5aa452be9fdbeb5fe15e94d39210b484e8
https://github.com/WebKit/WebKit/commit/208b9c5aa452be9fdbeb5fe15e94d39210b484e8
Author: Youenn Fablet <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M LayoutTests/http/wpt/webrtc/audio-video-transform.js
M LayoutTests/http/wpt/webrtc/audiovideo-script-transform-expected.txt
M LayoutTests/http/wpt/webrtc/audiovideo-script-transform.html
M Source/WebCore/Modules/mediastream/RTCEncodedStreamProducer.cpp
M Source/WebCore/Modules/mediastream/RTCEncodedStreamProducer.h
M Source/WebCore/Modules/mediastream/RTCRtpScriptTransformer.cpp
M Source/WebCore/Modules/mediastream/RTCRtpTransformableFrame.h
Log Message:
-----------
Cherry-pick 305413.606@safari-7624-branch (8d45e135c17e).
https://bugs.webkit.org/show_bug.cgi?id=311131
Type Confusion in RTCEncodedStreamProducer.cpp Results in OOB Read
https://bugs.webkit.org/show_bug.cgi?id=311131
rdar://173718825
Reviewed by Eric Carlson.
We add a check in RTCEncodedStreamProducer::writeFrame that we can only
enqueue a video frame on a video sender/receiver,
and audio frame on an audio sender/receiver.
We should also allow write frames in a WritableStream that are generated
from the corresponding ReadableStream.
We add the check in RTCEncodedStreamProducer::writeFrame for
RTCRtpScriptTransformer and
Covered by updated test.
* LayoutTests/http/wpt/webrtc/audio-video-transform.js:
(AudioVideoRTCRtpTransformer):
(AudioVideoRTCRtpTransformer.prototype.process):
(onrtctransform): Deleted.
* LayoutTests/http/wpt/webrtc/audiovideo-script-transform-expected.txt:
* LayoutTests/http/wpt/webrtc/audiovideo-script-transform.html:
* Source/WebCore/Modules/mediastream/RTCEncodedStreamProducer.cpp:
(WebCore::RTCEncodedStreamProducer::start):
(WebCore::RTCEncodedStreamProducer::enqueueFrame):
(WebCore::RTCEncodedStreamProducer::writeFrame):
* Source/WebCore/Modules/mediastream/RTCEncodedStreamProducer.h:
* Source/WebCore/Modules/mediastream/RTCRtpScriptTransformer.cpp:
(WebCore::RTCRtpScriptTransformer::start):
* Source/WebCore/Modules/mediastream/RTCRtpTransformableFrame.h:
(WebCore::RTCRtpTransformableFrame::isFromTransformer const):
(WebCore::RTCRtpTransformableFrame::setTransformer):
Identifier: 305413.606@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.560@webkitglib/2.52
Commit: 3a59fb123ba5f7c9ae8e10c7f0c950525e9d1c5d
https://github.com/WebKit/WebKit/commit/3a59fb123ba5f7c9ae8e10c7f0c950525e9d1c5d
Author: Zak Ridouh <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A
LayoutTests/fast/scrolling/scroll-update-during-grid-layout-crash-expected.txt
A LayoutTests/fast/scrolling/scroll-update-during-grid-layout-crash.html
M Source/WebCore/rendering/RenderLayerScrollableArea.cpp
Log Message:
-----------
Cherry-pick 305413.639@safari-7624-branch (b6e4815bf940).
https://bugs.webkit.org/show_bug.cgi?id=309595
[grid layout] Don't call viewportContentsChanged() from scroll updates
during render tree layout
<https://bugs.webkit.org/show_bug.cgi?id=309595>
<rdar://170531390>
Reviewed by Simon Fraser.
RenderLayerScrollableArea::scrollTo() calls
LocalFrameView::viewportContentsChanged() which computes visibility
rects by querying renderer geometry via applyRecursivelyWithVisibleRect.
When scrollTo() is invoked during render tree layout (e.g. via
updateScrollInfoAfterLayout during grid pre-layout), containing blocks
may not have completed layout yet. This causes an assertion failure in
gridAreaRangeForOutOfFlow when trying to resolve percentage padding on
an absolutely positioned iframe against a grid area that hasn't been
populated yet.
Guard the viewportContentsChanged() call with isInRenderTreeLayout().
This is safe because performPostLayoutTasks() already calls
viewportContentsChanged() unconditionally after every layout completes.
*
LayoutTests/fast/scrolling/scroll-update-during-grid-layout-crash-expected.txt:
Added.
* LayoutTests/fast/scrolling/scroll-update-during-grid-layout-crash.html:
Added.
* Source/WebCore/rendering/RenderLayerScrollableArea.cpp:
(WebCore::RenderLayerScrollableArea::scrollTo):
Identifier: 305413.639@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.561@webkitglib/2.52
Commit: 43be4c8a6a8c521359eb08dd01f47ee1b2dbc4ac
https://github.com/WebKit/WebKit/commit/43be4c8a6a8c521359eb08dd01f47ee1b2dbc4ac
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A LayoutTests/fast/html/dialog-close-from-button-crash-expected.txt
A LayoutTests/fast/html/dialog-close-from-button-crash.html
M Source/WebCore/html/HTMLDialogElement.cpp
Log Message:
-----------
Cherry-pick 305413.656@safari-7624-branch (d986891db87d).
https://bugs.webkit.org/show_bug.cgi?id=312180
Use-after-free in HTMLDialogElement::close
https://bugs.webkit.org/show_bug.cgi?id=312180
rdar://174525336
Reviewed by Geoffrey Garen.
Fix the bug in HTMLDialogElement::handleCommandInternal by storing the
String value
of the invoker in a local variable.
Test: fast/html/dialog-close-from-button-crash.html
* LayoutTests/fast/html/dialog-close-from-button-crash-expected.txt: Added.
* LayoutTests/fast/html/dialog-close-from-button-crash.html: Added.
* Source/WebCore/html/HTMLDialogElement.cpp:
(WebCore::HTMLDialogElement::handleCommandInternal):
Identifier: 305413.656@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.562@webkitglib/2.52
Commit: 1286782cd06330fc28edaec5fa3f56bc7446b9a3
https://github.com/WebKit/WebKit/commit/1286782cd06330fc28edaec5fa3f56bc7446b9a3
Author: Sihui Liu <[email protected]>
Date: 2026-05-19 (Tue, 19 May 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. https://bugs.webkit.org/show_bug.cgi?id=312180
[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]
Canonical link: https://commits.webkit.org/305877.563@webkitglib/2.52
Commit: bd80f4977dcc8e2b30ad0fe6a51423aa0910ba9c
https://github.com/WebKit/WebKit/commit/bd80f4977dcc8e2b30ad0fe6a51423aa0910ba9c
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-19 (Tue, 19 May 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. https://bugs.webkit.org/show_bug.cgi?id=312202
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]
Canonical link: https://commits.webkit.org/305877.564@webkitglib/2.52
Commit: 440d41e7e842dc8ffe3e98080a975265d7bea0fe
https://github.com/WebKit/WebKit/commit/440d41e7e842dc8ffe3e98080a975265d7bea0fe
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-19 (Tue, 19 May 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. https://bugs.webkit.org/show_bug.cgi?id=312244
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]
Canonical link: https://commits.webkit.org/305877.565@webkitglib/2.52
Commit: 564f45355a028d7f38e280c8ff988fb90be5a2b6
https://github.com/WebKit/WebKit/commit/564f45355a028d7f38e280c8ff988fb90be5a2b6
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-19 (Tue, 19 May 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. https://bugs.webkit.org/show_bug.cgi?id=312247
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]
Canonical link: https://commits.webkit.org/305877.566@webkitglib/2.52
Commit: a2ffab5a6b8c2a8e04050f190d82db4e730aef0c
https://github.com/WebKit/WebKit/commit/a2ffab5a6b8c2a8e04050f190d82db4e730aef0c
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-19 (Tue, 19 May 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. https://bugs.webkit.org/show_bug.cgi?id=312365
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]
Canonical link: https://commits.webkit.org/305877.567@webkitglib/2.52
Commit: 6678301894f4dbf9b3a8255f6ee1c1a4dedba406
https://github.com/WebKit/WebKit/commit/6678301894f4dbf9b3a8255f6ee1c1a4dedba406
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-19 (Tue, 19 May 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. https://bugs.webkit.org/show_bug.cgi?id=312357
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]
Canonical link: https://commits.webkit.org/305877.568@webkitglib/2.52
Commit: dd339866719c5e3f81a4ebf9ac792966b4e83109
https://github.com/WebKit/WebKit/commit/dd339866719c5e3f81a4ebf9ac792966b4e83109
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-19 (Tue, 19 May 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. https://bugs.webkit.org/show_bug.cgi?id=312426
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
Canonical link: https://commits.webkit.org/305877.569@webkitglib/2.52
Commit: e9754ced56054d27c0dbe1fe93286b42ce5b19ec
https://github.com/WebKit/WebKit/commit/e9754ced56054d27c0dbe1fe93286b42ce5b19ec
Author: Ryosuke Niwa <[email protected]>
Date: 2026-05-19 (Tue, 19 May 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. https://bugs.webkit.org/show_bug.cgi?id=312712
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]
Canonical link: https://commits.webkit.org/305877.570@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/aa6b0c5cfb5c...e9754ced5605
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
