Branch: refs/heads/webkitglib/2.50
Home: https://github.com/WebKit/WebKit
Commit: f0c49d1d0f19c7eeae8ce242bf598ae3cebc1a52
https://github.com/WebKit/WebKit/commit/f0c49d1d0f19c7eeae8ce242bf598ae3cebc1a52
Author: Youenn Fablet <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/Navigation.mm
Log Message:
-----------
Cherry-pick 301765.328@safari-7623-branch (00c47cad6649).
https://bugs.webkit.org/show_bug.cgi?id=278659
Safari allows CSRF by resetting the Sec-Fetch-Site header on refresh
rdar://158416842
Reviewed by Chris Dumez.
In case of form resubmition, we were recomputing Sec-Fetch-Site and friends
from the destination origin, which was wrong.
Instead, given we already computed the Sec headers, we reuse them when
resubmitting a form.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/Navigation.mm
* Source/WebCore/loader/cache/CachedResourceLoader.cpp:
(WebCore::shouldReuseExistingFetchMetadata):
(WebCore::shouldUpdateFetchMetadata):
(WebCore::CachedResourceLoader::updateHTTPRequestHeaders):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/Navigation.mm:
(TEST(Navigation, FormResubmited)):
Identifier: 301765.328@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.446@webkitglib/2.50
Commit: a06f287bde028f9c9d8ac7f5817ca813c1082d57
https://github.com/WebKit/WebKit/commit/a06f287bde028f9c9d8ac7f5817ca813c1082d57
Author: Shu-yu Guo <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M JSTests/stress/regexp-duplicate-named-captures.js
M Source/JavaScriptCore/yarr/YarrInterpreter.cpp
M Source/JavaScriptCore/yarr/YarrJIT.cpp
M Source/JavaScriptCore/yarr/YarrPattern.cpp
M Source/JavaScriptCore/yarr/YarrPattern.h
Log Message:
-----------
Cherry-pick 301765.330@safari-7623-branch (3b3f8ae21a23).
https://bugs.webkit.org/show_bug.cgi?id=302560
[JSC] Distinguish named and numbered backreferences in Yarr
https://bugs.webkit.org/show_bug.cgi?id=302560
rdar://164402403
Reviewed by Keith Miller.
The duplicate named capture group feature added the ability to have
duplicate
capture group names so long as they're in different disjuncts. The
semantics is
to check if any of the capture groups with the same name matched. There
can be
a maximum of one match as they are restricted to different disjuncts. In
this
case, Yarr mints a special "duplicated named groups group" id along with an
indirection table that can check if any of the groups with the same name
matched.
Currently both named and numbered backreferences are compiled to the same
PatternTerm and ByteTerm type, with named capture groups resolved to the
numbers. If the capture group number is part of a duplicated name groups
group,
the special id is used instead.
The problem is that that duplicated named group resolution is done even when
the backreference was explicitly numbered. That is, in
/(?<k>...)|(?<k>...\1)/,
\1 is supposed to refer to the first parentheses, but ends up referring to
both
disjuncts. As shown in this example, this can be recursive!
This recursion can manifest as out of bounds when doing backtracking,
because
you can end up matching a group of size N, match a disjunct of size M, then
backtrack expecting to undo size N, but end up rewinding size M.
This PR fixes this issue by distinguishing numbered and named backreference
PatternTerms, and only performing the duplicate named group logic for named
backreferences.
A new test function is added to regexp-duplicate-named-capture.js
Identifier: 301765.330@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.447@webkitglib/2.50
Commit: b08dc7f0b743e33e43811177d5c5462e7673b1e9
https://github.com/WebKit/WebKit/commit/b08dc7f0b743e33e43811177d5c5462e7673b1e9
Author: Anthony Tarbinian <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A LayoutTests/workers/worker-set-delete-terminate-crash-expected.txt
A LayoutTests/workers/worker-set-delete-terminate-crash.html
M Source/JavaScriptCore/runtime/OrderedHashTableHelper.h
Log Message:
-----------
Cherry-pick 301765.357@safari-7623-branch (eccc2eed44f9).
https://bugs.webkit.org/show_bug.cgi?id=303658
[JSC] Modifying storage in OrderedHashTableHelper should
DeferTerminationForAWhile
https://bugs.webkit.org/show_bug.cgi?id=303658
rdar://162356649
Reviewed by Keith Miller.
When resizing storage in OrderedHashTableHelper (via addImpl or
shinkIfNeeded),
it's possible to leave the storage in an inconsistent state if we handle a
termination exception. For consistency, we should DeferTerminationForAWhile
until the storage has been fully updated.
Test: workers/worker-set-delete-terminate-crash.html
* LayoutTests/workers/worker-set-delete-terminate-crash-expected.txt: Added.
* LayoutTests/workers/worker-set-delete-terminate-crash.html: Added.
* Source/JavaScriptCore/runtime/OrderedHashTableHelper.h:
(JSC::OrderedHashTableHelper::addImpl):
(JSC::OrderedHashTableHelper::shrinkIfNeeded):
Identifier: 301765.357@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.448@webkitglib/2.50
Commit: 651ac71c62e521569634ef365572775997437cdb
https://github.com/WebKit/WebKit/commit/651ac71c62e521569634ef365572775997437cdb
Author: Jer Noble <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M Source/WebCore/platform/audio/AudioResamplerKernel.cpp
Log Message:
-----------
Cherry-pick 301765.369@safari-7623-branch (ee36b92f6f9f).
https://bugs.webkit.org/show_bug.cgi?id=303959
Integer underflow in AudioResamplerKernel::getSourceSpan()
rdar://162552376
https://bugs.webkit.org/show_bug.cgi?id=303959
Reviewed by Eric Carlson.
Protect against underflows when calculating the number of
source frames needed using WTF::safeSub().
* Source/WebCore/platform/audio/AudioResamplerKernel.cpp:
(WebCore::AudioResamplerKernel::getSourceSpan):
Identifier: 301765.369@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.449@webkitglib/2.50
Commit: dec74a64f42cb0b2d9c26a8f9a61075d976ca0fc
https://github.com/WebKit/WebKit/commit/dec74a64f42cb0b2d9c26a8f9a61075d976ca0fc
Author: Shu-yu Guo <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp
Log Message:
-----------
Cherry-pick 301765.371@safari-7623-branch (167074a8e936).
https://bugs.webkit.org/show_bug.cgi?id=304032
[JSC] Store float instead of double for F32 in OMG tail calls
https://bugs.webkit.org/show_bug.cgi?id=304032
rdar://166285942
Reviewed by Dan Hecht and Mark Lam.
F32 and F64 were both doing a double store when spilling in OMG tail calls,
while F32 should be doing a float store to avoid writing out of bounds of
the
spill slot.
No test as cannot reliably and observably test this temporary stack
corruption.
Identifier: 301765.371@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.450@webkitglib/2.50
Commit: 69d217c4e4189c39efa8fbfa1144e5184c2ead14
https://github.com/WebKit/WebKit/commit/69d217c4e4189c39efa8fbfa1144e5184c2ead14
Author: Shu-yu Guo <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A JSTests/wasm/gc/validate-unreachable-unset-local.js
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
Cherry-pick 301765.372@safari-7623-branch (e2b2223e8a58).
https://bugs.webkit.org/show_bug.cgi?id=304086
[JSC] Fix Wasm validation of unreachable locals
https://bugs.webkit.org/show_bug.cgi?id=304086
rdar://166283484
Reviewed by Dan Hecht.
WebAssembly requires non-defaultable locals (i.e. locals with non-nullable
ref
types) to be set before they're used by local.get. Current implementation
incorrectly performs this validation in the case the local.get/set are
unreachable. While initialization is tracked in such unreachable local
instructions, the locals stack is not correctly reset at control flow merge
points. This PR resets the stack at such points.
Test: JSTests/wasm/gc/validate-unreachable-unset-local.js
Identifier: 301765.372@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.451@webkitglib/2.50
Commit: 96c21b65344526df42e7b9b225b49f0da49a1c92
https://github.com/WebKit/WebKit/commit/96c21b65344526df42e7b9b225b49f0da49a1c92
Author: Rob Buis <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A LayoutTests/fast/forms/onformdata-navigate-crash-expected.txt
A LayoutTests/fast/forms/onformdata-navigate-crash.html
M Source/WebCore/html/HTMLFormElement.cpp
M Source/WebCore/loader/FormSubmission.cpp
M Source/WebCore/loader/FormSubmission.h
Log Message:
-----------
Cherry-pick 301765.373@safari-7623-branch (1acabe11a6b0).
https://bugs.webkit.org/show_bug.cgi?id=301645
[WebKit][Main+SU] [ea2e11e05711c082] ASAN_ILL | WebCore::FormState::create;
WebCore::FormSubmission::create; WebCore::HTMLFormElement::submit
https://bugs.webkit.org/show_bug.cgi?id=301645
rdar://163480500
Reviewed by Chris Dumez.
When constructing FormSubmission the formdata event is dispatched. When
combined
with the Navigation API the event handling can cause the document frame to
be
detached, triggering a release assert in the FormState constructor. To fix
this
detect the frame removal after dispatching and end the submit operation
early.
* LayoutTests/fast/forms/onformdata-navigate-crash-expected.txt: Added.
* LayoutTests/fast/forms/onformdata-navigate-crash.html: Added.
* Source/WebCore/html/HTMLFormElement.cpp:
(WebCore::HTMLFormElement::submit):
* Source/WebCore/loader/FormSubmission.cpp:
(WebCore::FormSubmission::create):
* Source/WebCore/loader/FormSubmission.h:
Canonical link: https://commits.webkit.org/[email protected]
Identifier: 301765.373@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.452@webkitglib/2.50
Commit: ff38ad767a903f96a4a907f922faaf4dc5aea8ff
https://github.com/WebKit/WebKit/commit/ff38ad767a903f96a4a907f922faaf4dc5aea8ff
Author: Frédéric Wang <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A
LayoutTests/fast/webcodecs/resetting-audio-decoder-with-unsupported-codec-crash-expected.txt
A
LayoutTests/fast/webcodecs/resetting-audio-decoder-with-unsupported-codec-crash.html
A
LayoutTests/fast/webcodecs/resetting-audio-encoder-with-unsupported-codec-crash-expected.txt
A
LayoutTests/fast/webcodecs/resetting-audio-encoder-with-unsupported-codec-crash.html
A
LayoutTests/fast/webcodecs/resetting-video-decoder-with-unsupported-codec-crash-expected.txt
A
LayoutTests/fast/webcodecs/resetting-video-decoder-with-unsupported-codec-crash.html
A
LayoutTests/fast/webcodecs/resetting-video-encoder-with-unsupported-codec-crash-expected.txt
A
LayoutTests/fast/webcodecs/resetting-video-encoder-with-unsupported-codec-crash.html
M Source/WebCore/Modules/webcodecs/WebCodecsAudioDecoder.cpp
M Source/WebCore/Modules/webcodecs/WebCodecsAudioEncoder.cpp
M Source/WebCore/Modules/webcodecs/WebCodecsBase.cpp
M Source/WebCore/Modules/webcodecs/WebCodecsVideoDecoder.cpp
M Source/WebCore/Modules/webcodecs/WebCodecsVideoEncoder.cpp
Log Message:
-----------
Cherry-pick 301765.374@safari-7623-branch (13f8cb5f9bd5).
https://bugs.webkit.org/show_bug.cgi?id=300958
ASAN_SEGV | WebCore::JSCallbackData::invokeCallback;
WebCore::JSWebCodecsErrorCallback::invoke;
WebCore::WebCodecsVideoDecoder::closeDecoder
https://bugs.webkit.org/show_bug.cgi?id=300958
Reviewed by Youenn Fablet.
When calling configure() on a webcodec with an unsupported config,
postTaskToCodec() is called to "queue a task to run the Close
AudioDecoder algorithm with NotSupportedError" as per
https://www.w3.org/TR/webcodecs.
If reset() is called before that task in dequeued, then the codec state
becomes Unconfigured and WebCodecsBase::virtualHasPendingActivity() no
longer ensures the JS wrapper stay alive, potentially causing a nullptr
crash when trying to execute the associated error callback:
```
bool WebCodecsBase::virtualHasPendingActivity() const
{
return m_state == WebCodecsCodecState::Configured &&
(m_codecControlMessagesPending || m_isMessageQueueBlocked);
}
```
This patch removes the assumption that the codec state must be
Configured in order to keep the JS wrapper alive and that addresses the
nullptr crash here. It makes sure that virtualHasPendingActivity()
would eventually be reset to false though.
Tests:
fast/webcodecs/resetting-audio-decoder-with-unsupported-codec-crash.html
fast/webcodecs/resetting-audio-encoder-with-unsupported-codec-crash.html
fast/webcodecs/resetting-video-decoder-with-unsupported-codec-crash.html
fast/webcodecs/resetting-video-encoder-with-unsupported-codec-crash.html
*
LayoutTests/fast/webcodecs/resetting-audio-decoder-with-unsupported-codec-crash-expected.txt:
Added.
*
LayoutTests/fast/webcodecs/resetting-audio-decoder-with-unsupported-codec-crash.html:
Added.
*
LayoutTests/fast/webcodecs/resetting-audio-encoder-with-unsupported-codec-crash-expected.txt:
Added.
*
LayoutTests/fast/webcodecs/resetting-audio-encoder-with-unsupported-codec-crash.html:
Added.
*
LayoutTests/fast/webcodecs/resetting-video-decoder-with-unsupported-codec-crash-expected.txt:
Added.
*
LayoutTests/fast/webcodecs/resetting-video-decoder-with-unsupported-codec-crash.html:
Added.
*
LayoutTests/fast/webcodecs/resetting-video-encoder-with-unsupported-codec-crash-expected.txt:
Added.
*
LayoutTests/fast/webcodecs/resetting-video-encoder-with-unsupported-codec-crash.html:
Added.
* Source/WebCore/Modules/webcodecs/WebCodecsBase.cpp:
(WebCore::WebCodecsBase::virtualHasPendingActivity const): Don't release
the codec when it's not in configured state.
* Source/WebCore/Modules/webcodecs/WebCodecsAudioDecoder.cpp:
(WebCore::WebCodecsAudioDecoder::configure): Ensure we clear
m_isMessageQueueBlocked when done.
* Source/WebCore/Modules/webcodecs/WebCodecsAudioEncoder.cpp:
(WebCore::WebCodecsAudioEncoder::configure): Ditto.
* Source/WebCore/Modules/webcodecs/WebCodecsVideoDecoder.cpp:
(WebCore::WebCodecsVideoDecoder::configure): Ditto.
* Source/WebCore/Modules/webcodecs/WebCodecsVideoEncoder.cpp:
(WebCore::WebCodecsVideoEncoder::configure): Ditto.
Canonical link: https://commits.webkit.org/[email protected]
Identifier: 301765.374@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.453@webkitglib/2.50
Commit: 26aa7ff54b94c908271594126c220c5131184888
https://github.com/WebKit/WebKit/commit/26aa7ff54b94c908271594126c220c5131184888
Author: Claudio Saavedra <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A LayoutTests/fast/rendering/collapsed-scrollbar-crash-expected.txt
A LayoutTests/fast/rendering/collapsed-scrollbar-crash.html
M Source/WebCore/rendering/RenderElement.h
M Source/WebCore/rendering/RenderScrollbarPart.h
Log Message:
-----------
Cherry-pick [email protected] (db1ee7ac4ada).
https://bugs.webkit.org/show_bug.cgi?id=302377
[WebKit][Main+SU] [292b7257c3a80358] ASAN_SEGV |
WebCore::RenderBox::localRectsForRepaint;
WebCore::RenderObject::clippedOverflowRect;
WebCore::RenderObject::repaintSlowRepaintObject
https://bugs.webkit.org/show_bug.cgi?id=302377
Reviewed by Simon Fraser.
RenderScrollbarPart doesn't have an enclosing layer,
so we can short-circuit the check in RenderElement
and return false always.
Test: fast/rendering/collapsed-scrollbar-crash.html
* LayoutTests/fast/rendering/collapsed-scrollbar-crash-expected.txt: Added.
* LayoutTests/fast/rendering/collapsed-scrollbar-crash.html: Added.
* Source/WebCore/rendering/RenderElement.h:
* Source/WebCore/rendering/RenderScrollbarPart.h:
Canonical link: https://commits.webkit.org/[email protected]
Identifier: 301765.379@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.454@webkitglib/2.50
Commit: 5c8079d5cd3894b8be2fcb58a89f0e752eabe42b
https://github.com/WebKit/WebKit/commit/5c8079d5cd3894b8be2fcb58a89f0e752eabe42b
Author: Youenn Fablet <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encoder.h
Log Message:
-----------
Cherry-pick 301765.383@safari-7623-branch (9d4b06b7a57c).
https://bugs.webkit.org/show_bug.cgi?id=302377
Potential 'out of bounds' issue committed to upstream libwebrtc
rdar://166200109
Reviewed by Chris Dumez.
Cherry-picking of
https://github.com/webmproject/libvpx/commit/d6e5cd7132d59d3cea86d06c9aae26f95fe00adb.
Identifier: 301765.383@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.455@webkitglib/2.50
Commit: be1cd8055d8e54a34f9e158144f178e6d7d5946e
https://github.com/WebKit/WebKit/commit/be1cd8055d8e54a34f9e158144f178e6d7d5946e
Author: Claudio Saavedra <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A
LayoutTests/fast/css-grid-layout/subgrid-with-changing-writing-mode-crash-expected.txt
A
LayoutTests/fast/css-grid-layout/subgrid-with-changing-writing-mode-crash.html
M Source/WebCore/rendering/RenderGrid.cpp
Log Message:
-----------
Cherry-pick 301765.380@safari-7623-branch (3c710b2a33ae).
https://bugs.webkit.org/show_bug.cgi?id=301640
[WebKit][Main+SU] [80bcc69aeb72643f] ASAN_ILL |
WebCore::GridTrackSizingAlgorithm::copyUsedTrackSizesForSubgrid;
WebCore::GridTrackSizingAlgorithm::run; WebCore::RenderGrid::layoutGrid
https://bugs.webkit.org/show_bug.cgi?id=301640
Reviewed by Sammy Gill.
When the writing mode of a grid changes orthogonally, there might
be incongruences in how parent and subgrid tracks relate. This needs
to be taken into account so that later the track sizing algorithm can
try to copy the track sizes for its subgrid. If the writing mode direction
has changed during a style change for a grid, call setNeedsItemPlacement()
for subgrid children.
Test: fast/css-grid-layout/subgrid-with-changing-writing-mode-crash.html
*
LayoutTests/fast/css-grid-layout/subgrid-with-changing-writing-mode-crash-expected.txt:
Added.
*
LayoutTests/fast/css-grid-layout/subgrid-with-changing-writing-mode-crash.html:
Added.
* Source/WebCore/rendering/RenderGrid.cpp:
(WebCore::RenderGrid::styleDidChange):
Canonical link: https://commits.webkit.org/[email protected]
Identifier: 301765.380@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.456@webkitglib/2.50
Commit: 1cb1de2cf3d91ce00d5876506677034f7e467f93
https://github.com/WebKit/WebKit/commit/1cb1de2cf3d91ce00d5876506677034f7e467f93
Author: Yijia Huang <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A JSTests/stress/map-forEach.js
M Source/JavaScriptCore/dfg/DFGNodeType.h
Log Message:
-----------
Cherry-pick 301765.392@safari-7623-branch (47b55468bf82).
https://bugs.webkit.org/show_bug.cgi?id=304950
[JSC] MapIterationEntryKey should have NodeResultJS, not NodeResultInt32
https://bugs.webkit.org/show_bug.cgi?id=304950
rdar://167200795
Reviewed by Marcus Plutowski.
MapIterationEntryKey returns arbitrary JSValues (map keys can be any type),
so it should be declared with NodeResultJS to match MapIterationEntryValue.
Test: JSTests/stress/map-forEach.js
Identifier: 301765.392@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.457@webkitglib/2.50
Commit: ae0ad782eb71a36addb49a1af984b93e0b8e3740
https://github.com/WebKit/WebKit/commit/ae0ad782eb71a36addb49a1af984b93e0b8e3740
Author: Ryosuke Niwa <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M Source/WebCore/xml/XMLSerializer.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewConfiguration.mm
Log Message:
-----------
Cherry-pick 301765.396@safari-7623-branch (f6a3e33e70aa).
https://bugs.webkit.org/show_bug.cgi?id=305020
XMLSerializer.serializeToString leaks URLs used by web extensions
https://bugs.webkit.org/show_bug.cgi?id=305020
<rdar://165629762>
Reviewed by Chris Dumez and Wenson Hsieh.
Fix the bug by masking out custom scheme URLs in XMLSerializer.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewConfiguration.mm
* Source/WebCore/xml/XMLSerializer.cpp:
(WebCore::XMLSerializer::serializeToString):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewConfiguration.mm:
(TEST(WebKit, ConfigurationMaskedURLSchemes)):
Identifier: 301765.396@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.458@webkitglib/2.50
Commit: bc78b8a67059f1fbde334effbf5ac1589affbdb5
https://github.com/WebKit/WebKit/commit/bc78b8a67059f1fbde334effbf5ac1589affbdb5
Author: Kai Tamkun <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A JSTests/stress/object-assign-inline-storage.js
M Source/JavaScriptCore/runtime/ObjectConstructorInlines.h
Log Message:
-----------
Cherry-pick 301765.401@safari-7623-branch (dabdca54351d).
https://bugs.webkit.org/show_bug.cgi?id=305020
Don't attempt to copy nonexistent inline storage in fast object cloning
rdar://167110652
Reviewed by Yusuke Suzuki.
This prevents an attempt to access inline storage in Object.assign when
there is no inline storage to copy.
Added a test that crashed with an assertion failure in debug mode
before these changes.
* JSTests/stress/object-assign-inline-storage.js: Added.
(shouldBe):
(C):
* Source/JavaScriptCore/runtime/ObjectConstructorInlines.h:
(JSC::checkStructureForClone): Renamed from checkStrucureForClone.
(JSC::objectCloneFast): Add a check for inline storage presence.
(JSC::tryCreateObjectViaCloning): Updated an invocation name.
(JSC::checkStrucureForClone): Renamed to checkStructureForClone.
Identifier: 301765.401@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.459@webkitglib/2.50
Commit: b7bc506b0ba86841fd3c983bb021e5b7ae4c610e
https://github.com/WebKit/WebKit/commit/b7bc506b0ba86841fd3c983bb021e5b7ae4c610e
Author: Anand Srinivasan <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A JSTests/stress/dfg-miscompiles-new-regexp.js
M Source/JavaScriptCore/dfg/DFGOperations.cpp
Log Message:
-----------
Cherry-pick 301765.415@safari-7623-branch (4175b9cec24d).
https://bugs.webkit.org/show_bug.cgi?id=305161
operationNewRegExpUntyped should call constructRegExp with a newTarget
https://bugs.webkit.org/show_bug.cgi?id=305161
rdar://167199047
Reviewed by Mark Lam.
If the RegExp constructor is invoked using "new" then it must have a
valid newTarget, but not if it is invoked as a function call
("RegExp(...)" vs. "new RegExp(...)"). This patch updates DFG to
follow the specification correctly, since previously the code did not
pass in a newTarget to the RegExp constructor.
operationNewRegExpUntyped() is only called for the NewRegExpUntyped DFG
node.
NewRegExpUntyped is only emitted by the bytecode parser if newTargetNode !=
callTargetNode.
Hence, the newTarget value that should be passes is the callTargetNode i.e.
the RegExp constructor.
See https://262.ecma-international.org/#sec-regexp-pattern-flags
specifying what should be passed in newTarget.
```
2. If NewTarget is undefined, then
a. Let newTarget be the active function object.
```
Test: JSTests/stress/dfg-miscompiles-new-regexp.js
* JSTests/stress/dfg-miscompiles-new-regexp.js: Added.
(opt):
(main):
* Source/JavaScriptCore/dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
Identifier: 301765.415@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.460@webkitglib/2.50
Commit: b8a4658a67dbd7c8c56ffbbd1044a1215f74895a
https://github.com/WebKit/WebKit/commit/b8a4658a67dbd7c8c56ffbbd1044a1215f74895a
Author: Gerald Squelart <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
Log Message:
-----------
Cherry-pick 301765.416@safari-7623-branch (7c8da3f7f913).
https://bugs.webkit.org/show_bug.cgi?id=305033
Catch multiplication overflow in bytesPerRow() validator
https://bugs.webkit.org/show_bug.cgi?id=305033
rdar://167621238
Reviewed by Dan Glastonbury.
The multiplication `m_size->width() * *bytesPerPixel` could overflow
into a negative number, allowing the validation to pass for very large
widths.
Fixed by using `WTF::safeMultiply`, which checks for overflows relative
to the result type.
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Identifier: 301765.416@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.461@webkitglib/2.50
Commit: a5ad2d0327993d3714d70081b3ce9308ac0b3d75
https://github.com/WebKit/WebKit/commit/a5ad2d0327993d3714d70081b3ce9308ac0b3d75
Author: Tim Horton <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A
LayoutTests/http/tests/scroll-to-text-fragment/dynamic-content-is-found-expected.txt
A
LayoutTests/http/tests/scroll-to-text-fragment/dynamic-content-is-found.html
M Source/WebCore/dom/FragmentDirectiveUtilities.cpp
M Source/WebCore/dom/FragmentDirectiveUtilities.h
M Source/WebCore/page/LocalFrameView.cpp
M Source/WebCore/page/LocalFrameView.h
Log Message:
-----------
Cherry-pick 300918@main (e4e149e651c9).
https://bugs.webkit.org/show_bug.cgi?id=300059
bsky.app: No highlight when navigating to text fragment link generated by
Safari
https://bugs.webkit.org/show_bug.cgi?id=300059
rdar://150880542
Reviewed by Abrar Rahman Protyasha.
When we successfully parse a text fragment out of the URL, but fail to find
the referenced content, start a 500ms repeating timer, and re-try finding
the content each time it fires, up to 3 seconds, or when the user scrolls,
or
the content is found, whichever comes first.
New test: http/tests/scroll-to-text-fragment/dynamic-content-is-found.html
* Source/WebCore/dom/FragmentDirectiveUtilities.cpp:
(WebCore::operator<<):
* Source/WebCore/dom/FragmentDirectiveUtilities.h:
Add overloads to dump parsed text fragments, for ease of debugging.
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::LocalFrameView):
(WebCore::LocalFrameView::reset):
(WebCore::LocalFrameView::scrollToFragment):
Factor scrollToTextFragment out of scrollToFragment to make the flow a bit
more clear.
(WebCore::LocalFrameView::scrollToTextFragment):
Invert the logic to be early-return-y.
When we fail, start the retry timer, with the rules explained above.
(WebCore::LocalFrameView::scrollToTextFragmentRetryTimerFired):
Retry the scroll when the timer fires.
(WebCore::LocalFrameView::scrollToAnchorFragment):
Rename this from scrollToFragmentInternal to scrollToAnchorFragment to
better explain
which subset of the fragment scrolling mechanism it covers.
(WebCore::LocalFrameView::maintainScrollPositionAtScrollToTextFragmentRange):
(WebCore::LocalFrameView::scrollToAnchorAndTextFragmentNowIfNeeded):
(WebCore::LocalFrameView::scrollToPendingTextFragmentRange):
Another clarity-related rename.
(WebCore::LocalFrameView::scrollToFragmentInternal): Deleted.
(WebCore::LocalFrameView::scrollToTextFragmentRange): Deleted.
* Source/WebCore/page/LocalFrameView.h:
Canonical link: https://commits.webkit.org/300918@main
Canonical link: https://commits.webkit.org/298234.462@webkitglib/2.50
Commit: 651b3b11a5851062b6d53ea1d462088a661c9121
https://github.com/WebKit/WebKit/commit/651b3b11a5851062b6d53ea1d462088a661c9121
Author: Basuke Suzuki <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A LayoutTests/http/tests/security/resources/page-with-text.html
A
LayoutTests/http/tests/security/text-fragment/popup-cross-origin-blocked-expected.txt
A
LayoutTests/http/tests/security/text-fragment/popup-cross-origin-blocked.html
A
LayoutTests/http/tests/security/text-fragment/popup-same-origin-allowed-expected.txt
A
LayoutTests/http/tests/security/text-fragment/popup-same-origin-allowed.html
M Source/WebCore/page/LocalFrameView.cpp
Log Message:
-----------
Cherry-pick 301765.417@safari-7623-branch (75bcb9f43cbe).
https://bugs.webkit.org/show_bug.cgi?id=300059
Block text fragments in cross-origin window.open() popups.
rdar://163804356
Reviewed by Chris Dumez.
This implements a security defense against timing side-channel attacks
using Text Fragments in cross-origin popups.
The exploit pattern:
w = window.open("attacker.com");
w.location = "victim.com";
w.location = "victim.com#:~:text=secret";
w.location = "about:blank";
// Measure timing to detect if text was found
Defense mechanism:
- Add checkTextFragmentSecurity() in LocalFrameView.cpp
- Block text fragments when opener origin ≠ current document origin
- Allow text fragments in same-origin popups (legitimate use)
- Allow text fragments in top-level navigation (no opener)
This aligns with Chrome's 2019 defense (commit c0d3c4cca8b16),
which uses RelatedPages().size() check. WebKit uses a simpler
cross-origin check that achieves the same security goal.
The fix does not affect about:blank origin inheritance or WPT tests,
as those don't use text fragments.
Tests: http/tests/security/text-fragment/popup-cross-origin-blocked.html
http/tests/security/text-fragment/popup-same-origin-allowed.html
* LayoutTests/http/tests/security/resources/page-with-text.html: Added.
*
LayoutTests/http/tests/security/text-fragment/popup-cross-origin-blocked-expected.txt:
Added.
*
LayoutTests/http/tests/security/text-fragment/popup-cross-origin-blocked.html:
Added.
*
LayoutTests/http/tests/security/text-fragment/popup-same-origin-allowed-expected.txt:
Added.
*
LayoutTests/http/tests/security/text-fragment/popup-same-origin-allowed.html:
Added.
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::checkTextFragmentSecurity):
(WebCore::LocalFrameView::scrollToTextFragment):
Identifier: 301765.417@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.463@webkitglib/2.50
Commit: f060077ba15d947f481b46c84e415bf67ef645ad
https://github.com/WebKit/WebKit/commit/f060077ba15d947f481b46c84e415bf67ef645ad
Author: Rob Buis <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A LayoutTests/svg/filters/filter-insert-button-crash-expected.txt
A LayoutTests/svg/filters/filter-insert-button-crash.html
M Source/WebCore/page/LocalFrameViewLayoutContext.cpp
M Source/WebCore/page/LocalFrameViewLayoutContext.h
M Source/WebCore/rendering/RenderObject.cpp
M Source/WebCore/rendering/updating/RenderTreeBuilderInline.cpp
Log Message:
-----------
Cherry-pick 301765.361@safari-7623-branch (e218dd58cf7e).
https://bugs.webkit.org/show_bug.cgi?id=301140
Cherry-pick [email protected] (6c8a256d475b).
rdar://137178583
[SVG] Don't repaint when referenced resources change if the renderer is
not in-tree yet
https://bugs.webkit.org/show_bug.cgi?id=301140
rdar://137178583
Reviewed by Alan Baradlay.
When moving svg resources around it's possible to end up
triggering a repaint before the renderer is in-tree. To
fix that, add API for blocking repaints and start using that
while in RenderTreeBuilder::Inline::splitFlow.
Test: svg/filters/filter-insert-button-crash.html
* LayoutTests/svg/filters/filter-insert-button-crash-expected.txt:
Added.
* LayoutTests/svg/filters/filter-insert-button-crash.html: Added.
* Source/WebCore/page/LocalFrameViewLayoutContext.cpp:
(WebCore::RepaintBlocker::RepaintBlocker):
(WebCore::RepaintBlocker::~RepaintBlocker):
* Source/WebCore/page/LocalFrameViewLayoutContext.h:
* Source/WebCore/rendering/RenderObject.cpp:
(WebCore::RenderObject::repaint const):
* Source/WebCore/rendering/updating/RenderTreeBuilderInline.cpp:
(WebCore::RenderTreeBuilder::Inline::splitFlow):
Canonical link:
https://commits.webkit.org/[email protected]
Identifier: 301765.361@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.464@webkitglib/2.50
Commit: 05f72bf324dd621fd56ce4050f05f69d88eede19
https://github.com/WebKit/WebKit/commit/05f72bf324dd621fd56ce4050f05f69d88eede19
Author: Claudio Saavedra <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A LayoutTests/highlight/highlight-crash-2-expected.txt
A LayoutTests/highlight/highlight-crash-2.html
M Source/WebCore/Modules/highlight/Highlight.cpp
Log Message:
-----------
Cherry-pick [email protected] (ae3502b8b960).
https://bugs.webkit.org/show_bug.cgi?id=304176
[WebKit][Main] [76d1bb47f067ac21] ASAN_SEGV |
WebCore::Highlight::clearFromSetLike; WebCore::HighlightRegistry::clear;
WebCore::Document::commonTeardown
https://bugs.webkit.org/show_bug.cgi?id=304176
Reviewed by Chris Dumez.
With the right disposing order, it is possible to cause reentrancy to
Highlight::clearFromSetLike(). This is due to the ownership relationship
between
Document->HighlightRegistry->Highlight->HighlightRange->Range->Document.
The attached test shows an example of how to achieve this (a dangling
document
that is only attached to a Range gets disposed during another Document's
disposing,
causing a reentrant call to Highlight::clearFromSetLike()).
Ensure Highlight::clearFromSetLike() is safely reentrant by exchanging
Highlight::m_highlightRanges with an empty vector so that any potentially
reentrant
call is a no-op.
Test: highlight/highlight-crash-2.html
* LayoutTests/highlight/highlight-crash-2-expected.txt: Added.
* LayoutTests/highlight/highlight-crash-2.html: Added.
* Source/WebCore/Modules/highlight/Highlight.cpp:
(WebCore::Highlight::clearFromSetLike):
Canonical link:
https://commits.webkit.org/[email protected]
Identifier: 301765.424@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.465@webkitglib/2.50
Commit: 7ac1627a8f632136c4fa08476d261db65e46675e
https://github.com/WebKit/WebKit/commit/7ac1627a8f632136c4fa08476d261db65e46675e
Author: Claudio Saavedra <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M Source/WebCore/Modules/highlight/Highlight.cpp
Log Message:
-----------
Cherry-pick [email protected] (51b8db6618a3).
https://bugs.webkit.org/show_bug.cgi?id=304176
[WebKit][Main] [76d1bb47f067ac21] ASAN_SEGV |
WebCore::Highlight::clearFromSetLike; WebCore::HighlightRegistry::clear;
WebCore::Document::commonTeardown
https://bugs.webkit.org/show_bug.cgi?id=304176
Reviewed by Chris Dumez.
Follow-up after [email protected] to improve the bug fix.
Covered by existing test.
* Source/WebCore/Modules/highlight/Highlight.cpp:
(WebCore::Highlight::clearFromSetLike):
Canonical link:
https://commits.webkit.org/[email protected]
Identifier: 301765.426@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.466@webkitglib/2.50
Commit: ed35da6a7a359a538d3e789e3d3891613881d838
https://github.com/WebKit/WebKit/commit/ed35da6a7a359a538d3e789e3d3891613881d838
Author: Yusuke Suzuki <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A JSTests/stress/dfg-proto-fold-invalidate3.js
M Source/JavaScriptCore/bytecode/GetByStatus.cpp
Log Message:
-----------
Cherry-pick 744106342146. https://bugs.webkit.org/show_bug.cgi?id=305521
[JSC] GetByStatus::computeFor has race condition around swapped object's
structure checks
https://bugs.webkit.org/show_bug.cgi?id=305521
rdar://155413221
Reviewed by Yijia Huang.
Now ObjectPropertyCondition is propertly created. But it is possible
that this finally registered ObjectPropertyCondition's structures are
not having a proper condition we would like. We are obtainining objects
from the condition and checking structure's characteristics.
Test: JSTests/stress/dfg-proto-fold-invalidate3.js
* JSTests/stress/dfg-proto-fold-invalidate3.js: Added.
(shouldBe):
(opt):
(watchCalleeProperty):
(async sleep):
(createClonedArguments):
(p):
(async main):
* Source/JavaScriptCore/bytecode/GetByStatus.cpp:
(JSC::GetByStatus::computeFor):
Identifier: 305413.33@safari-7624-branch
Canonical link: https://commits.webkit.org/301765.428@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.467@webkitglib/2.50
Commit: 85fae84d47ba553895ab867e87acbec636dbc224
https://github.com/WebKit/WebKit/commit/85fae84d47ba553895ab867e87acbec636dbc224
Author: Yusuke Suzuki <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A JSTests/wasm/stress/ipint-variable-length-gc-opcodes.js
M Source/JavaScriptCore/llint/InPlaceInterpreter64.asm
M Source/JavaScriptCore/wasm/WasmBBQJIT.h
M Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp
M Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp
M Source/JavaScriptCore/wasm/WasmIPIntGenerator.h
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp
Log Message:
-----------
Cherry-pick 37d2b52a42b9. https://bugs.webkit.org/show_bug.cgi?id=305813
[JSC] IPInt PC move should be recorded one for prefixed opcodes
https://bugs.webkit.org/show_bug.cgi?id=305813
rdar://168478682
Reviewed by Keith Miller and Dan Hecht.
Prefixed opcodes in IPInt (GC, SIMD, etc.) have subsequent sub-opcode to
dispatch actual instruction. However this sub-opcode is encoded via
VarUInt32 LEB. This means that opcode can have multiple different ways
to be encoded (e.g. one value can be represeted via 2 byte, 3 byte,
etc.). As a result, we should not use advancePC(constant) since
instruction is variable-length. This patch fixes the issue using
advancePC(constant).
Test: JSTests/wasm/stress/ipint-variable-length-gc-opcodes.js
* JSTests/wasm/stress/ipint-variable-length-gc-opcodes.js: Added.
(createRedundantLEB128):
(encodeVarUInt32):
(testRefI31RedundantEncoding):
(testI31GetRedundantEncoding):
(testArrayLenRedundantEncoding):
(testArrayFillRedundantEncoding):
(testArrayCopyRedundantEncoding):
(testExternAnyConvertRedundantEncoding):
* Source/JavaScriptCore/llint/InPlaceInterpreter64.asm:
* Source/JavaScriptCore/wasm/WasmBBQJIT.h:
* Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addSIMDConstant):
(JSC::Wasm::BBQJITImpl::BBQJIT::addSIMDExtractLane):
(JSC::Wasm::BBQJITImpl::BBQJIT::addSIMDReplaceLane):
(JSC::Wasm::BBQJITImpl::BBQJIT::addConstant): Deleted.
(JSC::Wasm::BBQJITImpl::BBQJIT::addExtractLane): Deleted.
(JSC::Wasm::BBQJITImpl::BBQJIT::addReplaceLane): Deleted.
* Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addSIMDConstant):
(JSC::Wasm::BBQJITImpl::BBQJIT::addSIMDExtractLane):
(JSC::Wasm::BBQJITImpl::BBQJIT::addSIMDReplaceLane):
(JSC::Wasm::BBQJITImpl::BBQJIT::addConstant): Deleted.
(JSC::Wasm::BBQJITImpl::BBQJIT::addExtractLane): Deleted.
(JSC::Wasm::BBQJITImpl::BBQJIT::addReplaceLane): Deleted.
* Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp:
(JSC::Wasm::ConstExprGenerator::addSIMDConstant):
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::simd):
* Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp:
(JSC::Wasm::IPIntGenerator::addSIMDSplat):
(JSC::Wasm::IPIntGenerator::addSIMDShuffle):
(JSC::Wasm::IPIntGenerator::addSIMDShift):
(JSC::Wasm::IPIntGenerator::addSIMDExtmul):
(JSC::Wasm::IPIntGenerator::addSIMDConstant):
(JSC::Wasm::IPIntGenerator::addSIMDExtractLane):
(JSC::Wasm::IPIntGenerator::addSIMDReplaceLane):
(JSC::Wasm::IPIntGenerator::addSIMDI_V):
(JSC::Wasm::IPIntGenerator::addSIMDV_V):
(JSC::Wasm::IPIntGenerator::addSIMDBitwiseSelect):
(JSC::Wasm::IPIntGenerator::addSIMDRelOp):
(JSC::Wasm::IPIntGenerator::addSIMDV_VV):
(JSC::Wasm::IPIntGenerator::addRefI31):
(JSC::Wasm::IPIntGenerator::addI31GetS):
(JSC::Wasm::IPIntGenerator::addI31GetU):
(JSC::Wasm::IPIntGenerator::addArrayLen):
(JSC::Wasm::IPIntGenerator::addArrayFill):
(JSC::Wasm::IPIntGenerator::addArrayCopy):
(JSC::Wasm::IPIntGenerator::addAnyConvertExtern):
(JSC::Wasm::IPIntGenerator::addExternConvertAny):
(JSC::Wasm::IPIntGenerator::addExtractLane): Deleted.
(JSC::Wasm::IPIntGenerator::addReplaceLane): Deleted.
* Source/JavaScriptCore/wasm/WasmIPIntGenerator.h:
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp:
(JSC::Wasm::OMGIRGenerator::addSIMDConstant):
(JSC::Wasm::OMGIRGenerator::addSIMDExtractLane):
(JSC::Wasm::OMGIRGenerator::addSIMDReplaceLane):
(JSC::Wasm::OMGIRGenerator::addExtractLane): Deleted.
(JSC::Wasm::OMGIRGenerator::addReplaceLane): Deleted.
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp:
(JSC::Wasm::OMGIRGenerator::addSIMDConstant):
(JSC::Wasm::OMGIRGenerator::addSIMDExtractLane):
(JSC::Wasm::OMGIRGenerator::addSIMDReplaceLane):
(JSC::Wasm::OMGIRGenerator::addExtractLane): Deleted.
(JSC::Wasm::OMGIRGenerator::addReplaceLane): Deleted.
Identifier: 301765.432@safari-7623-branch
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.468@webkitglib/2.50
Commit: 46f817a61d5d4e5524972c8fec075ded85cf750f
https://github.com/WebKit/WebKit/commit/46f817a61d5d4e5524972c8fec075ded85cf750f
Author: Chris Dumez <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M Source/WebCore/html/canvas/EXTDisjointTimerQueryWebGL2.cpp
Log Message:
-----------
Cherry-pick 301765.347@safari-7623-branch (fabe69c2dcb4).
https://bugs.webkit.org/show_bug.cgi?id=303348
Unsafe argument capture in EXTDisjointTimerQueryWebGL2::queryCounterEXT()
https://bugs.webkit.org/show_bug.cgi?id=303348
rdar://165125247
Reviewed by Brent Fulgham.
The lambda runs asynchronously and it is thus unsafe to capture by reference
here. We need to capture a smart pointer to the query to make sure it is
kept
alive.
* Source/WebCore/html/canvas/EXTDisjointTimerQueryWebGL2.cpp:
(WebCore::EXTDisjointTimerQueryWebGL2::queryCounterEXT):
Identifier: 301765.347@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.469@webkitglib/2.50
Commit: a70ab2e560ecddc6d6fdf10e81333be43395579e
https://github.com/WebKit/WebKit/commit/a70ab2e560ecddc6d6fdf10e81333be43395579e
Author: Matthew Finkel <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkSession.cpp
M Source/WebKit/NetworkProcess/NetworkSessionCreationParameters.h
M
Source/WebKit/NetworkProcess/NetworkSessionCreationParameters.serialization.in
M
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementManager.cpp
M
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementManager.h
M
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementManagerInterface.cpp
M
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementManagerInterface.h
M
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementNetworkLoader.cpp
M
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementNetworkLoader.h
M
Source/WebKit/NetworkProcess/PrivateClickMeasurement/cocoa/PrivateClickMeasurementNetworkLoaderCocoa.mm
M
Source/WebKit/Shared/EntryPointUtilities/Cocoa/Daemon/PCMDaemonEntryPoint.mm
M Source/WebKit/UIProcess/WebsiteData/soup/WebsiteDataStoreSoup.cpp
Log Message:
-----------
Cherry-pick 22d708a2fd38. https://bugs.webkit.org/show_bug.cgi?id=305951
[PCM] Connections for Private Click Measurement are not proxied
https://bugs.webkit.org/show_bug.cgi?id=305951
rdar://168552975
Reviewed by Alex Christensen.
This has a couple missing pieces. The expectation is that reports are sent
via
a proxied connection, and requests for fraud prevention key material is
fetched
over a proxied connection. Currently, these connections are not proxied
because
they are not:
1) associated with the application bundle (e.g, Safari)
2) considered "third party" resource requests
This PR plumbs through the application bundle identifier or audit token,
depending on which one is available, and it sets the request as a cross-site
subresource request. As a safe guard, this patch also requires failing
closed
when the connection is not proxied.
* Source/WebKit/NetworkProcess/NetworkSession.cpp:
(WebKit::managerOrProxy):
*
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementManager.cpp:
(WebKit::PrivateClickMeasurementManager::create):
(WebKit::PrivateClickMeasurementManager::PrivateClickMeasurementManager):
(WebKit::PrivateClickMeasurementManager::getTokenPublicKey):
(WebKit::PrivateClickMeasurementManager::getSignedUnlinkableTokenForSource):
(WebKit::PrivateClickMeasurementManager::getSignedUnlinkableTokenForDestination):
(WebKit::PrivateClickMeasurementManager::fireConversionRequestImpl):
*
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementManager.h:
*
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementManagerInterface.cpp:
(WebKit::PCM::initializePCMStorageInDirectory):
*
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementManagerInterface.h:
*
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementNetworkLoader.cpp:
(WebKit::PCM::NetworkLoader::start):
*
Source/WebKit/NetworkProcess/PrivateClickMeasurement/PrivateClickMeasurementNetworkLoader.h:
*
Source/WebKit/NetworkProcess/PrivateClickMeasurement/cocoa/PrivateClickMeasurementNetworkLoaderCocoa.mm:
(WebKit::PCM::statelessSessionWithoutRedirectsSingleton):
(WebKit::PCM::NetworkLoader::start):
*
Source/WebKit/Shared/EntryPointUtilities/Cocoa/Daemon/PCMDaemonEntryPoint.mm:
(WebKit::PCMDaemonMain):
Identifier: 301765.433@safari-7623-branch
(cherry picked from commit 22d708a2fd385c9649f4d2f1f96a1e2f76070649)
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.470@webkitglib/2.50
Commit: 45ad4bc261feb61fb1bd54dde311e0fb7921e41d
https://github.com/WebKit/WebKit/commit/45ad4bc261feb61fb1bd54dde311e0fb7921e41d
Author: Yusuke Suzuki <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
M Source/JavaScriptCore/assembler/MacroAssemblerX86_64.h
M Source/JavaScriptCore/assembler/X86Assembler.h
M Source/JavaScriptCore/assembler/testmasm.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
Log Message:
-----------
Cherry-pick 305087@main (2fe3a6e9c518).
https://bugs.webkit.org/show_bug.cgi?id=304897
[JSC] Allow same registers for src and dst in
MacroAssemblerX86_64::negateDouble / negateFloat
https://bugs.webkit.org/show_bug.cgi?id=304897
rdar://167491947
Reviewed by Sosuke Suzuki.
Relax X86_64's negateDouble / negateFloat invariants. loadDouble /
loadFloat are already using scratchRegister() so it is still requiring
scratchRegister(), but by using _mr variant, we can avoid
`ASSEERT(src != dst)` restriction. This simplifies BBQ implementations.
Test: Source/JavaScriptCore/assembler/testmasm.cpp
* Source/JavaScriptCore/assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::negateDouble):
(JSC::MacroAssemblerX86_64::negateFloat):
* Source/JavaScriptCore/assembler/X86Assembler.h:
(JSC::X86Assembler::xorps_mr):
(JSC::X86Assembler::xorpd_mr):
(JSC::X86Assembler::vxorps_mrr):
(JSC::X86Assembler::vxorpd_mrr):
* Source/JavaScriptCore/assembler/testmasm.cpp:
(floatOperands):
(JSC::testNegateDouble):
(JSC::testNegateFloat):
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addF32Neg):
(JSC::Wasm::BBQJITImpl::BBQJIT::addF64Neg):
Canonical link: https://commits.webkit.org/305087@main
Canonical link: https://commits.webkit.org/298234.471@webkitglib/2.50
Commit: 6c99c16e79ed9823b8419a5e190952653e396aa2
https://github.com/WebKit/WebKit/commit/6c99c16e79ed9823b8419a5e190952653e396aa2
Author: Yusuke Suzuki <[email protected]>
Date: 2026-03-03 (Tue, 03 Mar 2026)
Changed paths:
A JSTests/stress/stack-overflow-llint-large-params-and-large-locals.js
M Source/JavaScriptCore/llint/LLIntSlowPaths.cpp
M Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm
M Source/JavaScriptCore/llint/LowLevelInterpreter64.asm
Log Message:
-----------
Cherry-pick 301765.393@safari-7623-branch (a0aac3a0fa8f).
https://bugs.webkit.org/show_bug.cgi?id=304973
[JSC] LLInt arity fix needs to be done against sp
https://bugs.webkit.org/show_bug.cgi?id=304973
rdar://167110398
Reviewed by Yijia Huang.
When performing LLInt arity fixup, it is done after checking local
frame's adjustment. This means that we should do stack overflow check
with `newlyAddedSlots + sp` with soft-stack-limit instead of
`newlyAddedSlots + cfr`.
Note that JIT code is doing the right things already.
Test: JSTests/stress/stack-overflow-llint-large-params-and-large-locals.js
* JSTests/stress/stack-overflow-llint-large-params-and-large-locals.js:
Added.
(shouldThrow):
* Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:
(JSC::LLInt::arityCheckFor):
* Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm:
* Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:
Identifier: 301765.393@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.472@webkitglib/2.50
Compare: https://github.com/WebKit/WebKit/compare/e8cd0f61201f...6c99c16e79ed
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
