Branch: refs/heads/webkitglib/2.48
Home: https://github.com/WebKit/WebKit
Commit: ee39f2c4db0681ff930160bc0dd41a6ebfdcbe84
https://github.com/WebKit/WebKit/commit/ee39f2c4db0681ff930160bc0dd41a6ebfdcbe84
Author: Frédéric Wang <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A LayoutTests/fast/grid/layout-positioned-grid-items-001-crash-expected.txt
A LayoutTests/fast/grid/layout-positioned-grid-items-001-crash.html
A LayoutTests/fast/grid/layout-positioned-grid-items-002-crash-expected.txt
A LayoutTests/fast/grid/layout-positioned-grid-items-002-crash.html
A LayoutTests/fast/grid/layout-positioned-grid-items-003-crash-expected.txt
A LayoutTests/fast/grid/layout-positioned-grid-items-003-crash.html
Log Message:
-----------
Cherry-pick 292955.2@webkit-embargoed (56e799de94f9).
https://bugs.webkit.org/show_bug.cgi?id=287481
Add non-regression tests for bugs 287481, 287482 and 287483.
https://bugs.webkit.org/show_bug.cgi?id=287481
Reviewed by Alan Baradlay.
This adds reduction of test cases for bugs reported by fuzzers:
- bug 287482 and bug 287483, fixed by https://commits.webkit.org/289863@main
- bug 287481, fixed by https://commits.webkit.org/290546@main.
*
LayoutTests/fast/grid/layout-positioned-grid-items-001-crash-expected.txt:
Added.
* LayoutTests/fast/grid/layout-positioned-grid-items-001-crash.html: Added.
Reduced from test case of bug 287481.
* LayoutTests/fast/grid/layout-positioned-grid-items-002-crash.html: Added.
Reduced from test case of bug 287483.
* LayoutTests/fast/grid/layout-positioned-grid-items-003-crash.html: Added.
Reduced from test case of bug 287482.
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.436@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.289@webkitglib/2.48
Commit: 5494f8f5bbfdf2eedb19d0d672eca2c87f4195a3
https://github.com/WebKit/WebKit/commit/5494f8f5bbfdf2eedb19d0d672eca2c87f4195a3
Author: Rob Buis <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A LayoutTests/editing/deleting/delete-multiple-styling-elements-expected.txt
A LayoutTests/editing/deleting/delete-multiple-styling-elements.html
M Source/WebCore/editing/DeleteSelectionCommand.cpp
Log Message:
-----------
Cherry-pick 292955.4@webkit-embargoed (55ed8716be7f).
https://bugs.webkit.org/show_bug.cgi?id=289378
stack-overflow | WebCore::Calculation::copy; WebCore::Calculation::copy;
WebCore::Calculation::copy
https://bugs.webkit.org/show_bug.cgi?id=289378
rdar://144403520
Reviewed by Ryosuke Niwa.
The node loop in
makeStylingElementsDirectChildrenOfEditableRootToPreventStyleLoss can change
the DOM, so
split it up in two parts.
*
LayoutTests/editing/deleting/delete-multiple-styling-elements-expected.txt:
Added.
* LayoutTests/editing/deleting/delete-multiple-styling-elements.html: Added.
* Source/WebCore/editing/DeleteSelectionCommand.cpp:
(WebCore::DeleteSelectionCommand::makeStylingElementsDirectChildrenOfEditableRootToPreventStyleLoss):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.440@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.290@webkitglib/2.48
Commit: 814e2d70e60538e1a3e43a9b80592f076686ff8a
https://github.com/WebKit/WebKit/commit/814e2d70e60538e1a3e43a9b80592f076686ff8a
Author: Yusuke Suzuki <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/stress/variable-initialization-error-check.js
M Source/JavaScriptCore/interpreter/Interpreter.cpp
M Source/JavaScriptCore/runtime/JSGlobalObject.cpp
M Source/JavaScriptCore/runtime/JSGlobalObjectInlines.h
M Source/JavaScriptCore/runtime/JSModuleNamespaceObject.cpp
M Source/JavaScriptCore/runtime/JSObject.cpp
M Source/JavaScriptCore/runtime/JSTemplateObjectDescriptor.cpp
M Source/JavaScriptCore/runtime/ObjectPrototype.cpp
M Source/JavaScriptCore/runtime/ProgramExecutable.cpp
Log Message:
-----------
Cherry-pick 289651.444@safari-7621-branch (b850d2257e8d).
https://bugs.webkit.org/show_bug.cgi?id=291747
[JSC] ASSERTION FAILED: Unexpected exception observed on thread Thread
https://bugs.webkit.org/show_bug.cgi?id=291747
rdar://149546774
Reviewed by Yijia Huang.
Many of operations (e.g. JSObject::put with stack overflow detection)
can throw random errors. Thus, let's use RETURN_IF_EXCEPTION more
instead of assertNoExceptionExceptTermination.
* JSTests/stress/variable-initialization-error-check.js: Added.
(C0):
* Source/JavaScriptCore/interpreter/Interpreter.cpp:
(JSC::Interpreter::executeEval):
* Source/JavaScriptCore/runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::canDeclareGlobalFunction):
(JSC::JSGlobalObject::createGlobalFunctionBinding):
* Source/JavaScriptCore/runtime/JSGlobalObjectInlines.h:
(JSC::JSGlobalObject::createGlobalVarBinding):
* Source/JavaScriptCore/runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
* Source/JavaScriptCore/runtime/JSObject.cpp:
(JSC::JSObject::ordinaryToPrimitive const):
(JSC::JSObject::getOwnNonIndexPropertyNames):
* Source/JavaScriptCore/runtime/JSTemplateObjectDescriptor.cpp:
(JSC::JSTemplateObjectDescriptor::createTemplateObject):
* Source/JavaScriptCore/runtime/ObjectPrototype.cpp:
(JSC::objectPrototypeHasOwnProperty):
* Source/JavaScriptCore/runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
Canonical link: https://commits.webkit.org/289651.444@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.291@webkitglib/2.48
Commit: 2cf6496234f4df914780c87e3c94da45990f2ece
https://github.com/WebKit/WebKit/commit/2cf6496234f4df914780c87e3c94da45990f2ece
Author: Rob Buis <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A
LayoutTests/fast/multicol/video-not-removed-from-fragmented-flow-crash-expected.txt
A
LayoutTests/fast/multicol/video-not-removed-from-fragmented-flow-crash.html
M Source/WebCore/rendering/RenderElement.cpp
Log Message:
-----------
Cherry-pick 292955.3@webkit-embargoed (19b66665ae74).
https://bugs.webkit.org/show_bug.cgi?id=288447
ASAN_TRAP | WebCore::RenderFragmentedFlow::removeRenderBoxFragmentInfo;
WebCore::RenderFragmentedFlow::removeFlowChildInfo;
WebCore::RenderElement::removeFromRenderFragmentedFlowIncludingDescendants
https://bugs.webkit.org/show_bug.cgi?id=288447
Reviewed by Alan Baradlay.
In the test case the video element is added to a fragmented flow, but is
not properly removed
when it becomes out of flow due to the popover attribute. The logic in
RenderElement::adjustFragmentedFlowStateOnContainingBlockChangeIfNeeded
will not work for this kind of element since the fragmened flow container
information is not known anymore, the video having become a top-level element.
To properly remove renderers from their fragmented flow, detect this
situation in RenderElement::styleWillChange, and use the fragmented flow access
(through locateEnclosingFragmentedFlow())
before the containing block is changed.
*
LayoutTests/fast/multicol/video-not-removed-from-fragmented-flow-crash-expected.txt:
Added.
*
LayoutTests/fast/multicol/video-not-removed-from-fragmented-flow-crash.html:
Added.
* Source/WebCore/rendering/RenderElement.cpp:
(WebCore::RenderElement::styleWillChange):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.469@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.292@webkitglib/2.48
Commit: 00dba2cecbf6c651457ceea33ea51e4e89b27957
https://github.com/WebKit/WebKit/commit/00dba2cecbf6c651457ceea33ea51e4e89b27957
Author: Ryosuke Niwa <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/WebCore/Modules/encryptedmedia/NavigatorEME.cpp
M
Source/WebCore/SaferCPPExpectations/UncountedLambdaCapturesCheckerExpectations
Log Message:
-----------
Cherry-pick 289651.470@safari-7621-branch (6d042697c796).
https://bugs.webkit.org/show_bug.cgi?id=292304
Use-after-free of Document in MediaKeySystemAccess::MediaKeySystemAccess
via tryNextSupportedConfiguration
https://bugs.webkit.org/show_bug.cgi?id=292304
rdar://145888476
Reviewed by Eric Carlson and Brent Fulgham.
tryNextSupportedConfiguration should store Document in WeakPtr instead of a
raw reference to avoid accessing a dead document.
* Source/WebCore/Modules/encryptedmedia/NavigatorEME.cpp:
(WebCore::tryNextSupportedConfiguration):
*
Source/WebCore/SaferCPPExpectations/UncountedLambdaCapturesCheckerExpectations:
Canonical link: https://commits.webkit.org/289651.470@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.293@webkitglib/2.48
Commit: b5e344ec31f9a99557a3c0bf2f64f84c49f797a0
https://github.com/WebKit/WebKit/commit/b5e344ec31f9a99557a3c0bf2f64f84c49f797a0
Author: Rob Buis <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A
LayoutTests/fast/multicol/null-enclosing-fragmented-flow-crash-expected.txt
A LayoutTests/fast/multicol/null-enclosing-fragmented-flow-crash.html
M Source/WebCore/rendering/RenderBlock.cpp
Log Message:
-----------
Cherry-pick [email protected] (65ae446abd0b).
https://bugs.webkit.org/show_bug.cgi?id=289389
ASAN_TRAP | WebCore::RenderFragmentedFlow::setFragmentRangeForBox;
WebCore::RenderBlockFlow::layoutBlockChild;
WebCore::RenderBlockFlow::layoutBlockChildren
https://bugs.webkit.org/show_bug.cgi?id=289389
Reviewed by Alan Baradlay.
The method updateCachedEnclosingFragmentedFlow can be called with a null
value for the fragmentedFlow
parameter while the render tree is not fully built yet, leading to possible
assertion failures later.
To fix this, do not cache null values for the enclosing fragmented flow and
instead make sure the enclosing
fragmented flow is set to null.
*
LayoutTests/fast/multicol/null-enclosing-fragmented-flow-crash-expected.txt:
Added.
* LayoutTests/fast/multicol/null-enclosing-fragmented-flow-crash.html:
Added.
* Source/WebCore/rendering/RenderBlock.cpp:
(WebCore::RenderBlock::updateCachedEnclosingFragmentedFlow const):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.471@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.294@webkitglib/2.48
Commit: 2abe3eaa5c0f01418585afb2e73ad877cecfb92b
https://github.com/WebKit/WebKit/commit/2abe3eaa5c0f01418585afb2e73ad877cecfb92b
Author: Michael Saboff <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M JSTests/stress/regexp-lookbehind.js
M Source/JavaScriptCore/yarr/YarrPattern.cpp
Log Message:
-----------
Cherry-pick 289651.472@safari-7621-branch (3665da825356).
https://bugs.webkit.org/show_bug.cgi?id=292305
[JSC] [e72bdd394922cc4a] ASAN_ILL |
Yarr::YarrPatternConstructor::quantifyAtom; Yarr::Parser::parseTokens;
JSC::Yarr::parse
https://bugs.webkit.org/show_bug.cgi?id=292305
rdar://149760394
Reviewed by Daniel Liu.
We were inadvertently creating ForwardReference atoms when we should have
been creating
BackReference atoms. This is because we would create a ForwardReference
when the referenced
subpatternId was equal to the value of a parenthesis' subpatternId, but
that is a valid
BackReference. The code in question made a >= comparison, but the greater
than case was
already handled prior to the code that this change removes.
Added some new regression test cases.
* JSTests/stress/regexp-lookbehind.js:
* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::atomBackReference):
(JSC::Yarr::YarrPatternConstructor::atomNamedBackReference):
Canonical link: https://commits.webkit.org/289651.472@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.295@webkitglib/2.48
Commit: 9f9e34faf13406d9d42d76fb6de4c0857fc1e454
https://github.com/WebKit/WebKit/commit/9f9e34faf13406d9d42d76fb6de4c0857fc1e454
Author: Matt Woodrow <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/Document.h
M Source/WebCore/dom/ViewTransition.cpp
Log Message:
-----------
Cherry-pick 289651.473@safari-7621-branch (927a0bf9a118).
https://bugs.webkit.org/show_bug.cgi?id=292314
heap-use-after-free | WebCore::forEachRendererInPaintOrder inside
ViewTransition::captureNewState.
https://bugs.webkit.org/show_bug.cgi?id=292314
<rdar://149686168>
Reviewed by Alan Baradlay.
captureNewStyle flushes style before iterating RenderLayer z-order lists and
reading style properties.
This calls into the ComputedStyleExtractor, which can call
updateLayoutIgnorePendingStylesheets which can do new style work that wasn't
captured in the previous flush (pending stylesheets, and content-visibility
relevancy).
This extra style flush can mutate renderers and invalidate the z-order lists
that are currently being iterated.
Adds a new helper updateStyleIfNeededIgnorePendingStylesheets, and use it
from
view-transitions, since we need the same level of flushing as inside the
iteration.
Also removes the updateLayout call from
Document::updateRelevancyOfContentVisibilityElements() since all existing
callers already flush layout directly after the call, except for the new
instance added in this patch (which doesn't want/need layout flushed).
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::updateStyleIfNeededIgnoringPendingStylesheets):
(WebCore::Document::updateRelevancyOfContentVisibilityElements):
* Source/WebCore/dom/Document.h:
* Source/WebCore/dom/ViewTransition.cpp:
(WebCore::forEachRendererInPaintOrder):
(WebCore::ViewTransition::captureOldState):
(WebCore::ViewTransition::activateViewTransition):
(WebCore::ViewTransition::updatePseudoElementRenderers):
Canonical link: https://commits.webkit.org/289651.473@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.296@webkitglib/2.48
Commit: afb2fbacfbbc2ac3a86c20f22aa36780a2994784
https://github.com/WebKit/WebKit/commit/afb2fbacfbbc2ac3a86c20f22aa36780a2994784
Author: Matthew Finkel <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M LayoutTests/http/tests/cookies/resources/setCookies.cgi
A
LayoutTests/http/tests/navigation/ping-attribute/cross-site-url-anchor-cookie-expected.txt
A
LayoutTests/http/tests/navigation/ping-attribute/cross-site-url-anchor-cookie-preexisting-cookie-expected.txt
A
LayoutTests/http/tests/navigation/ping-attribute/cross-site-url-anchor-cookie-preexisting-cookie.html
A
LayoutTests/http/tests/navigation/ping-attribute/cross-site-url-anchor-cookie.html
A
LayoutTests/http/tests/resourceLoadStatistics/only-partitioned-cookies-after-redirect-expected.txt
A
LayoutTests/http/tests/resourceLoadStatistics/only-partitioned-cookies-after-redirect.html
A
LayoutTests/http/tests/websocket/tests/hybi/websocket-allowed-setting-cookie-as-third-party-with-third-party-cookie-blocking.https-expected.txt
A
LayoutTests/http/tests/websocket/tests/hybi/websocket-allowed-setting-cookie-as-third-party-with-third-party-cookie-blocking.https.html
A
LayoutTests/http/tests/workers/service/basic-install-event-sw-fetch-third-party-expected.txt
A
LayoutTests/http/tests/workers/service/basic-install-event-sw-fetch-third-party.html
A
LayoutTests/http/tests/workers/service/resources/basic-install-event-waitUntil-resolve-worker-then-fetch.js
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
M Tools/TestWebKitAPI/Tests/WebKitCocoa/ResourceLoadStatistics.mm
Log Message:
-----------
Cherry-pick 289651.478@safari-7621-branch (ce0222098a20).
https://bugs.webkit.org/show_bug.cgi?id=292371
[cocoa] Disable CHIPS
https://bugs.webkit.org/show_bug.cgi?id=292371
rdar://149535707
Reviewed by Alex Christensen and Wenson Hsieh.
Before 288413@main, Apple platforms blocked all third-party cookies by
default.
In that commit, we enabled CHIPS (opt-in partitioned cookies), and that
required allowing partitioned third-party cookies while rejecting
unpartitioned
cookies. The mechanism for rejecting unpartitioned third-party cookies is
incomplete,
so this change disables CHIPS and returns to the previous shipping behavior.
We may land a different fix later or fix this in an underlying framework.
Adding some new tests that cover setting cross-site cookies in various
situations.
* LayoutTests/http/tests/cookies/resources/setCookies.cgi:
*
LayoutTests/http/tests/navigation/ping-attribute/cross-site-url-anchor-cookie-expected.txt:
Added.
*
LayoutTests/http/tests/navigation/ping-attribute/cross-site-url-anchor-cookie-preexisting-cookie-expected.txt:
Added.
*
LayoutTests/http/tests/navigation/ping-attribute/cross-site-url-anchor-cookie-preexisting-cookie.html:
Added.
*
LayoutTests/http/tests/navigation/ping-attribute/cross-site-url-anchor-cookie.html:
Added.
*
LayoutTests/http/tests/resourceLoadStatistics/only-partitioned-cookies-after-redirect-expected.txt:
Added.
*
LayoutTests/http/tests/resourceLoadStatistics/only-partitioned-cookies-after-redirect.html:
Added.
*
LayoutTests/http/tests/websocket/tests/hybi/websocket-allowed-setting-cookie-as-third-party-with-third-party-cookie-blocking.https-expected.txt:
Added.
*
LayoutTests/http/tests/websocket/tests/hybi/websocket-allowed-setting-cookie-as-third-party-with-third-party-cookie-blocking.https.html:
Added.
*
LayoutTests/http/tests/workers/service/basic-install-event-sw-fetch-third-party-expected.txt:
Added.
*
LayoutTests/http/tests/workers/service/basic-install-event-sw-fetch-third-party.html:
Added.
*
LayoutTests/http/tests/workers/service/resources/basic-install-event-waitUntil-resolve-worker-then-fetch.js:
Added.
(event.event.waitUntil.new.Promise):
(event.then.r.r.text.then):
* LayoutTests/platform/mac-wk1/TestExpectations:
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/ResourceLoadStatistics.mm:
(TEST(ResourceLoadStatistics, BlockUnpartitionedThirdPartyCookies)):
(TEST(ResourceLoadStatistics,
BlockUnpartitionedAndAllowPartitionedThirdPartyCookies)):
Canonical link: https://commits.webkit.org/289651.478@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.297@webkitglib/2.48
Commit: 665db4e9754f2e3bc7aa577b948225c5c84424c7
https://github.com/WebKit/WebKit/commit/665db4e9754f2e3bc7aa577b948225c5c84424c7
Author: Keith Miller <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/stress/osr-availability-heap-materialization-clobbered.js
M Source/JavaScriptCore/dfg/DFGAvailabilityMap.cpp
M Source/JavaScriptCore/dfg/DFGAvailabilityMap.h
M Source/JavaScriptCore/dfg/DFGOSRAvailabilityAnalysisPhase.cpp
M Source/JavaScriptCore/dfg/DFGPutStackSinkingPhase.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
M Source/JavaScriptCore/ftl/FTLOSRExitCompiler.cpp
Log Message:
-----------
Cherry-pick 289651.482@safari-7621-branch (662148187562).
https://bugs.webkit.org/show_bug.cgi?id=291742
[JSC]ASSERTION FAILED: from.isCell() at jsCast
https://bugs.webkit.org/show_bug.cgi?id=291742
rdar://149546133
Reviewed by Yusuke Suzuki.
OSRAvailabilityAnalysisPhase needs to update the Availability in the heap
when a local on
the stack gets clobbered. If we don't then when materializing an object for
OSR we could
read a random value (possibly in a different format, although I'm not 100%
sure) for a
type confusion. ArgumentsEliminationPhase only does `computeInterference`
at the head of
each block. This sorta works because in most cases if a PutStack will
clobber the recovery
value then we'll end up escaping the candidate. Unfortunately, with the
previous rules
this was both overly conservative and too weak. Too weak because we could
clobber the
necassary local without updating Availability so we'd use the wrong value
(this bug).
Too conservative because the value could still be recoverable via SSA (not
fixed here).
* Source/JavaScriptCore/dfg/DFGAvailabilityMap.cpp:
(JSC::DFG::AvailabilityMap::filterByLiveness):
(JSC::DFG::AvailabilityMap::pruneByLiveness):
Add a filterByLiveness that non-destructively returns an
AvailabilityMap and use that
to implement pruneByLiveness as that's effectively what pruneByLiveness
already does.
(JSC::DFG::AvailabilityMap::validateAvailability const):
Add extra validation for OSR exit availability. The new checks ensure
the local's
perspective on what's available matches what a materialization in the
heap would
see too. This validation finds the bug in the test case without
requiring an assert
* Source/JavaScriptCore/dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
Handle clobbers of the Availability for a local by walking the heap and
looking for
any materializations that are relying on the same machine local as the
one we're
clobbering. This is O(n) but that's probably fine since the
materialization heap
tends to be small.
Canonical link: https://commits.webkit.org/289651.482@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.298@webkitglib/2.48
Commit: cabb61ad4e540c21236c9d17d20257f04bed7362
https://github.com/WebKit/WebKit/commit/cabb61ad4e540c21236c9d17d20257f04bed7362
Author: Vassili Bykov <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/JavaScriptCore/wasm/WasmOperations.cpp
Log Message:
-----------
Cherry-pick 289651.501@safari-7621-branch (8ba9671cffb6).
https://bugs.webkit.org/show_bug.cgi?id=292705
operationJSToWasmEntryWrapperBuildReturnFrame may return early without
fully initializing an array created by tryCreateUninitializedRestricted
https://bugs.webkit.org/show_bug.cgi?id=292705
rdar://150360109
Reviewed by Daniel Liu and Yusuke Suzuki.
The two places where the function exits on an exception are now changed to
first call a function
that will initialize the remained of the array with jsUndefined.
Canonical link: https://commits.webkit.org/289651.501@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.299@webkitglib/2.48
Commit: d382a54153f7149c5b711d2c42b8b7d2fbf8a502
https://github.com/WebKit/WebKit/commit/d382a54153f7149c5b711d2c42b8b7d2fbf8a502
Author: Yusuke Suzuki <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/wasm/stress/js-to-wasm-stackoverflow.js
M Source/JavaScriptCore/llint/WebAssembly.asm
M Source/JavaScriptCore/wasm/js/JSToWasm.cpp
Log Message:
-----------
Cherry-pick 289651.503@safari-7621-branch (e473f4ac0618).
https://bugs.webkit.org/show_bug.cgi?id=292593
Segmentation fault in JSC with testcase with Wasm SIMD instructions
https://bugs.webkit.org/show_bug.cgi?id=292593
rdar://150748445
Reviewed by Keith Miller and Daniel Liu.
When using throwing-from-wasm,
1. Callee needs to be wasm callee. In this case, we should store
JSEntrypointCallee.
2. We should not restore callee saves. By setting (1), unwinding will do
that for us by using JSEntrypointCallee's callee save information.
* JSTests/wasm/stress/js-to-wasm-stackoverflow.js: Added.
(F1):
* Source/JavaScriptCore/llint/WebAssembly.asm:
* Source/JavaScriptCore/wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmJITShared):
Canonical link: https://commits.webkit.org/289651.503@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.300@webkitglib/2.48
Commit: 9d0c0c481ae8455471240e1da7dd7e9b48ba063b
https://github.com/WebKit/WebKit/commit/9d0c0c481ae8455471240e1da7dd7e9b48ba063b
Author: Said Abou-Hallawa <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
Log Message:
-----------
Cherry-pick 289651.506@safari-7621-branch (52c2c7d983e0).
https://bugs.webkit.org/show_bug.cgi?id=292809
Validate ShareableBitmapConfiguration fields when sending it over IPC
https://bugs.webkit.org/show_bug.cgi?id=292809
rdar://150772440
Reviewed by Anne van Kesteren.
bytesPerPixel, bytesPerRow and bitmapInfo of ShareableBitmapConfiguration
have
to be checked and validated. Otherwise a buffer overflow can happen when
reading
the pixels of the image.
1. bytesPerPixel should be between 1 and 8 inclusive.
2. bytesPerRow depends on the width of the image and bytesPerPixel.
3. bitmapInfo is unsigned but there should not be any bit set outside the
CGBitmapInfo masks.
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Canonical link: https://commits.webkit.org/289651.506@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.301@webkitglib/2.48
Commit: 05ed7761b0ac09390d7f8b6fcbf3cecddf44f597
https://github.com/WebKit/WebKit/commit/05ed7761b0ac09390d7f8b6fcbf3cecddf44f597
Author: Yijia Huang <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/stress/instanceof-get-by-status-for-prototype-from-llint.js
M Source/JavaScriptCore/bytecode/GetByStatus.cpp
Log Message:
-----------
Cherry-pick 289651.507@safari-7621-branch (d318c79f1dca).
https://bugs.webkit.org/show_bug.cgi?id=292886
[JSC] Fix incorrect identifier in GetByStatus for fused instanceof
https://bugs.webkit.org/show_bug.cgi?id=292886
rdar://151178966
Reviewed by Yusuke Suzuki.
The fused instanceof bytecode uses GetByStatus to optimize property access
for prototype lookup. Previously, it incorrectly mapped the getPrototype
checkpoint to the "value" property instead of "prototype". This patch
corrects
the identifier to vm.propertyNames->prototype.
* JSTests/stress/instanceof-get-by-status-for-prototype-from-llint.js:
Added.
(mod6):
(require_x_is_array.__commonJS.):
(__copyProps.get return):
(__copyProps):
* Source/JavaScriptCore/bytecode/GetByStatus.cpp:
(JSC::GetByStatus::computeFromLLInt):
Canonical link: https://commits.webkit.org/289651.507@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.302@webkitglib/2.48
Commit: e2a5100f8e69f0aea56cb66254b9495688d114c4
https://github.com/WebKit/WebKit/commit/e2a5100f8e69f0aea56cb66254b9495688d114c4
Author: Daniel Liu <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 289651.508@safari-7621-branch (21c2ff503451).
https://bugs.webkit.org/show_bug.cgi?id=292783
Fix more missing exception checks in SerializedScriptValue
https://bugs.webkit.org/show_bug.cgi?id=292783
rdar://150766136
Reviewed by Yusuke Suzuki.
The deserializer fuzzer has found more missing exception checks.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::startVisitNamedMember):
(WebCore::CloneDeserializer::objectEndVisitNamedMember):
(WebCore::CloneDeserializer::deserialize):
(WebCore::SerializedScriptValue::deserialize):
Canonical link: https://commits.webkit.org/289651.508@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.303@webkitglib/2.48
Commit: cd57c6e00fe3957bd930bddc0db277fb20fb83ec
https://github.com/WebKit/WebKit/commit/cd57c6e00fe3957bd930bddc0db277fb20fb83ec
Author: Vassili Bykov <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/wasm/stress/wasm-try-table-catching-backwards.js
M Source/JavaScriptCore/llint/InPlaceInterpreter64.asm
M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp
M Source/JavaScriptCore/wasm/WasmIPIntGenerator.h
Log Message:
-----------
Cherry-pick 289651.509@safari-7621-branch (e5dbc8e03d41).
https://bugs.webkit.org/show_bug.cgi?id=292599
Segmentation fault in JSC coming from throwWasmToJSException
https://bugs.webkit.org/show_bug.cgi?id=292599
rdar://150752978
Reviewed by Daniel Liu and Yusuke Suzuki.
The failure is triggered by the fact that in the Wasm code `$label0` comes
before the `try_table`
that uses it as a catch label. A test case with a less random and verbose
example reproducing the
issue is included in the patch. The "normal" expected behavior for the
example in the bug report is
to loop infinitely.
The `call` instruction inside the `try_table` block throws an exception on
return because `f0` (a JS
function) returned by the call can't be marshaled into a `funcref` required
by the import signature.
The control transfer on a caught exception is implemented as a "ghost"
`block` instruction, which is
to say that there is no actual `block` instruction in the code, but the
exception logic jumps to the
`block` instruction handler while `PC` is pointing at the `try_table` and
`MC` at a `BlockMetadata`
structure embedded in the `try_table` metadata block. The deltas in the
metadata are negative
because control is transferred to `$label0` located earlier in the code.
The problem is that the deltas are 32-bit values loaded into `w0` and `w1`.
The values are then not
sign-extended to the full 64-bit width before being added to `PC` and `MC`
as `x0` and `x1`. As a
result, they work as very large positive values and make `PC` and `MC`
point at random data. That
explains the randomness of failure modes. If `PC` happens to point at a
zero byte, the byte works as
an `unreachable` instruction, causing an exception exit. Other values are
treated as random
instructions with random metadata, typically triggering a segfault.
The patch changes the implementation of `block` to sign-extend the deltas.
As far as I understand
them, other instructions using `BlockMetadata` deltas only ever skip
forward and never require sign
extension, but I added comments to make that assumption explicit. I also
changed the type of
`BlockMetadata` fields to `int32_t` to raise awareness of their nature.
Canonical link: https://commits.webkit.org/289651.509@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.304@webkitglib/2.48
Commit: 709ef864ee027a5e0046e034fb89a9043ab205b3
https://github.com/WebKit/WebKit/commit/709ef864ee027a5e0046e034fb89a9043ab205b3
Author: Daniel Liu <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/stress/dataview-byte-length-large-array-oob-baseline.js
A JSTests/stress/dataview-byte-length-large-array-oob.js
A JSTests/stress/dataview-byte-length-large-array.js
A JSTests/stress/dataview-byte-length-small-array-oob-baseline.js
A JSTests/stress/dataview-byte-length-small-array-oob.js
A JSTests/stress/dataview-byte-length-small-array.js
Log Message:
-----------
Cherry-pick 289651.510@safari-7621-branch (bbc109eacd71).
https://bugs.webkit.org/show_bug.cgi?id=291852
dataview-byte-length tests always fail because of testLoopCount
https://bugs.webkit.org/show_bug.cgi?id=292949#
rdar://151246567
Reviewed by Mark Lam and Yusuke Suzuki.
These tests use `testLoopCount` without initializing it, meaning that we
will
always end up failing these tests because of an uninitialized variable.
These
tests should be passing.
* JSTests/stress/dataview-byte-length-large-array-oob.js:
* JSTests/stress/dataview-byte-length-large-array.js:
* JSTests/stress/dataview-byte-length-small-array-oob.js:
* JSTests/stress/dataview-byte-length-small-array.js:
Canonical link: https://commits.webkit.org/289651.510@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.305@webkitglib/2.48
Commit: a05d5453cd59f0b5909e91147cf16b37d5023779
https://github.com/WebKit/WebKit/commit/a05d5453cd59f0b5909e91147cf16b37d5023779
Author: Youenn Fablet <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp8/vp8_cx_iface.c
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vpx/src/vpx_encoder.c
Log Message:
-----------
Cherry-pick 289651.513@safari-7621-branch (ad4ded681458).
https://bugs.webkit.org/show_bug.cgi?id=291852
vpx_codec_enc_init_multi: fix double free on init failure
rdar://150500959
Reviewed by Jean-Yves Avenard.
Cherry-picking of
https://github.com/webmproject/libvpx/commit/1c758781c428c0e895645b95b8ff1512b6bdcecb
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp8/vp8_cx_iface.c:
(vp8e_init):
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vpx/src/vpx_encoder.c:
(vpx_codec_enc_init_multi_ver):
Canonical link: https://commits.webkit.org/289651.513@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.306@webkitglib/2.48
Commit: 7763ff6131e20ef66f3257fb372294356668d178
https://github.com/WebKit/WebKit/commit/7763ff6131e20ef66f3257fb372294356668d178
Author: Claudio Saavedra <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M JSTests/stress/regress-185888.js
M JSTests/stress/string-16bit-repeat-overflow.js
M LayoutTests/js/throw-large-string-oom-expected.txt
M LayoutTests/js/throw-large-string-oom.html
M Source/WTF/wtf/text/StringImpl.h
Log Message:
-----------
Cherry-pick [email protected] (aeed21455d86).
https://bugs.webkit.org/show_bug.cgi?id=288439
ASAN_TRAP | WTF::String::utf8; WTR::TestInvocation::dumpResults;
WTR::TestInvocation::invoke
https://bugs.webkit.org/show_bug.cgi?id=288439
Reviewed by Darin Adler.
Both StringImpl::tryGetUTF8ForCharacters() methods are incorrectly setting
a limit
to the size of the vector to be used for the UTF-8 conversion to a fraction
StringImpl::MaxLength, which can cause a valid string not to be converted
succesfully
if it's long enough. The purpose of this check should be to prevent overflow
when calculating the size of the vector, so a better approach is to use
checked
arithmetic to keep the size within boundaries in a cleaner way.
Some JS tests that rely on overflowing are updated to reflect the change,
as the
sizes used in the tests shouldn't really overflow once this is corrected,
so use
larger strings instead.
* JSTests/stress/regress-185888.js:
* JSTests/stress/string-16bit-repeat-overflow.js:
* LayoutTests/js/throw-large-string-oom-expected.txt:
* LayoutTests/js/throw-large-string-oom.html:
* Source/WTF/wtf/text/StringImpl.h:
(WTF::StringImpl::tryGetUTF8ForCharacters):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.521@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.307@webkitglib/2.48
Commit: b2076482bd419cecb4027e6785e4a17bcfacac22
https://github.com/WebKit/WebKit/commit/b2076482bd419cecb4027e6785e4a17bcfacac22
Author: Rob Buis <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A LayoutTests/fast/canvas/offscreen-no-script-context-crash-expected.txt
A LayoutTests/fast/canvas/offscreen-no-script-context-crash.html
M LayoutTests/platform/mac-wk1/TestExpectations
M Source/WebCore/html/CanvasBase.cpp
M Source/WebCore/html/OffscreenCanvas.cpp
Log Message:
-----------
Cherry-pick [email protected] (44fc00a2610d).
https://bugs.webkit.org/show_bug.cgi?id=289380
ASAN_SEGV | WebCore::CanvasBase::setImageBuffer;
WebCore::OffscreenCanvas::setImageBufferAndMarkDirty;
WebCore::ImageBitmapRenderingContext::setBlank
https://bugs.webkit.org/show_bug.cgi?id=289380
Reviewed by Ryosuke Niwa.
The OffscreenCanvas DOM object can be detached from its script execution
context so
add checks to see if it is available.
* LayoutTests/fast/canvas/offscreen-no-script-context-crash-expected.txt:
Added.
* LayoutTests/fast/canvas/offscreen-no-script-context-crash.html: Added.
* LayoutTests/platform/mac-wk1/TestExpectations:
* Source/WebCore/html/CanvasBase.cpp:
(WebCore::CanvasBase::setImageBuffer const):
* Source/WebCore/html/OffscreenCanvas.cpp:
(WebCore::OffscreenCanvas::scheduleCommitToPlaceholderCanvas):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.525@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.308@webkitglib/2.48
Commit: 199ec444d4e491baaaa66be41f7ceb972357b874
https://github.com/WebKit/WebKit/commit/199ec444d4e491baaaa66be41f7ceb972357b874
Author: Frédéric Wang <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A LayoutTests/fast/editing/insert-list-increasingly-deeper-item-expected.txt
A LayoutTests/fast/editing/insert-list-increasingly-deeper-item.html
A
LayoutTests/fast/editing/insert-list-keep-listifying-and-unlistifying-indefinitely-expected.txt
A
LayoutTests/fast/editing/insert-list-keep-listifying-and-unlistifying-indefinitely.html
M Source/WebCore/editing/InsertListCommand.cpp
Log Message:
-----------
Cherry-pick [email protected] (af0885753297).
https://bugs.webkit.org/show_bug.cgi?id=289376
Fix infinite loop in InsertListCommand::doApply().
https://bugs.webkit.org/show_bug.cgi?id=289376
Reviewed by Ryosuke Niwa.
In https://commits.webkit.org/293666@main, we worked around an infinite
loop in InsertListCommand::doApply() when the "current paragraph" does
not move forward, assuming the old "current paragraph" is still part
of the tree. This latter condition can fail if for example the editor
reformatted the old "current paragraph" and replaced it with a new
element. To be able to check the "current paragraph" does not get
blocked in that case, we instead rely on the position from which we
advanced to that "current paragraph". This allows to addres two cases:
- When we indefinitely listify/unlistify the current paragraph.
- When the indefinitely add new containers around the current paragraph
(leading to an arbitrary deep tree).
*
LayoutTests/fast/editing/insert-list-increasingly-deeper-item-expected.txt:
Added.
* LayoutTests/fast/editing/insert-list-increasingly-deeper-item.html: Added.
*
LayoutTests/fast/editing/insert-list-keep-listifying-and-unlistifying-indefinitely-expected.txt:
Added.
*
LayoutTests/fast/editing/insert-list-keep-listifying-and-unlistifying-indefinitely.html:
Added.
* Source/WebCore/editing/InsertListCommand.cpp:
(WebCore::InsertListCommand::doApply): Add an early return ; cherry-pick
changes from https://commits.webkit.org/293666@main
* LayoutTests/fast/ruby/crash-when-ruby-base-is-collapsed-expected.txt:
Cherry-pick changes from https://commits.webkit.org/293666@main
* LayoutTests/fast/text/selection-on-a-detached-tree-expected.txt: Ditto.
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.526@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.309@webkitglib/2.48
Commit: cb6fa3d43551bfed9ff543c7f80276a366176c1e
https://github.com/WebKit/WebKit/commit/cb6fa3d43551bfed9ff543c7f80276a366176c1e
Author: Rob Buis <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A LayoutTests/editing/execCommand/insert-ordered-list-crash3-expected.txt
A LayoutTests/editing/execCommand/insert-ordered-list-crash3.html
M Source/WebCore/editing/InsertListCommand.cpp
Log Message:
-----------
Cherry-pick 292955.9@webkit-embargoed (d77b797e1244).
https://bugs.webkit.org/show_bug.cgi?id=288446
stack-overflow | WebCore::RenderBox::contentBoxWidth;
WebCore::RenderBoxModelObject::paddingRight; WebCore::RenderBox::contentBoxWidth
https://bugs.webkit.org/show_bug.cgi?id=288446
Reviewed by Ryosuke Niwa.
The test case regressed with 257613@main. To fix this, revert to the old
behavior if the selection
starts and ends outside of the list.
* LayoutTests/editing/execCommand/insert-ordered-list-crash3-expected.txt:
Added.
* LayoutTests/editing/execCommand/insert-ordered-list-crash3.html: Added.
* Source/WebCore/editing/InsertListCommand.cpp:
(WebCore::InsertListCommand::doApplyForSingleParagraph):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.527@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.310@webkitglib/2.48
Commit: 9ac16018d788b5a0ced363523d56ff7ba3fdcc63
https://github.com/WebKit/WebKit/commit/9ac16018d788b5a0ced363523d56ff7ba3fdcc63
Author: Daniel Liu <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/wasm/stress/omg-tail-call-to-function-with-less-arguments.js
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
Log Message:
-----------
Cherry-pick 289651.530@safari-7621-branch (109e023e12d0).
https://bugs.webkit.org/show_bug.cgi?id=293197
OMG wasm->wasm calls need to restore stack pointer
https://bugs.webkit.org/show_bug.cgi?id=293197
rdar://151553598
Reviewed by Keith Miller.
During OMG, we may call a function which tail calls another function, thus
changing the stack pointer. When we return from the tail call, we won't be
in the same stack position, and thus need to restore it. We need to add in
the logic to restore the stack pointer based on the current frame size and
the value of fp.
* JSTests/wasm/stress/omg-tail-call-to-function-with-less-arguments.js:
Added.
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp:
(JSC::Wasm::OMGIRGenerator::addCall):
Canonical link: https://commits.webkit.org/289651.530@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.311@webkitglib/2.48
Commit: 3c66fd267d6a013987a4604130c5162f1cedf4e5
https://github.com/WebKit/WebKit/commit/3c66fd267d6a013987a4604130c5162f1cedf4e5
Author: Kimmo Kinnunen <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGL.cpp
M Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGL.h
M Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGL.messages.in
M
Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGLFunctionsGenerated.h
M Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp
M Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.h
M
Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxyFunctionsGenerated.cpp
M Tools/Scripts/generate-gpup-webgl
Log Message:
-----------
Cherry-pick 289651.532@safari-7621-branch (726be12b8c74).
https://bugs.webkit.org/show_bug.cgi?id=293116
RemoteGraphicsContextGL should copy GLenum arrays
https://bugs.webkit.org/show_bug.cgi?id=293116
rdar://148500598
Reviewed by Mike Wyrzykowski.
Move drawBuffers, drawBuffersEXT, invalidateFramebuffer,
invalidateSubFramebuffer, framebufferDiscard to manual functions and
copy the enum arrays to Vectors before calling into ANGLE.
* Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGL.cpp:
(WebKit::RemoteGraphicsContextGL::drawBuffers):
(WebKit::RemoteGraphicsContextGL::drawBuffersEXT):
(WebKit::RemoteGraphicsContextGL::invalidateFramebuffer):
(WebKit::RemoteGraphicsContextGL::invalidateSubFramebuffer):
(WebKit::RemoteGraphicsContextGL::framebufferDiscard):
* Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGL.h:
* Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGL.messages.in:
*
Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGLFunctionsGenerated.h:
(framebufferTextureLayer):
(drawRangeElements):
(getTranslatedShaderSourceANGLE):
(disableFoveation):
(invalidateFramebuffer): Deleted.
(invalidateSubFramebuffer): Deleted.
(drawBuffers): Deleted.
(drawBuffersEXT): Deleted.
(framebufferDiscard): Deleted.
* Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp:
(WebKit::RemoteGraphicsContextGLProxy::drawBuffers):
(WebKit::RemoteGraphicsContextGLProxy::drawBuffersEXT):
(WebKit::RemoteGraphicsContextGLProxy::invalidateFramebuffer):
(WebKit::RemoteGraphicsContextGLProxy::invalidateSubFramebuffer):
(WebKit::RemoteGraphicsContextGLProxy::framebufferDiscard):
* Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.h:
*
Source/WebKit/WebProcess/GPU/graphics/RemoteGraphicsContextGLProxyFunctionsGenerated.cpp:
(WebKit::RemoteGraphicsContextGLProxy::invalidateFramebuffer): Deleted.
(WebKit::RemoteGraphicsContextGLProxy::invalidateSubFramebuffer): Deleted.
(WebKit::RemoteGraphicsContextGLProxy::drawBuffers): Deleted.
(WebKit::RemoteGraphicsContextGLProxy::drawBuffersEXT): Deleted.
(WebKit::RemoteGraphicsContextGLProxy::framebufferDiscard): Deleted.
* Tools/Scripts/generate-gpup-webgl:
(webkit_ipc_cpp_proxy_impl.process_out_args):
Canonical link: https://commits.webkit.org/289651.532@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.312@webkitglib/2.48
Commit: 846b3f034f0021a0e45358b904682bc3de367605
https://github.com/WebKit/WebKit/commit/846b3f034f0021a0e45358b904682bc3de367605
Author: Daniel Liu <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/JavaScriptCore/llint/WebAssembly.asm
M Source/JavaScriptCore/wasm/js/JSToWasm.cpp
Log Message:
-----------
Cherry-pick 289651.534@safari-7621-branch (a8d546461042).
https://bugs.webkit.org/show_bug.cgi?id=292621
createJSToWasmJITShared should populate codeBlock and callee slots
https://bugs.webkit.org/show_bug.cgi?id=292621
rdar://150776242
Reviewed by Yusuke Suzuki.
In 294376@main, we updated the JS to Wasm shared thunk to change how
the entrypoint was loaded during calls. With these changes, we don't
use the CodeBlock or Callee slots in the frame. This issue may cause
undefined behavior due to using arbitrary memory values being loaded
from these stack slots. We should populate these slots properly with
the correct JSWebAssemblyInstance and boxed callee values so that we
can walk the stack without running into uninitialized values.
* Source/JavaScriptCore/llint/WebAssembly.asm:
* Source/JavaScriptCore/wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmJITShared):
Canonical link: https://commits.webkit.org/289651.534@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.313@webkitglib/2.48
Commit: 647d239a03850a129b6a86a328aeb3e78a25472f
https://github.com/WebKit/WebKit/commit/647d239a03850a129b6a86a328aeb3e78a25472f
Author: Dan Hecht <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/wasm/gc/i31-array-index.js
M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp
Log Message:
-----------
Cherry-pick 289651.535@safari-7621-branch (b7fa9f7b95c9).
https://bugs.webkit.org/show_bug.cgi?id=293518
[JSC] BBQJIT::addI31GetS needs to truncate the result to 32-bits
https://bugs.webkit.org/show_bug.cgi?id=293518
rdar://151951424
Reviewed by Yusuke Suzuki and Keith Miller.
The tag bits of i31ref need to be removed when evaluating i31.get_u.
Canonical link: https://commits.webkit.org/289651.535@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.314@webkitglib/2.48
Commit: 279a7b66e8865cefbca084954f3241a828a2e97f
https://github.com/WebKit/WebKit/commit/279a7b66e8865cefbca084954f3241a828a2e97f
Author: Youenn Fablet <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/webrtc/net/dcsctp/tx/outstanding_data.cc
M Source/ThirdParty/libwebrtc/Source/webrtc/net/dcsctp/tx/outstanding_data.h
Log Message:
-----------
Cherry-pick 289651.536@safari-7621-branch (c609e634bb2f).
https://bugs.webkit.org/show_bug.cgi?id=293518
com.apple.WebKit.WebContent use-after-free crash at libwebrtc.dylib:
dcsctp::TransmissionControlBlock::SendBufferedPackets
rdar://150587630
Reviewed by David Kilzer.
Instead of modifying outstanding_data_ while iterating it, we iterate
outstanding_data_ and put copies of its Items to be processed in a separate
deque.
We then iterate through the vector to do the processing.
We add an enqueue routine to share code between the two places where
outstanding_data_ is iterated/modified.
*
Source/ThirdParty/libwebrtc/Source/webrtc/net/dcsctp/tx/outstanding_data.cc:
*
Source/ThirdParty/libwebrtc/Source/webrtc/net/dcsctp/tx/outstanding_data.h:
Canonical link: https://commits.webkit.org/289651.536@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.315@webkitglib/2.48
Commit: 90b25c59d8127ca7737ca8ab4fc31b7bfdd78564
https://github.com/WebKit/WebKit/commit/90b25c59d8127ca7737ca8ab4fc31b7bfdd78564
Author: Pedro Varangot <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A
LayoutTests/fast/css/viewtransition-copyelementbaseproperties-no-flushed-style-crash-expected.txt
A
LayoutTests/fast/css/viewtransition-copyelementbaseproperties-no-flushed-style-crash.html
M Source/WebCore/dom/ViewTransition.cpp
Log Message:
-----------
Cherry-pick 289651.537@safari-7621-branch (41211dd06597).
https://bugs.webkit.org/show_bug.cgi?id=293303
Renderer is being used after free during ViewTransition
copyElementBaseProperties
rdar://150195159
https://bugs.webkit.org/show_bug.cgi?id=293303
Reviewed by Matt Woodrow.
This fixes the bug by adding an extra style flush
*
LayoutTests/fast/css/viewtransition-copyelementbaseproperties-no-flushed-style-crash-expected.txt:
Added.
*
LayoutTests/fast/css/viewtransition-copyelementbaseproperties-no-flushed-style-crash.html:
Added.
* Source/WebCore/dom/ViewTransition.cpp:
(WebCore::ViewTransition::updatePseudoElementStylesRead):
Canonical link: https://commits.webkit.org/289651.537@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.316@webkitglib/2.48
Commit: 24ba44cd9bb440984f4d32be82ea0ab015e1fcaf
https://github.com/WebKit/WebKit/commit/24ba44cd9bb440984f4d32be82ea0ab015e1fcaf
Author: Daniel Liu <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/JavaScriptCore/runtime/OrderedHashTableHelper.h
Log Message:
-----------
Cherry-pick 289651.538@safari-7621-branch (44dd2c945c05).
https://bugs.webkit.org/show_bug.cgi?id=293579
OrderedHashTable addImpl should only increment the alive entry count if no
exception takes place
https://bugs.webkit.org/show_bug.cgi?id=293579
rdar://152034907
Reviewed by Yusuke Suzuki.
If an exception is thrown while we are calculating the normalized key, we
will end up in a state where we have incremented aliveEntryCount, but the
map will not actually have an element added. We should only increment the
aliveEntryCount if we successfully add an element to the map.
* Source/JavaScriptCore/runtime/OrderedHashTableHelper.h:
(JSC::OrderedHashTableHelper::addImpl):
Canonical link: https://commits.webkit.org/289651.538@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.317@webkitglib/2.48
Commit: fa508b6ea345dd04e1aba6cc892105a0985fb013
https://github.com/WebKit/WebKit/commit/fa508b6ea345dd04e1aba6cc892105a0985fb013
Author: Yusuke Suzuki <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/stress/copy-data-properties-underscore-proto.js
M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp
Log Message:
-----------
Cherry-pick 289651.541@safari-7621-branch (a59d9e4235bd).
https://bugs.webkit.org/show_bug.cgi?id=293578
ASSERTION FAILED: !(attributes & (PropertyAttribute::Accessor |
PropertyAttribute::CustomAccessor | PropertyAttribute::ReadOnly))
https://bugs.webkit.org/show_bug.cgi?id=293578
rdar://152034597
Reviewed by Keith Miller.
Do not allow copyDataProperties fast path when source structure is
having __proto__ property.
* JSTests/stress/copy-data-properties-underscore-proto.js: Added.
(C0):
(const.v4.set __proto__):
* Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp:
(JSC::canPerformFastPropertyEnumerationForCopyDataProperties):
Canonical link: https://commits.webkit.org/289651.541@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.318@webkitglib/2.48
Commit: 14ae2d81ddfe25e1366acc28bfa45634cc813c7b
https://github.com/WebKit/WebKit/commit/14ae2d81ddfe25e1366acc28bfa45634cc813c7b
Author: Matthew Finkel <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A
LayoutTests/http/tests/security/block-connection-to-zero-port.https-expected.txt
A LayoutTests/http/tests/security/block-connection-to-zero-port.https.html
M Source/WTF/wtf/URL.cpp
Log Message:
-----------
Cherry-pick 289651.542@safari-7621-branch (e53b026d3ace).
https://bugs.webkit.org/show_bug.cgi?id=292888
Block connections to port 0
https://bugs.webkit.org/show_bug.cgi?id=292888
rdar://143927479
Reviewed by Anne van Kesteren.
Requesting connections to port 0 can be leveraged in some interesting ways.
This change prevents creating connections with port 0.
*
LayoutTests/http/tests/security/block-connection-to-zero-port.https-expected.txt:
Added.
* LayoutTests/http/tests/security/block-connection-to-zero-port.https.html:
Added.
* Source/WTF/wtf/URL.cpp:
(WTF::portAllowed):
Canonical link: https://commits.webkit.org/289651.542@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.319@webkitglib/2.48
Commit: 477da9f63f04761312ee536c3c190dbd1a2bff92
https://github.com/WebKit/WebKit/commit/477da9f63f04761312ee536c3c190dbd1a2bff92
Author: Said Abou-Hallawa <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/ipc/invalid-feConvolveMatrix-crash-expected.txt
A LayoutTests/ipc/invalid-feConvolveMatrix-crash.html
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
Log Message:
-----------
Cherry-pick 289651.546@safari-7621-branch (3620d2286f59).
https://bugs.webkit.org/show_bug.cgi?id=293707
Validate the decoded FEConvolveMatrix
https://bugs.webkit.org/show_bug.cgi?id=293707
rdar://149463698
Reviewed by Simon Fraser.
Adopt the validations of SVGFEConvolveMatrixElement::createFilterEffect()
to the
decoded FEConvolveMatrix to ensure the filter effect rectangle is within the
dimension of FilterImage. These validators should be enforced.
1. x of kernelSize > 0
2. 0 <= targetX < x of kernelSize
3. divisor != 0
4. kernelUnitLength cannot be negative or zero
5. kernelSize is the dimension of the flattened kernel
* LayoutTests/TestExpectations:
* LayoutTests/ipc/invalid-feConvolveMatrix-crash-expected.txt: Added.
* LayoutTests/ipc/invalid-feConvolveMatrix-crash.html: Added.
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Canonical link: https://commits.webkit.org/289651.546@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.320@webkitglib/2.48
Commit: 764001f41b76cd0410915c981200840fecd76346
https://github.com/WebKit/WebKit/commit/764001f41b76cd0410915c981200840fecd76346
Author: Daniel Liu <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/stress/json-const-raw-json-should-be-const.js
M Source/JavaScriptCore/runtime/StructureInlines.h
Log Message:
-----------
Cherry-pick 289651.553@safari-7621-branch (62d3336558aa).
https://bugs.webkit.org/show_bug.cgi?id=293970
addPropertyWithoutTransition doesn't call setContainsReadOnlyProperties
https://bugs.webkit.org/show_bug.cgi?id=293970
rdar://152417321
Reviewed by Keith Miller and Mark Lam.
When a JSRawJSONObject is initialized, its property `rawJSON` should be
read-only. However,
the object does not update its structure to indicate it has a read-only
property. This hits
an assertion failure when we try to use the object in certain scenarios. We
should make the
Structure correctly register read-only properties when they are added.
* JSTests/stress/json-const-raw-json-should-be-const.js: Added.
* Source/JavaScriptCore/runtime/StructureInlines.h:
(JSC::Structure::add):
(JSC::Structure::addOrReplacePropertyWithoutTransition):
Canonical link: https://commits.webkit.org/289651.553@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.321@webkitglib/2.48
Commit: 53b71e72414139a319ea35d5c2604c49a1484118
https://github.com/WebKit/WebKit/commit/53b71e72414139a319ea35d5c2604c49a1484118
Author: Yusuke Suzuki <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/stress/string-replace-speculate-string.js
M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
Log Message:
-----------
Cherry-pick 289651.555@safari-7621-branch (b3f27c30ba5e).
https://bugs.webkit.org/show_bug.cgi?id=293730
DFG ASSERTION FAILED: Edge verification error: Node was expected to have
type String but has type Cell
https://bugs.webkit.org/show_bug.cgi?id=293730
rdar://152217438
Reviewed by Yijia Huang.
We should correctly do speculateString when edge says StringUse
regardless. It is possible that leading Check:String can be removed.
* JSTests/stress/string-replace-speculate-string.js: Added.
(catch):
* Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
Canonical link: https://commits.webkit.org/289651.555@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.322@webkitglib/2.48
Commit: a7291197a383a1b0102c40b8568be4b8ba4951ad
https://github.com/WebKit/WebKit/commit/a7291197a383a1b0102c40b8568be4b8ba4951ad
Author: Yijia Huang <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/JavaScriptCore/yarr/YarrJIT.cpp
Log Message:
-----------
Cherry-pick 289651.563@safari-7621-branch (01d3edddfa1a).
https://bugs.webkit.org/show_bug.cgi?id=294182
[YARR] Remove sentinel-based tracking in Unicode read path
https://bugs.webkit.org/show_bug.cgi?id=294182
rdar://152806201
Reviewed by Yusuke Suzuki.
Simplified the logic for tracking additional read size when handling
Unicode characters in
Yarr JIT. Previously, a sentinel-based mechanism (0x4) was used to indicate
whether a non-BMP
character had been read. This approach required conditional logic that
could silently fail
in edge cases like skipped alternatives or control flow changes during
backtracking.
This patch:
- Removes the sentinel mechanism entirely.
- Initializes firstCharacterAdditionalReadSize to 0 on alternative entry.
- Always sets it to 1 when reading a non-BMP character, 0 otherwise.
- Removes all conditional writes and checks for the sentinel.
This change ensures the additional read size is always well-defined and
simplifies the
backtracking and match start logic. It improves robustness and correctness
in Unicode mode
without changing observable RegExp semantics.
* Source/JavaScriptCore/yarr/YarrJIT.cpp:
Canonical link: https://commits.webkit.org/289651.563@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.323@webkitglib/2.48
Commit: 6b5fadcb81d0f95130e9591c619635925ed4036c
https://github.com/WebKit/WebKit/commit/6b5fadcb81d0f95130e9591c619635925ed4036c
Author: Pascoe <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/WebKit/UIProcess/PageClient.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/ios/PageClientImplIOS.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.mm
Log Message:
-----------
Cherry-pick 289651.572@safari-7621-branch (bcdb1e3948f7).
https://bugs.webkit.org/show_bug.cgi?id=294374
File picker dialog can create confusion about which page got the file
https://bugs.webkit.org/show_bug.cgi?id=294374
rdar://134570800
Reviewed by Chris Dumez.
Whenever a window is created via window.open while a file picker dialog is
up,
the window that was opened will be shown after the dialog is
fulfilled/dismissed.
This can create confusion about which page got the file because the page
shown
wasn't the page that got the file. This patch fixes that by closing any
open file
pickers whenever a new window is created.
* Source/WebKit/UIProcess/PageClient.h:
(WebKit::PageClient::dismissAnyOpenPickers):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::createNewPage):
* Source/WebKit/UIProcess/ios/PageClientImplIOS.h:
* Source/WebKit/UIProcess/ios/PageClientImplIOS.mm:
(WebKit::PageClientImpl::dismissAnyOpenPicker):
Canonical link: https://commits.webkit.org/289651.572@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.324@webkitglib/2.48
Commit: 76095d65f6115d836abad8f7e86ba25717d47ec5
https://github.com/WebKit/WebKit/commit/76095d65f6115d836abad8f7e86ba25717d47ec5
Author: Pedro Varangot <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A
LayoutTests/ipc/LocalSampleBufferDisplayLayer-LogIdentifier-data-race-uaf-expected.txt
A
LayoutTests/ipc/LocalSampleBufferDisplayLayer-LogIdentifier-data-race-uaf.html
M Source/WebCore/platform/graphics/avfoundation/SampleBufferDisplayLayer.h
M
Source/WebCore/platform/graphics/avfoundation/objc/LocalSampleBufferDisplayLayer.h
M
Source/WebCore/platform/graphics/avfoundation/objc/LocalSampleBufferDisplayLayer.mm
M
Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm
M Source/WebKit/GPUProcess/webrtc/RemoteSampleBufferDisplayLayer.cpp
M Source/WebKit/GPUProcess/webrtc/RemoteSampleBufferDisplayLayer.h
M Source/WebKit/GPUProcess/webrtc/RemoteSampleBufferDisplayLayer.messages.in
M Source/WebKit/WebProcess/GPU/webrtc/SampleBufferDisplayLayer.cpp
M Source/WebKit/WebProcess/GPU/webrtc/SampleBufferDisplayLayer.h
Log Message:
-----------
Cherry-pick 289651.577@safari-7621-branch (87cbcc71660c).
https://bugs.webkit.org/show_bug.cgi?id=293986
Data race on LogIdentifier setter/use on LocalSampleBufferDisplayLayer can
lead to UAF
rdar://152079992
https://bugs.webkit.org/show_bug.cgi?id=293986
Reviewed by Chris Dumez.
This fixes the bug by using an integer instead of a string as the log
identifier
*
LayoutTests/ipc/LocalSampleBufferDisplayLayer-LogIdentifier-data-race-uaf-expected.txt:
Added.
*
LayoutTests/ipc/LocalSampleBufferDisplayLayer-LogIdentifier-data-race-uaf.html:
Added.
* Source/WebCore/platform/graphics/avfoundation/SampleBufferDisplayLayer.h:
*
Source/WebCore/platform/graphics/avfoundation/objc/LocalSampleBufferDisplayLayer.h:
*
Source/WebCore/platform/graphics/avfoundation/objc/LocalSampleBufferDisplayLayer.mm:
(WebCore::LocalSampleBufferDisplayLayer::layerStatusDidChange):
(WebCore::LocalSampleBufferDisplayLayer::layerErrorDidChange):
(WebCore::LocalSampleBufferDisplayLayer::enqueueBufferInternal):
(WebCore::LocalSampleBufferDisplayLayer::onIrregularFrameRateNotification):
*
Source/WebCore/platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm:
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::layersAreInitialized):
* Source/WebKit/GPUProcess/webrtc/RemoteSampleBufferDisplayLayer.cpp:
(WebKit::RemoteSampleBufferDisplayLayer::setLogIdentifier):
* Source/WebKit/GPUProcess/webrtc/RemoteSampleBufferDisplayLayer.h:
*
Source/WebKit/GPUProcess/webrtc/RemoteSampleBufferDisplayLayer.messages.in:
* Source/WebKit/WebProcess/GPU/webrtc/SampleBufferDisplayLayer.cpp:
(WebKit::SampleBufferDisplayLayer::setLogIdentifier):
* Source/WebKit/WebProcess/GPU/webrtc/SampleBufferDisplayLayer.h:
Canonical link: https://commits.webkit.org/289651.577@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.325@webkitglib/2.48
Commit: 3539e88834dbf92d22be1ab2b4a3176e155ecadf
https://github.com/WebKit/WebKit/commit/3539e88834dbf92d22be1ab2b4a3176e155ecadf
Author: Daniel Liu <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M JSTests/stress/regexp-duplicate-named-captures.js
M Source/JavaScriptCore/yarr/YarrPattern.cpp
Log Message:
-----------
Cherry-pick 289651.581@safari-7621-branch (b8b8e71e68fb).
https://bugs.webkit.org/show_bug.cgi?id=294681
Removing zero-quantified terms from m_forwardReferencesInLookbehind should
compare term
https://bugs.webkit.org/show_bug.cgi?id=294681
rdar://153521682
Reviewed by Yusuke Suzuki.
There are multiple paths which would allow us to put an element into
m_forwardReferencesInLookbehind; the previous condition checking for
forward references with a zero-repeat quantifier would sometimes get
out of sync with the elements being added, meaning that we would end
up with an incorrect vector state.
* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::quantifyAtom):
* JSTests/stress/regexp-duplicate-named-captures.js:
Canonical link: https://commits.webkit.org/289651.581@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.326@webkitglib/2.48
Commit: 890806194b76092c2ff7e6bbe7b2a03a3d2c2f1b
https://github.com/WebKit/WebKit/commit/890806194b76092c2ff7e6bbe7b2a03a3d2c2f1b
Author: Rob Buis <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M LayoutTests/TestExpectations
A LayoutTests/ipc/restore-empty-stack-crash-expected.txt
A LayoutTests/ipc/restore-empty-stack-crash.html
M Source/WebCore/platform/graphics/displaylists/DisplayListRecorderImpl.cpp
Log Message:
-----------
Cherry-pick [email protected] (0f1f962ca278).
https://bugs.webkit.org/show_bug.cgi?id=293971
Release assert in Vector::at via DisplayList::Recorder::didUpdateSingleState
https://bugs.webkit.org/show_bug.cgi?id=293971
Reviewed by Said Abou-Hallawa.
Restore should not clear the last state stack entry if the state stack
entry is zero or one.
* LayoutTests/TestExpectations:
* LayoutTests/ipc/restore-empty-stack-crash-expected.txt: Added.
* LayoutTests/ipc/restore-empty-stack-crash.html: Added.
* Source/WebCore/platform/graphics/displaylists/DisplayListRecorderImpl.cpp:
(WebCore::DisplayList::RecorderImpl::restore):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.585@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.327@webkitglib/2.48
Commit: ed17934b566cd840ef117c2abdc985265ffea30f
https://github.com/WebKit/WebKit/commit/ed17934b566cd840ef117c2abdc985265ffea30f
Author: Claudio Saavedra <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A
LayoutTests/webanimations/reparent-element-with-animation-crash-expected.txt
A LayoutTests/webanimations/reparent-element-with-animation-crash.html
M Source/WebCore/animation/ElementAnimationRareData.cpp
Log Message:
-----------
Cherry-pick [email protected] (d79e4c2037ff).
https://bugs.webkit.org/show_bug.cgi?id=293018
ASAN_ILL | WebCore::ElementAnimationRareData::setLastStyleChangeEventStyle;
Style::TreeResolver::createAnimatedElementUpdate;
Style::TreeResolver::resolveElement
https://bugs.webkit.org/show_bug.cgi?id=293018
Reviewed by Antoine Quint.
When an element with an animation and keyframe effect associated is
reparented,
style originated animations are cancelled for its styleable. This causes the
animation rare data's animations to be destroyed, which in turn also
destroys
the keyframe effects for those animations that have them. The issue is that
keyframe effects are also weak referenced from animation rare data's
keyframe
effect stack, and these weak references become null and are at risk of being
null-dereferenced later on.
This can be fixed by removing keyframe effects for every animation created
by
markup from the keyframe stack, before removing the animations.
A similar fix was landed in https://commits.webkit.org/292328@main, but
that only
addressed the case when an animation is removed from a timeline.
*
LayoutTests/webanimations/reparent-element-with-animation-crash-expected.txt:
Added.
* LayoutTests/webanimations/reparent-element-with-animation-crash.html:
Added.
* Source/WebCore/animation/ElementAnimationRareData.cpp:
(WebCore::ElementAnimationRareData::setAnimationsCreatedByMarkup):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.586@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.328@webkitglib/2.48
Commit: 9529e8df7048cdbbfeddb54ebc83ab64f1aff8ba
https://github.com/WebKit/WebKit/commit/9529e8df7048cdbbfeddb54ebc83ab64f1aff8ba
Author: Rob Buis <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A LayoutTests/svg/animations/key-times-zero-crash-expected.txt
A LayoutTests/svg/animations/key-times-zero-crash.html
M Source/WebCore/svg/SVGAnimationElement.cpp
Log Message:
-----------
Cherry-pick [email protected] (c8e054f1ad1a).
https://bugs.webkit.org/show_bug.cgi?id=293965
Release assert in LegacyRenderSVGRoot::repaintRectInLocalCoordinates
https://bugs.webkit.org/show_bug.cgi?id=293965
Reviewed by Simon Fraser.
For linear and spline animation, the first time value in the list must be
0, and the last time value in the list must be 1 [1].
[1] https://svgwg.org/specs/animations/#KeyTimesAttribute
* LayoutTests/svg/animations/key-times-zero-crash-expected.txt: Added.
* LayoutTests/svg/animations/key-times-zero-crash.html: Added.
* Source/WebCore/svg/SVGAnimationElement.cpp:
(WebCore::SVGAnimationElement::startedActiveInterval):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/289651.587@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.329@webkitglib/2.48
Commit: 7ae5644d765df8c0792429f0474f55b3a17627cd
https://github.com/WebKit/WebKit/commit/7ae5644d765df8c0792429f0474f55b3a17627cd
Author: Dan Hecht <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
A JSTests/wasm/stress/lower-stack-args-huge-frame.js
M Source/JavaScriptCore/b3/air/AirLowerStackArgs.cpp
Log Message:
-----------
Cherry-pick 289651.594@safari-7621-branch (254f4eefafe1).
https://bugs.webkit.org/show_bug.cgi?id=295317
[JSC] Fix lowerStackArgs handling of moves between spill slots and large
frames
https://bugs.webkit.org/show_bug.cgi?id=295317
rdar://154809096
Reviewed by Yusuke Suzuki, Keith Miller, and Mark Lam.
On ARM64, when a stack slot's offset from %fp/%sp cannot be
encoded directly in an instruction, lowerStackArgs uses %lr
to materialize the address. Most instructions on ARM have only
one memory operand, however the Air instruction:
Move (spillA), (spillB), scratchReg
has two stack operands and it's possible for neither to be
directly addressable. Since there is only one register available
to materialize, fix lowering of these stack slots by transforming
this instruction to:
Move (spillA), scratchReg
Move scratchReg, (spillB)
Then the spill slot addresses can be materialized using the single
register. Note that this is the same transformation that will eventually
be done by the MacroAssembler anyway and stack slot coalescing and
allocation has already occurred at this point.
Canonical link: https://commits.webkit.org/289651.594@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.330@webkitglib/2.48
Commit: ef58043a8966f5b49c664ac62f42685d865d80e1
https://github.com/WebKit/WebKit/commit/ef58043a8966f5b49c664ac62f42685d865d80e1
Author: Jer Noble <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/WebCore/platform/audio/HRTFDatabaseLoader.cpp
M Source/WebCore/platform/audio/HRTFDatabaseLoader.h
Log Message:
-----------
Cherry-pick 289651.596@safari-7621-branch (0de4de353f69).
https://bugs.webkit.org/show_bug.cgi?id=295382
CRASH: HRTFDatabaseLoader::createAndLoadAsynchronouslyIfNecessary() crashes
in HRTFDatabaseLoader::ref()
https://bugs.webkit.org/show_bug.cgi?id=295382
rdar://153904348
Reviewed by Andy Estes and Chris Dumez.
Don't store raw pointers as a cache; that's what ThreadSafeWeakPtr is for.
* Source/WebCore/platform/audio/HRTFDatabaseLoader.cpp:
(WebCore::loaderMap):
(WebCore::HRTFDatabaseLoader::createAndLoadAsynchronouslyIfNecessary):
(): Deleted.
Canonical link: https://commits.webkit.org/289651.596@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.331@webkitglib/2.48
Commit: 68477fe6783de1fded2d3676d9befa3c2f9aa85f
https://github.com/WebKit/WebKit/commit/68477fe6783de1fded2d3676d9befa3c2f9aa85f
Author: Rupin Mittal <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.h
M Tools/TestWebKitAPI/Tests/mac/LoadWebArchive.mm
Log Message:
-----------
Cherry-pick 289651.603@safari-7621-branch (52189fdc734f).
https://bugs.webkit.org/show_bug.cgi?id=295655
Navigation isRequestFromClientOrUserInput is incorrectly true for
window.open call with web archive
https://bugs.webkit.org/show_bug.cgi?id=295655
rdar://154084804
Reviewed by Youenn Fablet.
When a web archive is navigated to from a `window.open` call, it's not
client or user initiated--it's programmatically initiated from JavaScript.
But currently, the navigation is incorrectly being marked as client or
user initiated.
So when the request loads, and DocumentLoader checks if it's allowed to
load the web archive:
bool allowsWebArchiveForMainFrame() const { return
m_isRequestFromClientOrUserInput; }
it assumes that it can, and it wrongly loads. We can verify that this
happens in MiniBrowser.
The issue is that WebPageProxy::loadRequest() always marks the navigation
as client or user initiated. Now this is fine in cases where the call to
WebPageProxy::loadRequest() comes from the client via the client making
an API call to WKWebView::loadRequest. But in this case, the client isn't
making an API call. Rather, WebPageProxy::loadRequest() is being called
by WebKit internally. `window.open` leads to WebPageProxy::createNewPage(),
which leads to WebPageProxy::loadRequest().
In this case, we want to tell WebPageProxy::loadRequest() that this is
not client or user initiated. This information is contained in the
`NavigationActionData navigationDataForNewProcess`. So we pass this on
from WebPageProxy::createNewPage() to WebPageProxy::loadRequest().
In all other cases, we keep the current behavior of the navigation being
marked as client or user initiated.
This is tested by a new API test.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::loadRequest):
This will mark the navigation as client or user initiated based on the
new flag being passed in (isRequestFromClientOrUserInput). To ensure
existing behavior doesn't change for other cases, this is true by default.
(WebKit::WebPageProxy::createNewPage):
Since WebKit is internally calling loadRequest from here, we explicitly
pass in navigationDataForNewProcess->isRequestFromClientOrUserInput.
* Source/WebKit/UIProcess/WebPageProxy.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/Download.mm:
(TestWebKitAPI::OriginatingFrameWhenConvertingNavigationInNewWindow)):
The first navigation in this test comes from "a.href" (programmatically
initiated by Javascript). On this call, WebKit is internally calling
WebPageProxy::loadRequest. Before this patch here, this was being marked
as client or user input.
In the fix for https://bugs.webkit.org/show_bug.cgi?id=293994, we changed
WebPageProxy::receivedNavigationResponsePolicyDecision such that if the
navigation was from a client or user input, then the information about the
originating frame would be set to empty. At that time, this first navigation
was going down that code path, so we had to alter the test accordingly.
Now, with this patch, that navigation is correctly being marked as NOT
client or user input. So it's no longer going down the code path introduced
in that previous patch, and we can now remove those changes to the test.
* Tools/TestWebKitAPI/Tests/mac/LoadWebArchive.mm:
(TestWebKitAPI::TEST(LoadWebArchive,
FailNavigationFromNonClientOrUserInitiatedWindowOpen)):
New API test.
Canonical link: https://commits.webkit.org/289651.603@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.332@webkitglib/2.48
Commit: fbac51c793426fa39878fb2d24f3eb7e5217e0de
https://github.com/WebKit/WebKit/commit/fbac51c793426fa39878fb2d24f3eb7e5217e0de
Author: David Kilzer <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encodeframe.c
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encoder.c
Log Message:
-----------
Cherry-pick 289651.604@safari-7621-branch (876b8705fe85).
https://bugs.webkit.org/show_bug.cgi?id=295735
Incorrect memory allocation in vp9_create_compressor and
source_var_based_partition_search_method functions
<https://bugs.webkit.org/show_bug.cgi?id=295735>
<rdar://154433059>
Reviewed by Darin Adler.
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encodeframe.c:
(source_var_based_partition_search_method):
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encoder.c:
(vp9_create_compressor):
- Change sizeof() operator to use `struct Diff` instead of `Diff*`.
Canonical link: https://commits.webkit.org/289651.604@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.333@webkitglib/2.48
Commit: 99d7175ede18f11367cacd84419d053518e5caf4
https://github.com/WebKit/WebKit/commit/99d7175ede18f11367cacd84419d053518e5caf4
Author: Gerald Squelart <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
Log Message:
-----------
Cherry-pick 13edca431b6a. https://bugs.webkit.org/show_bug.cgi?id=295735
Better validator for ShareableBitmapConfiguration::bytesPerPixel
rdar://155751899
Reviewed by Cameron McCormack.
Ensure that the value is between 1 and 8 (inclusive).
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
Canonical link: https://commits.webkit.org/289651.606@safari-7621-branch
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/290945.334@webkitglib/2.48
Commit: fd33252c46398f61d19d99fc0622471e70a03ebf
https://github.com/WebKit/WebKit/commit/fd33252c46398f61d19d99fc0622471e70a03ebf
Author: Roberto Rodriguez <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/ThirdParty/ANGLE/src/libANGLE/TransformFeedback.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/TransformFeedback.h
M Source/ThirdParty/ANGLE/src/libANGLE/validationES2.cpp
M Source/ThirdParty/ANGLE/src/tests/gl_tests/WebGLCompatibilityTest.cpp
Log Message:
-----------
Cherry-pick 9f94758cf470. https://bugs.webkit.org/show_bug.cgi?id=295735
ANGLE: (Cherry-pick upstream commit) M138: Validate buffers bound for
transform feedback are not modified.
rdar://155961812
Reviewed by Jonathan Bedard.
Cherry-pick upstream ANGLE commit
(https://github.com/google/angle/commit/e1dc0a7ab5d1f1f2edaa7e41447d873895e083bf)
to validate buffers bound for transform feedback.
* Source/ThirdParty/ANGLE/src/libANGLE/TransformFeedback.cpp:
(gl::TransformFeedback::isBufferBound const):
* Source/ThirdParty/ANGLE/src/libANGLE/TransformFeedback.h:
* Source/ThirdParty/ANGLE/src/libANGLE/validationES2.cpp:
(gl::ValidateBufferData):
(gl::ValidateBufferSubData):
* Source/ThirdParty/ANGLE/src/tests/gl_tests/WebGLCompatibilityTest.cpp:
Canonical link: https://commits.webkit.org/289651.607@safari-7621-branch
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/290945.335@webkitglib/2.48
Commit: df384465c17de73c477028eb8cb74bdf1a8d5e72
https://github.com/WebKit/WebKit/commit/df384465c17de73c477028eb8cb74bdf1a8d5e72
Author: Roberto Rodriguez <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/ThirdParty/ANGLE/src/libANGLE/TransformFeedback.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/TransformFeedback.h
Log Message:
-----------
Cherry-pick 0c5e0151c010. https://bugs.webkit.org/show_bug.cgi?id=295735
ANGLE: Recompute vertex capacity on transform feedback resume.
rdar://156053084
Reviewed by Jonathan Bedard.
Recompute the vertex capacity upon a transform feedback resume operation
in case an operation changed the underlying buffer between pause and
resume operations.
* Source/ThirdParty/ANGLE/src/libANGLE/TransformFeedback.cpp:
(gl::TransformFeedback::resume):
Canonical link: https://commits.webkit.org/289651.608@safari-7621-branch
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/290945.336@webkitglib/2.48
Commit: 65b737ab9151227d4292cc0fadb8c3f0f5449686
https://github.com/WebKit/WebKit/commit/65b737ab9151227d4292cc0fadb8c3f0f5449686
Author: Chris Dumez <[email protected]>
Date: 2025-07-31 (Thu, 31 Jul 2025)
Changed paths:
M Source/WebCore/Modules/indexeddb/IDBTransaction.cpp
Log Message:
-----------
Cherry-pick 289651.475@safari-7621-branch (05d9b16c830a).
https://bugs.webkit.org/show_bug.cgi?id=292340
Crash under IDBTransaction::requestPutOrAdd()
https://bugs.webkit.org/show_bug.cgi?id=292340
rdar://149937426
Reviewed by Sihui Liu and Per Arne Vollan.
The code was constructing the IDBResultData on the background thread and
then
capturing it in the lambda with a WTFMove() before using it on the main
thread.
This didn't look thread-safe. We could call `isolatedCopy()` but I have
opted
to delay the construction of the IDBResultData until we're on the main
thread.
* Source/WebCore/Modules/indexeddb/IDBTransaction.cpp:
(WebCore::IDBTransaction::putOrAddOnServer):
Canonical link: https://commits.webkit.org/289651.475@safari-7621-branch
Canonical link: https://commits.webkit.org/290945.337@webkitglib/2.48
Compare: https://github.com/WebKit/WebKit/compare/4d05e6db0521...65b737ab9151
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
