Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 37a64b18d20dc8644c584a2ed78a2a0894af3a70
https://github.com/WebKit/WebKit/commit/37a64b18d20dc8644c584a2ed78a2a0894af3a70
Author: Yijia Huang <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/ftl-osr-exit-phantom-array-unwritten-slot.js
M Source/JavaScriptCore/ftl/FTLOperations.cpp
Log Message:
-----------
Cherry-pick 305413.393@safari-7624-branch (aeeeecbce0b1).
https://bugs.webkit.org/show_bug.cgi?id=308545
[JSC] Fix incorrect handling of unwritten slots in
operationPopulateObjectInOSR for PhantomNewArrayWithButterfly
rdar://171067586
https://bugs.webkit.org/show_bug.cgi?id=308545
Reviewed by Yusuke Suzuki.
When a PhantomNewArrayWithButterfly is materialized during OSR exit, slots
that were
conditionally not written before the exit point should be treated as holes.
Fix
operationPopulateObjectInOSR to handle these slots correctly instead of
passing them
to putDirectIndex.
Test: JSTests/stress/ftl-osr-exit-phantom-array-unwritten-slot.js
Identifier: 305413.393@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.579@webkitglib/2.52
Commit: 87fa7e213437648975f4551d499fdb9a9cf16d3c
https://github.com/WebKit/WebKit/commit/87fa7e213437648975f4551d499fdb9a9cf16d3c
Author: Chris Dumez <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/WebCore/platform/graphics/GraphicsContext.cpp
M Source/WebCore/platform/graphics/controls/ControlFactory.h
Log Message:
-----------
Cherry-pick 305413.407@safari-7624-branch (338ced72faee).
https://bugs.webkit.org/show_bug.cgi?id=309218
[CoreIPC][GPU] Use-after-free on `ControlFactory::singleton()` due to usage
of non-thread-safe RefCounted
https://bugs.webkit.org/show_bug.cgi?id=309218
rdar://169706356
Reviewed by Ryosuke Niwa.
ControlFactory is ref'd / deref'd from several threads concurrently but
subclasses RefCounted.
* Source/WebCore/platform/graphics/GraphicsContext.cpp:
(WebCore::GraphicsContext::drawDisplayList):
Drop unnecessary ref'ing of of ControlFactory::singleton() on a background
thread.
* Source/WebCore/platform/graphics/controls/ControlFactory.h:
Subclass ThreadSafeRefCounted instead of RefCounted.
Identifier: 305413.407@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.580@webkitglib/2.52
Commit: f04ed1ed1d7b986c5636753d5cfc2b6525d080df
https://github.com/WebKit/WebKit/commit/f04ed1ed1d7b986c5636753d5cfc2b6525d080df
Author: Yusuke Suzuki <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/JavaScriptCore/heap/Heap.cpp
Log Message:
-----------
Cherry-pick 305413.412@safari-7624-branch (196f76f5bc51).
https://bugs.webkit.org/show_bug.cgi?id=308527
[JSC] WebAssemblyGCStructure::finalizeUnconditionally should be called
https://bugs.webkit.org/show_bug.cgi?id=308527
rdar://problem/171049091
Reviewed by Keith Miller.
Structure::finalizeUnconditionally must be called at GC end phase.
Structure and BrandedStructure are done correctly, but
WebAssemblyGCStructure is not.
* Source/JavaScriptCore/heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
Identifier: 305413.412@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.581@webkitglib/2.52
Commit: 2e808901c4b9313a62fcaeb4823174f85a33882b
https://github.com/WebKit/WebKit/commit/2e808901c4b9313a62fcaeb4823174f85a33882b
Author: Shu-yu Guo <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/JavaScriptCore/runtime/RegExp.cpp
M Source/JavaScriptCore/runtime/RegExpInlines.h
Log Message:
-----------
Cherry-pick 305413.415@safari-7624-branch (bfb699d9b999).
https://bugs.webkit.org/show_bug.cgi?id=309405
[JSC] Make RegExp::byteCodeCompileIfNecessary threadsafe
https://bugs.webkit.org/show_bug.cgi?id=309405
rdar://171888887
Reviewed by Yusuke Suzuki.
RegExp::matchConcurrently shouldn't cause any compilation, but bail out if
JIT
code for the regexp doesn't already exist. However, it is possible that a
RegExp has JIT code but no bytecode, in which case matchConcurrently can
incorrectly racily attempt to compile bytecode.
This PR makes byteCodeCompileIfNecessary threadsafe by taking the cell
lock. It
also bails out of matchConcurrently if the regexp doesn't already have
bytecode
when called from the compiler thread. Note that that check inside
matchInline
does not need to take the cell lock at that spot, because matchConcurrently,
the caller, already takes the cell lock.
There is no new test because to manifest this race requires artificially
adding
sleeps to threads.
* Source/JavaScriptCore/runtime/RegExp.cpp:
(JSC::RegExp::byteCodeCompileIfNecessary):
* Source/JavaScriptCore/runtime/RegExpInlines.h:
(JSC::RegExp::matchInline):
Identifier: 305413.415@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.582@webkitglib/2.52
Commit: 736d0819c54358179b6da5414d8ad9afb3d0addf
https://github.com/WebKit/WebKit/commit/736d0819c54358179b6da5414d8ad9afb3d0addf
Author: Shu-yu Guo <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/ftl-multigetbyoffset-constant-numberuse.js
Log Message:
-----------
Cherry-pick 305413.420@safari-7624-branch (532faf3ef13a).
https://bugs.webkit.org/show_bug.cgi?id=309517
[JSC] Add test for MultiGetByOffset interaction with ValueRepReduction
https://bugs.webkit.org/show_bug.cgi?id=309517
rdar://171948690
Reviewed by Keith Miller.
Add a test for the fix from 305413.251@safari-7624-branch, which escapes
MultiGetByOffset constant values which aren't convertible to double.
* JSTests/stress/ftl-multigetbyoffset-constant-numberuse.js: Added.
Identifier: 305413.420@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.583@webkitglib/2.52
Commit: 57d041747454b00334c1f11bf417b4e6ecc7c1c9
https://github.com/WebKit/WebKit/commit/57d041747454b00334c1f11bf417b4e6ecc7c1c9
Author: Shu-yu Guo <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
M Source/JavaScriptCore/wasm/WasmBBQPlan.cpp
M Source/JavaScriptCore/wasm/WasmCallee.cpp
M Source/JavaScriptCore/wasm/WasmIPIntPlan.cpp
M Source/JavaScriptCore/wasm/WasmModuleInformation.cpp
M Source/JavaScriptCore/wasm/WasmModuleInformation.h
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
M Source/JavaScriptCore/wasm/WasmOMGPlan.cpp
M Source/JavaScriptCore/wasm/WasmOSREntryPlan.cpp
M Source/JavaScriptCore/wasm/WasmPlan.cpp
M Source/JavaScriptCore/wasm/WasmSectionParser.cpp
M Source/JavaScriptCore/wasm/WasmStreamingParser.cpp
Log Message:
-----------
Cherry-pick 305413.432@safari-7624-branch (935ddf64e1d2).
https://bugs.webkit.org/show_bug.cgi?id=309538
[JSC] Make wasm name section parsing threadsafe
https://bugs.webkit.org/show_bug.cgi?id=309538
rdar://172053974
Reviewed by Yusuke Suzuki.
There is a race when parsing the wasm "name" custom section. Compiler
threads
and the main thread may race on access of the name section.
This PR fixes the race by making the name section go through a rel/acq
accessor. Lifetime safety is upkept by holding onto the retired name section
(the initial empty one) when the parser finishes parsing a name section. For
simplicity, all name sections after the first one are ignored, as there is
no normative requirement on custom sections.
No test added as manual sleeping is required to widen the window to
reproduce.
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addTopLevel):
* Source/JavaScriptCore/wasm/WasmCallee.cpp:
(JSC::Wasm::OptimizingJITCallee::addCodeOrigin):
* Source/JavaScriptCore/wasm/WasmIPIntPlan.cpp:
(JSC::Wasm::IPIntPlan::compileFunction):
* Source/JavaScriptCore/wasm/WasmModuleInformation.cpp:
(JSC::Wasm::ModuleInformation::setNameSection):
* Source/JavaScriptCore/wasm/WasmModuleInformation.h:
* Source/JavaScriptCore/wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* Source/JavaScriptCore/wasm/WasmPlan.cpp:
(JSC::Wasm::Plan::signpostMessage const):
* Source/JavaScriptCore/wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseCustom):
* Source/JavaScriptCore/wasm/WasmStreamingParser.cpp:
(JSC::Wasm::StreamingParser::finalize):
Identifier: 305413.432@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.584@webkitglib/2.52
Commit: da4751f74a7810f07aedcefc505f3b40f1e98ee4
https://github.com/WebKit/WebKit/commit/da4751f74a7810f07aedcefc505f3b40f1e98ee4
Author: Shu-yu Guo <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/promise-resolve-subclass-not-identity.js
M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
M Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp
Log Message:
-----------
Cherry-pick 305413.447@safari-7624-branch (8fb39d0d2bd3).
https://bugs.webkit.org/show_bug.cgi?id=309612
[JSC] Promise.resolve should not folded to identity on Promise subclasses
https://bugs.webkit.org/show_bug.cgi?id=309612
rdar://172195606
Reviewed by Yijia Huang.
Per spec, Promise.resolve(x) acts as identity on x iff x.constructor is
Promise
(more pedantically, if it is the same object as the `this` value that the
resolve function was called with, which, when called on the global Promise,
is
Promise). DFG currently incorrectly folds all builtin Promise subclasses to
identity as well.
This PR fixes the constant folding and abstract interpreter by restricting
the
folding to arguments that have the builtin promise structure, i.e. is not a
subclass.
Test: JSTests/stress/promise-resolve-subclass-not-identity.js
* JSTests/stress/promise-resolve-subclass-not-identity.js: Added.
(MyPromise):
* Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
Identifier: 305413.447@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.585@webkitglib/2.52
Commit: 8f5a6c17df6effca73a01405a9bd0bcca112ed4f
https://github.com/WebKit/WebKit/commit/8f5a6c17df6effca73a01405a9bd0bcca112ed4f
Author: Shu-yu Guo <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/osr-exit-scratch-buffer-gc.js
M Source/JavaScriptCore/dfg/DFGOSRExit.cpp
M Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp
Log Message:
-----------
Cherry-pick 305413.448@safari-7624-branch (6c8c0aa26b94).
https://bugs.webkit.org/show_bug.cgi?id=309599
[JSC] Scan OSR exits' ScratchBuffers
https://bugs.webkit.org/show_bug.cgi?id=309599
rdar://172203433
Reviewed by Yijia Huang and Yusuke Suzuki.
DFG and FTL OSR exits use ScratchBuffers when shuffling the stack during the
exit itself. If the stack is overwritten, it's possible that the
ScratchBuffer
becomes the sole retainer of the previously on-stack pointers. These buffers
are treated as conservative roots by the GC according to their activeLength,
which the OSR exits weren't setting. This PR fixes that by setting the
activeLength.
Test: JSTests/stress/osr-exit-scratch-buffer-gc.js
* JSTests/stress/osr-exit-scratch-buffer-gc.js: Added.
(opt):
(main):
* Source/JavaScriptCore/dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit):
* Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
Identifier: 305413.448@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.586@webkitglib/2.52
Commit: b3f87970ed3c84b380e6b78c1f937de5313a6ad3
https://github.com/WebKit/WebKit/commit/b3f87970ed3c84b380e6b78c1f937de5313a6ad3
Author: Vassili Bykov <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/JavaScriptCore/wasm/WasmStreamingCompiler.cpp
M Source/JavaScriptCore/wasm/WasmStreamingCompiler.h
M Source/WebCore/bindings/js/JSDOMGlobalObject.cpp
Log Message:
-----------
Cherry-pick 305413.457@safari-7624-branch (0e0b5050073d).
https://bugs.webkit.org/show_bug.cgi?id=309590
Use-after-free of StreamingCompiler::m_ticket
https://bugs.webkit.org/show_bug.cgi?id=309590
rdar://172087002
Reviewed by Marcus Plutowski.
This patch fixes the possibility of a UAF when Wasm streaming compiler is
invoked in an
iframe which is disposed of before compilation finishes.
The result of streaming compilation is expected by a lambda created when
the compilation
starts. The lambda captures a raw pointer to the globalObject and
(transitively via the
streaming compiler) a raw pointer to the TicketData associated with the
compilation
request. However, it's possible for the lambda to outlive those two
objects. This happens
in the context of an iframe if the iframe is removed before the compilation
finishes. In
that case the globalObject of the iframe is collected and the ticket is
cancelled and
destroyed. When compilation finishes, the lambda ends up dereferencing
dangling pointers.
This patch makes the following changes:
StreamingCompiler now holds TicketData via a ThreadSafeWeakPtr<TicketData>.
Every use site
promotes that weak pointer to a RefPtr and checks for both null (ticket
destroyed) and
isCancelled (ticket present but cancelled). This promote-and-check sequence
is factored
into a private takeTicketIfActive() helper.
In JSDOMGlobalObject.cpp, the lambda does not capture the raw globalObject
pointer.
Instead, it fetches the globalObject from the ticket via the compiler using
the streaming
compiler's new method globalObjectIfActive(). The method returns a nullptr
if the ticket
is no longer there or has been cancelled.
Testing: the failure scenario is not directly testable.
* Source/JavaScriptCore/wasm/WasmStreamingCompiler.cpp:
(JSC::Wasm::StreamingCompiler::StreamingCompiler):
(JSC::Wasm::StreamingCompiler::~StreamingCompiler):
(JSC::Wasm::StreamingCompiler::didComplete):
(JSC::Wasm::StreamingCompiler::fail):
(JSC::Wasm::StreamingCompiler::cancel):
(JSC::Wasm::StreamingCompiler::takeTicketIfActive):
(JSC::Wasm::StreamingCompiler::globalObjectIfActive):
* Source/JavaScriptCore/wasm/WasmStreamingCompiler.h:
* Source/WebCore/bindings/js/JSDOMGlobalObject.cpp:
(WebCore::handleResponseOnStreamingAction):
Identifier: 305413.457@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.587@webkitglib/2.52
Commit: 28b8de4799389537142f6a8709e449fee9cf645a
https://github.com/WebKit/WebKit/commit/28b8de4799389537142f6a8709e449fee9cf645a
Author: Yijia Huang <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/generator-expression-info-multiwide-remap.js
M Source/JavaScriptCore/bytecode/ExpressionInfo.cpp
M Source/JavaScriptCore/bytecode/ExpressionInfo.h
M Source/JavaScriptCore/bytecode/ExpressionInfoInlines.h
Log Message:
-----------
Cherry-pick 305413.466@safari-7624-branch (31c074842fc5).
https://bugs.webkit.org/show_bug.cgi?id=309843
[JSC] ExpressionInfo::Encoder::adjustInstPC should take an index instead of
a pointer
https://bugs.webkit.org/show_bug.cgi?id=309843
rdar://172411808
Reviewed by Mark Lam.
adjustInstPC() previously took a raw EncodedInfo* pointer that aliased
m_expressionInfoEncodedInfo's backing buffer. This is fragile since the
pointer can become invalid if the vector is resized.
Change adjustInstPC() to take an unsigned index instead. An integer
index remains valid across reallocations since vector element access
always recomputes the address from the current base pointer.
Test: JSTests/stress/generator-expression-info-multiwide-remap.js
Identifier: 305413.466@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.588@webkitglib/2.52
Commit: 95267bff0542fbc092c224afd2eb710ba1e75b6d
https://github.com/WebKit/WebKit/commit/95267bff0542fbc092c224afd2eb710ba1e75b6d
Author: Shu-yu Guo <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
Cherry-pick 305413.468@safari-7624-branch (3e734eae0148).
https://bugs.webkit.org/show_bug.cgi?id=172456
[JSC] Move FTL stack overflow check to prologue
https://bugs.webkit.org/show_bug.cgi?id=172456
rdar://172371127
Reviewed by Yusuke Suzuki.
Move the stack overflow check in FTL to a prologue using a custom prologue
generator. This simplifies to stack overflow logic to not require restoring
state before jumping to the thunk that throws the stack overflow exception.
Also fixes a bug where the patchpoint version was not correctly restoring
the
sp.
No new test as it takes too longer to trigger the stack overflow.
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
Identifier: 305413.468@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.589@webkitglib/2.52
Commit: cd1691058c1627acc7cc8fc6ad2b236c90acf8ee
https://github.com/WebKit/WebKit/commit/cd1691058c1627acc7cc8fc6ad2b236c90acf8ee
Author: Yusuke Suzuki <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/regexp-alternative-heavy.js
M JSTests/stress/regexp-bol-optimize-out-of-stack.js
A JSTests/stress/regexp-combined-large.js
A JSTests/stress/regexp-deep-nested.js
A JSTests/stress/regexp-heavy-mixed.js
A JSTests/stress/regexp-lookahead-heavy.js
M LayoutTests/js/script-tests/stack-overflow-regexp.js
M LayoutTests/js/stack-overflow-regexp-expected.txt
M Source/JavaScriptCore/assembler/AssemblerBuffer.h
M Source/JavaScriptCore/yarr/YarrErrorCode.cpp
M Source/JavaScriptCore/yarr/YarrErrorCode.h
M Source/JavaScriptCore/yarr/YarrParser.h
M Source/JavaScriptCore/yarr/YarrPattern.cpp
M Source/JavaScriptCore/yarr/YarrSyntaxChecker.cpp
Log Message:
-----------
Cherry-pick 305413.479@safari-7624-branch (a0acd4b94ec1).
https://bugs.webkit.org/show_bug.cgi?id=309601
[JSC] Make RegExp tolerant against excessive stress
https://bugs.webkit.org/show_bug.cgi?id=309601
rdar://171448096
Reviewed by Yijia Huang.
We fixed three issues. But only one is actually critical security issue.
Remaining two are making RegExp tolerant against excessive patterns.
1. We have no guard against too large JIT code generation (4GB~). We fix
AssemblerBuffer to detect and crash safely.
2. We add RegExp capture limit which is aligned to V8's number.
3. We add RegExp frame size limit, which makes RegExp parsing failed
when frame size exceeds `unsigned` entries.
Tests: JSTests/stress/regexp-alternative-heavy.js
JSTests/stress/regexp-combined-large.js
JSTests/stress/regexp-deep-nested.js
JSTests/stress/regexp-heavy-mixed.js
JSTests/stress/regexp-lookahead-heavy.js
* JSTests/stress/regexp-alternative-heavy.js: Added.
(tryCompileAndRun):
* JSTests/stress/regexp-bol-optimize-out-of-stack.js:
* JSTests/stress/regexp-combined-large.js: Added.
(tryCompileAndRun):
* JSTests/stress/regexp-deep-nested.js: Added.
(tryCompileAndRun):
* JSTests/stress/regexp-heavy-mixed.js: Added.
(tryCompileAndRun):
* JSTests/stress/regexp-lookahead-heavy.js: Added.
(tryCompileAndRun):
* LayoutTests/js/script-tests/stack-overflow-regexp.js:
(shouldThrow.recursiveCall):
(shouldThrow):
* LayoutTests/js/stack-overflow-regexp-expected.txt:
* Source/JavaScriptCore/assembler/AssemblerBuffer.h:
(JSC::AssemblerDataImpl::grow):
(JSC::AssemblerBuffer::AssemblerBuffer):
(JSC::AssemblerBuffer::isAvailable):
(JSC::AssemblerBuffer::LocalWriter::putIntegralUnchecked):
(JSC::AssemblerBuffer::putIntegral):
* Source/JavaScriptCore/yarr/YarrErrorCode.cpp:
(JSC::Yarr::errorMessage):
(JSC::Yarr::errorToThrow):
* Source/JavaScriptCore/yarr/YarrErrorCode.h:
* Source/JavaScriptCore/yarr/YarrParser.h:
(JSC::Yarr::requires):
(JSC::Yarr::Parser::parse):
(JSC::Yarr::Parser::parseParenthesesBegin):
(JSC::Yarr::Parser::countCaptures):
* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin):
(JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets):
(JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets):
(JSC::Yarr::YarrPatternConstructor::setupOffsets):
* Source/JavaScriptCore/yarr/YarrSyntaxChecker.cpp:
(JSC::Yarr::SyntaxChecker::atomParenthesesSubpatternBegin):
Identifier: 305413.479@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.590@webkitglib/2.52
Commit: eeb2ea3e715deb1e5fd69dfd1c6ba254c11f79f3
https://github.com/WebKit/WebKit/commit/eeb2ea3e715deb1e5fd69dfd1c6ba254c11f79f3
Author: Shu-yu Guo <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/typedarray-forEach-transition.js
M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h
Log Message:
-----------
Cherry-pick 305413.485@safari-7624-branch (32d01d0d2755).
https://bugs.webkit.org/show_bug.cgi?id=309918
[JSC] Fix vector caching in TypedArray.prototype.forEach
https://bugs.webkit.org/show_bug.cgi?id=309918
rdar://172446537
Reviewed by Yijia Huang.
A TypedArray's vector can move even when it's fixed-length and non-shared
due
to materializing its ArrayBuffer and due to BoundsChecking Wasm memories
doing
reallocation. In those cases, the current code incorrectly caches the data
pointer to the vector. This PR fixes those cases by reloading the vector.
Test: JSTests/stress/typedarray-forEach-transition.js
* JSTests/stress/typedarray-forEach-transition.js: Added.
(ta.forEach):
* Source/JavaScriptCore/runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::typedArrayViewForEachImpl):
Identifier: 305413.485@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.591@webkitglib/2.52
Commit: 608e1228bfaa73fc6b1dfc4c6099b05d598874c2
https://github.com/WebKit/WebKit/commit/608e1228bfaa73fc6b1dfc4c6099b05d598874c2
Author: Shu-yu Guo <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/checkpoint-exception-handler-during-osr-exit.js
M Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp
Log Message:
-----------
Cherry-pick 305413.486@safari-7624-branch (ee8795961642).
https://bugs.webkit.org/show_bug.cgi?id=309930
[JSC] Don't advance bytecode when reifying inline frames at a checkpoint
https://bugs.webkit.org/show_bug.cgi?id=309930
rdar://172471763
Reviewed by Yusuke Suzuki.
When reifying inlined frames, the BytecodeIndex currently written into the
reified baseline frames in the case when OSR exiting at a checkpoint, is the
bytecode after the checkpoint. In case the bytecode in which checkpointed
execution resumes throws, this would result in the wrong exception handler
as
the index points to one past the bytecode being re-executed.
Note that this BytecodeIndex on the baseline frame is different from the
index
used for actual resumption of execution. That index is kept in a sidestate
and
encodes the checkpoint.
Test: JSTests/stress/checkpoint-exception-handler-during-osr-exit.js
* JSTests/stress/checkpoint-exception-handler-during-osr-exit.js: Added.
(const.b):
(opt):
(main):
* Source/JavaScriptCore/dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
Identifier: 305413.486@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.592@webkitglib/2.52
Commit: c3c3383fa59db3409030354f8b30654504c0121b
https://github.com/WebKit/WebKit/commit/c3c3383fa59db3409030354f8b30654504c0121b
Author: Brady Eidson <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
M Source/WTF/wtf/WallTime.cpp
M Source/WTF/wtf/WallTime.h
M Source/WebCore/Modules/notifications/Notification.cpp
M Source/WebCore/Modules/notifications/Notification.h
M Source/WebCore/Modules/notifications/NotificationData.h
M Source/WebCore/Modules/notifications/NotificationDataCocoa.mm
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/Shared/WebProcessCreationParameters.h
M Source/WebKit/Shared/WebProcessCreationParameters.serialization.in
M Source/WebKit/Shared/WebPushDaemonConstants.h
M Source/WebKit/Shared/WebPushMessage.cpp
M Source/WebKit/UIProcess/API/C/WKWebsiteDataStoreConfigurationRef.cpp
M Source/WebKit/UIProcess/API/C/WKWebsiteDataStoreConfigurationRef.h
M Source/WebKit/UIProcess/API/Cocoa/_WKWebsiteDataStoreConfiguration.h
M Source/WebKit/UIProcess/API/Cocoa/_WKWebsiteDataStoreConfiguration.mm
M Source/WebKit/UIProcess/WebProcessPool.cpp
M Source/WebKit/UIProcess/WebsiteData/WebsiteDataStoreConfiguration.h
M Source/WebKit/WebProcess/WebProcess.cpp
M Source/WebKit/webpushd/WebPushDaemon.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/PushAPI.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebPushDaemon.mm
M Tools/WebKitTestRunner/TestController.cpp
M Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm
Log Message:
-----------
Cherry-pick 305413.488@safari-7624-branch (46110060bb2a).
https://bugs.webkit.org/show_bug.cgi?id=309940
Don't let ServiceWorkers handling push events call showNotification but
then immediately close that notification
rdar://170734287
https://bugs.webkit.org/show_bug.cgi?id=309940
Reviewed by Ben Nham.
We have "silent push" protection, where we require service workers handling
a push event to post a user visible notification.
However, a website that wants to use push messages to get silent background
runtime can get "user visible" credit
by showing the notification but then immediately close it.
This patch adds behavior such that a persistent notification has a minimum
lifetime before script can call close() on it.
This lifetime lines up with the maximum "push event handler" lifetime, such
that an attacker that sends a second push
message to try to close notifications from the first push message needs to
wait, and that second handler will itself
need to show a new notification for the push subscription to remain valid.
Notifications already had a "creation time" member, but the member wasn't
properly kept up to date as it was passed
around through various processes and delegate calls. This patch makes it so
that value is accurate and maintained.
We also pipe through explicit overriding of the "required lifetime" value
to something shorter for testing purposes.
Tests: Tools/TestWebKitAPI/Tests/WebKitCocoa/PushAPI.mm
Tools/TestWebKitAPI/Tests/WebKitCocoa/WebPushDaemon.mm
* Source/WTF/wtf/WallTime.cpp:
(WTF::WallTime::fromSecondsSinceEpoch):
(WTF::WallTime::secondsSinceEpoch const):
* Source/WTF/wtf/WallTime.h:
* Source/WebCore/Modules/notifications/Notification.cpp:
(WebCore::Notification::setOverridePersistentNotificationMinimumLifetime):
(WebCore::Notification::create):
(WebCore::Notification::Notification):
(WebCore::Notification::close):
(WebCore::Notification::data const):
* Source/WebCore/Modules/notifications/Notification.h:
* Source/WebCore/Modules/notifications/NotificationData.h:
* Source/WebCore/Modules/notifications/NotificationDataCocoa.mm:
(WebCore::NotificationData::fromDictionary):
(WebCore::NotificationData::dictionaryRepresentation const):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/Shared/WebProcessCreationParameters.h:
* Source/WebKit/Shared/WebProcessCreationParameters.serialization.in:
* Source/WebKit/Shared/WebPushDaemonConstants.h:
(): Deleted.
* Source/WebKit/Shared/WebPushMessage.cpp:
(WebKit::WebPushMessage::notificationPayloadToCoreData const):
* Source/WebKit/UIProcess/API/C/WKWebsiteDataStoreConfigurationRef.cpp:
(WKWebsiteDataStoreConfigurationOverridePersistentNotificationMinimumLifetimeForTesting):
(WKWebsiteDataStoreConfigurationSetOverridePersistentNotificationMinimumLifetimeForTesting):
* Source/WebKit/UIProcess/API/C/WKWebsiteDataStoreConfigurationRef.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKWebsiteDataStoreConfiguration.h:
* Source/WebKit/UIProcess/API/Cocoa/_WKWebsiteDataStoreConfiguration.mm:
(-[_WKWebsiteDataStoreConfiguration
overridePersistentNotificationMinimumLifetimeForTesting]):
(-[_WKWebsiteDataStoreConfiguration
setOverridePersistentNotificationMinimumLifetimeForTesting:]):
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::initializeNewWebProcess):
* Source/WebKit/UIProcess/WebsiteData/WebsiteDataStoreConfiguration.h:
(WebKit::WebsiteDataStoreConfiguration::overridePersistentNotificationMinimumLifetimeForTesting
const):
(WebKit::WebsiteDataStoreConfiguration::setOverridePersistentNotificationMinimumLifetimeForTesting):
* Source/WebKit/WebProcess/WebProcess.cpp:
(WebKit::WebProcess::initializeWebProcess):
* Source/WebKit/webpushd/WebPushDaemon.mm:
(WebPushD::WebPushDaemon::silentPushTimeout const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/PushAPI.mm:
((PushAPI, callNotificationClose)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WebPushDaemon.mm:
(TestWebKitAPI::(WebPushDBuiltInTest, ShowAndGetNotifications)):
(TestWebKitAPI::(WebPushDBuiltInTest,
PushNotificationCloseImmediatelyAfterShowShouldFail)):
(TestWebKitAPI::(WebPushDBuiltInTest,
ImplicitSilentPushTimerCancelledOnShowingNotification)):
(TestWebKitAPI::(WebPushDBuiltInTest,
ImplicitSilentPushTimerIgnoredForInspectedContexts)):
(TestWebKitAPI::(WebPushDPushNotificationEventTest, Basic)):
* Tools/WebKitTestRunner/TestController.cpp:
(WTR::TestController::defaultWebsiteDataStore):
(WTR::TestController::grantNotificationPermission):
* Tools/WebKitTestRunner/cocoa/TestControllerCocoa.mm:
(WTR::TestController::platformInitializeDataStore):
Identifier: 305413.488@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.593@webkitglib/2.52
Commit: 18bcacd91722af355a66e50528f3fb7a753656e9
https://github.com/WebKit/WebKit/commit/18bcacd91722af355a66e50528f3fb7a753656e9
Author: Anand Srinivasan <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/b3cppi-ssa-dominance.js
M Source/JavaScriptCore/b3/B3CanonicalizePrePostIncrements.cpp
Log Message:
-----------
Cherry-pick 305413.504@safari-7624-branch (783f58da6e75).
https://bugs.webkit.org/show_bug.cgi?id=310055
Fix dominance analysis in B3CanonicalizePrePostIncrements
https://bugs.webkit.org/show_bug.cgi?id=310055
rdar://172282220
Reviewed by Yusuke Suzuki and Yijia Huang.
B3CanonicalizePrePostIncrements moves an add to generate an address for
a memory operation, and needs to check that the current block dominates
all uses of the add's result. If the current block does not dominate all
uses the compiler must cancel the optimization for the current block but
right now the loop does nothing.
Test: JSTests/stress/b3cppi-ssa-dominance.js
* JSTests/stress/b3cppi-ssa-dominance.js: Added.
(arr2.fill.0x1337.trigger):
* Source/JavaScriptCore/b3/B3CanonicalizePrePostIncrements.cpp:
(JSC::B3::canonicalizePrePostIncrements):
Identifier: 305413.504@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.594@webkitglib/2.52
Commit: 7e5eb04ea1ead5c316f31f226d463ce959f1f74a
https://github.com/WebKit/WebKit/commit/7e5eb04ea1ead5c316f31f226d463ce959f1f74a
Author: Shu-yu Guo <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/literal-parser-proto-setter.js
M Source/JavaScriptCore/runtime/LiteralParser.cpp
Log Message:
-----------
Cherry-pick 305413.524@safari-7624-branch (15b9c504262f).
https://bugs.webkit.org/show_bug.cgi?id=310231
[JSC] Take slow path in LiteralParser if original structure changes
https://bugs.webkit.org/show_bug.cgi?id=310231
rdar://172857687
Reviewed by Keith Miller.
LiteralParser has a fast path for caching transitions if we're parsing a
literal with an existing transition. This is done before the object literal
is
actually parsed. During actual parsing, user code may run due to setters for
__proto__, which may invalidate the original object's structure and thus its
cached transition. Currently we don't account for the structure changing.
This
PR fixes it by taking the slow path if the structure changes.
Test: JSTests/stress/literal-parser-proto-setter.js
* JSTests/stress/literal-parser-proto-setter.js: Added.
* Source/JavaScriptCore/runtime/LiteralParser.cpp:
(JSC::requires):
Identifier: 305413.524@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.595@webkitglib/2.52
Commit: ae672ba217b3e7e962d3aa8c777748c3df8d0453
https://github.com/WebKit/WebKit/commit/ae672ba217b3e7e962d3aa8c777748c3df8d0453
Author: Vassili Bykov <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/wasm/regress/310207.js
M Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp
Log Message:
-----------
Cherry-pick 305413.525@safari-7624-branch (c5d68122b2fa).
https://bugs.webkit.org/show_bug.cgi?id=310207
[JSC] WebAssemblyGCStructureTypeDependencies::process should retain
unexpanded types too
rdar://172856476
https://bugs.webkit.org/show_bug.cgi?id=310207
Reviewed by Yusuke Suzuki.
WebAssemblyGCTypeDependencies collects a transitive closure of
TypeDefinitions
reachable from a root type to prevent dangling pointers when a Wasm module
is
GC'd but GC objects or Tags survive. Currently, it only retains the expanded
(concrete) forms of transitively-referenced types. However, the expanded
types'
fields contain Type.index values that point to unexpanded forms
(Projections,
Subtypes). These unexpanded forms are not retained and can be freed by
TypeInformation::tryCleanup(), leaving dangling pointers.
Rework the traversal so that unexpanded types are placed on the worklist,
and
process() retains both the unexpanded and expanded forms of each type it
visits.
Test: JSTests/wasm/regress/310207.js (only detects the issue in a debug
build)
Identifier: 305413.525@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.596@webkitglib/2.52
Commit: 7bb2cb1ad254fa01d37f49e1c532d9bc8053d8d8
https://github.com/WebKit/WebKit/commit/7bb2cb1ad254fa01d37f49e1c532d9bc8053d8d8
Author: Yusuke Suzuki <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/wasm/stress/instance-anchor.js
M Source/JavaScriptCore/wasm/debugger/WasmDebugServer.cpp
M Source/JavaScriptCore/wasm/debugger/WasmDebugServer.h
M Source/JavaScriptCore/wasm/debugger/WasmModuleManager.cpp
M Source/JavaScriptCore/wasm/debugger/WasmModuleManager.h
M Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.cpp
Log Message:
-----------
Cherry-pick 305413.527@safari-7624-branch (eecf636daa52).
https://bugs.webkit.org/show_bug.cgi?id=310234
[JSC] Wasm::InstanceAnchor should be unregistered at the prologue of
JSWebAssemblyInstance destructor
https://bugs.webkit.org/show_bug.cgi?id=310234
rdar://172821924
Reviewed by Yijia Huang.
Wasm::InstanceAnchor can expose JSWebAssemblyInstance to the other
threads including compiler. Thus if we would like to start destroying
JSWebAssemblyInstance, we should first unregister Wasm::InstanceAnchor
before destroying any part of JSWebAssemblyInstance.
Test: JSTests/wasm/stress/instance-anchor.js
* JSTests/wasm/stress/instance-anchor.js: Added.
(bury):
(main.warmUpInstanceB):
(main):
* Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::~JSWebAssemblyInstance):
Identifier: 305413.527@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.597@webkitglib/2.52
Commit: a4bfae46061ac428fa791de6c7c52c211ee5fd69
https://github.com/WebKit/WebKit/commit/a4bfae46061ac428fa791de6c7c52c211ee5fd69
Author: Kai Tamkun <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/regress-171780137.js
M Source/JavaScriptCore/runtime/LiteralParser.cpp
Log Message:
-----------
Cherry-pick 305413.528@safari-7624-branch (f2bc8d9a2369).
https://bugs.webkit.org/show_bug.cgi?id=309841
[JSC] Skip transitions with symbol names in LiteralParser
rdar://171780137
https://bugs.webkit.org/show_bug.cgi?id=309841
Reviewed by Yusuke Suzuki and Darin Adler.
This PR causes LiteralParser::equalIdentifier to return false when
given a symbol. This prevents following property addition transitions
when the added property name is a symbol. The literal parser doesn't
deal with symbol property names.
Test: JSTests/stress/regress-171780137.js
* JSTests/stress/regress-171780137.js: Added.
(assert):
* Source/JavaScriptCore/runtime/LiteralParser.cpp:
(JSC::reviverMode>::equalIdentifier): Add a check for symbols
Identifier: 305413.528@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.598@webkitglib/2.52
Commit: 70f497dbc9c84135b3be17cceb78eea07d1f5131
https://github.com/WebKit/WebKit/commit/70f497dbc9c84135b3be17cceb78eea07d1f5131
Author: Yijia Huang <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/ftl-materialize-new-array-with-butterfly.js
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
Cherry-pick 305413.530@safari-7624-branch (ad7a71bb3efe).
https://bugs.webkit.org/show_bug.cgi?id=310223
[JSC] Fix GC safety for sunk contiguous array materialization in FTL
https://bugs.webkit.org/show_bug.cgi?id=310223
rdar://172827445
Reviewed by Yusuke Suzuki.
compileMaterializeNewArrayWithButterfly writes element values into a raw
butterfly before
allocating the JSArray header. For contiguous arrays the element values are
GC cell pointers,
but their last B3 use is the store64 into the butterfly. B3 backward
liveness therefore marks
them dead at that point, so they are absent from the stack when
allocateJSArray's slow path
triggers a collection — the butterfly is unowned and the GC does not trace
its contents.
Fix by collecting contiguous element values and calling
ensureStillAliveHere after
allocateJSArray. This inserts a zero-instruction patchpoint that is a
formal B3 use of each
value, extending their liveness backward through the allocation slow path
and forcing them onto
the stack where the GC conservative scanner can find them.
INT32 and DOUBLE elements are not cell pointers and need no treatment.
Test: JSTests/stress/ftl-materialize-new-array-with-butterfly.js
Identifier: 305413.530@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.599@webkitglib/2.52
Commit: f07bc7d1497545736843901dc4401935de444b3c
https://github.com/WebKit/WebKit/commit/f07bc7d1497545736843901dc4401935de444b3c
Author: Dan Hecht <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/fixobviousspills-earlydefs.js
M Source/JavaScriptCore/b3/air/AirFixObviousSpills.cpp
Log Message:
-----------
Cherry-pick 305413.539@safari-7624-branch (383834666ab9).
https://bugs.webkit.org/show_bug.cgi?id=310303
[JSC] Fix AirFixObviousSpills modeling of early defs
https://bugs.webkit.org/show_bug.cgi?id=310303
rdar://171874387
Reviewed by Yusuke Suzuki and Keith Miller.
fixObviousSpills treats early defs the same as late defs, which is
fine for the analysis phase since aliasing is effectively computed
at the boundary after the instruction. However, during the rewrite
phase, it should not use an alias that has been invalidated by
any early defs (e.g. scratch registers). Otherwise, the early def
may clobber the aliased thing before it's used.
Fix this by breaking apart the steps so that rewriting can be
done in the correct sequence.
Test: JSTests/stress/fixobviousspills-earlydefs.js
* JSTests/stress/fixobviousspills-earlydefs.js: Added.
* Source/JavaScriptCore/b3/air/AirFixObviousSpills.cpp:
Identifier: 305413.539@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.600@webkitglib/2.52
Commit: 4f541fa63f9666b2545e0faba20a97ee0cc7493e
https://github.com/WebKit/WebKit/commit/4f541fa63f9666b2545e0faba20a97ee0cc7493e
Author: Anand Srinivasan <[email protected]>
Date: 2026-05-19 (Tue, 19 May 2026)
Changed paths:
A JSTests/stress/baseline-op-del-by-id-write-barrier.js
A JSTests/stress/baseline-op-del-by-val-write-barrier.js
M Source/JavaScriptCore/jit/BaselineJITRegisters.h
M Source/JavaScriptCore/jit/JIT.h
M Source/JavaScriptCore/jit/JITPropertyAccess.cpp
Log Message:
-----------
Cherry-pick 305413.540@safari-7624-branch (7c715b4eeda1).
https://bugs.webkit.org/show_bug.cgi?id=310139
Fix baseline write barrier handling in OpDelBy{Id,Val}
https://bugs.webkit.org/show_bug.cgi?id=310139
rdar://172299872
Reviewed by Yusuke Suzuki.
In the baseline implementation of OpDelById, code like `o = delete o.x` can
overwrite the pointer to object o with a boolean value before the write
barrier, meaning the barrier is wrongly invoked on the boolean instead of
the original object. Same problem with OpDelByVal, which can be
replicated with `o = delete o["x"]`.
Tests: JSTests/stress/baseline-op-del-by-id-write-barrier.js
JSTests/stress/baseline-op-del-by-val-write-barrier.js
* JSTests/stress/baseline-op-del-by-id-write-barrier.js: Added.
(main):
* JSTests/stress/baseline-op-del-by-val-write-barrier.js: Added.
(main):
* Source/JavaScriptCore/jit/BaselineJITRegisters.h:
* Source/JavaScriptCore/jit/JIT.h:
* Source/JavaScriptCore/jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emitWriteBarrier):
Identifier: 305413.540@safari-7624-branch
Canonical link: https://commits.webkit.org/305877.601@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/fb39ecd0963a...4f541fa63f96
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
