Branch: refs/heads/webkitglib/2.50
Home: https://github.com/WebKit/WebKit
Commit: daefdf5d5213d4d6737bfe9aee2d37f5c970bbc7
https://github.com/WebKit/WebKit/commit/daefdf5d5213d4d6737bfe9aee2d37f5c970bbc7
Author: Simon Fraser <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/WebCore/rendering/svg/RenderSVGResourceFilter.h
M Source/WebCore/rendering/svg/RenderSVGResourceFilterPrimitive.h
Log Message:
-----------
Cherry-pick 304432@main (c0e7b7504cf2).
https://bugs.webkit.org/show_bug.cgi?id=304126
CheckedPtr crash when LBSE is enabled
https://bugs.webkit.org/show_bug.cgi?id=304126
rdar://166451135
Reviewed by Alan Baradlay.
All classes derived from CanMakeCheckedPtr need to use
`WTF_OVERRIDE_DELETE_FOR_CHECKED_PTR`.
RenderSVGResourceFilter and RenderSVGResourceFilterPrimitive didn't, so fix
that.
* Source/WebCore/rendering/svg/RenderSVGResourceFilter.h:
* Source/WebCore/rendering/svg/RenderSVGResourceFilterPrimitive.h:
Canonical link: https://commits.webkit.org/304432@main
Canonical link: https://commits.webkit.org/298234.320@webkitglib/2.50
Commit: 15b8b1cd5b99dfb11f06104f573e465f2bb2d0fd
https://github.com/WebKit/WebKit/commit/15b8b1cd5b99dfb11f06104f573e465f2bb2d0fd
Author: Chris Dumez <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/WebCore/platform/audio/AudioSession.h
M Source/WebCore/platform/audio/cocoa/AudioSessionCocoa.h
M Source/WebKit/WebProcess/GPU/media/RemoteAudioSession.h
Log Message:
-----------
Cherry-pick 304350@main (a6f27ff8617c).
https://bugs.webkit.org/show_bug.cgi?id=304049
RemoteMediaSessionManagerProxy inherits ThreadSafeRefCounted from 2 base
classes
https://bugs.webkit.org/show_bug.cgi?id=304049
Reviewed by Jean-Yves Avenard.
RemoteMediaSessionManagerProxy inherits ThreadSafeRefCounted from 2 base
classes (WebCore::REMOTE_MEDIA_SESSION_MANAGER_BASE_CLASS and
WebCore::AudioSession when USE(AUDIO_SESSION) (which is true for Cocoa
ports).
This is not safe and could lead to use-after-free bugs. To address the
issue have AudioSession subclass
AbstractThreadSafeRefCountedAndCanMakeWeakPtr
instead of ThreadSafeRefCountedAndCanMakeWeakPtr.
* Source/WebCore/platform/audio/AudioSession.h:
* Source/WebCore/platform/audio/cocoa/AudioSessionCocoa.h:
* Source/WebKit/UIProcess/Media/RemoteMediaSessionManagerProxy.h:
* Source/WebKit/WebProcess/GPU/media/RemoteAudioSession.h:
Canonical link: https://commits.webkit.org/304350@main
Canonical link: https://commits.webkit.org/298234.321@webkitglib/2.50
Commit: e30883ba56e7be9eb11d5b7af97de92ae76591e9
https://github.com/WebKit/WebKit/commit/e30883ba56e7be9eb11d5b7af97de92ae76591e9
Author: Dan Hecht <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A JSTests/stress/new-regexp-structure.js
M Source/JavaScriptCore/dfg/DFGOperations.cpp
M Source/JavaScriptCore/dfg/DFGOperations.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
Cherry-pick 301765.30@safari-7623-branch (8b1890640ebd).
https://bugs.webkit.org/show_bug.cgi?id=300995
[JSC] Fix cross-realm NewRegExpUntyped
https://bugs.webkit.org/show_bug.cgi?id=300995
rdar://160674600
Reviewed by Mark Lam and Yusuke Suzuki.
There are two bugs with cross-realm NewRegExpUntyped:
1. Strength reduction was reducing to NewRegExp which would lose
the explicit structure.
2. DFG code generation and lowering to B3 was using the wrong
global object when creating the RegExp in this case.
These bugs lead to incorrect speculations and also incorrect
instanceof behavior.
Test: JSTests/stress/new-regexp-structure.js
* JSTests/stress/new-regexp-structure.js: Added.
(assert):
(getStructureID):
(doLoopRegExp):
(testRegExpStructure):
(testRegExpProperty):
* Source/JavaScriptCore/dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* Source/JavaScriptCore/dfg/DFGOperations.h:
* Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:
* Source/JavaScriptCore/dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewRegExpUntyped):
Identifier: 301765.30@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.322@webkitglib/2.50
Commit: 8a06fcc459f5f4eb48bee27097c3a6f6947b7cdb
https://github.com/WebKit/WebKit/commit/8a06fcc459f5f4eb48bee27097c3a6f6947b7cdb
Author: Yusuke Suzuki <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A JSTests/wasm/stress/bbq-array-set-consume.js
M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp
Log Message:
-----------
Cherry-pick 301765.31@safari-7623-branch (3de827f24294).
https://bugs.webkit.org/show_bug.cgi?id=300774
[JSC] BBQ ArraySet should consume inputs when value is constant
https://bugs.webkit.org/show_bug.cgi?id=300774
rdar://162607154
Reviewed by Keith Miller and Dan Hecht.
BBQJIT::addArraySet is missing `consume` for `index` when value is
a constant.
Test: JSTests/wasm/stress/bbq-array-set-consume.js
* JSTests/wasm/stress/bbq-array-set-consume.js: Added.
(sakura_main):
* Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addArraySet):
Identifier: 301765.31@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.323@webkitglib/2.50
Commit: 2d019ddba0acc77b162cc00cb182730f208278dc
https://github.com/WebKit/WebKit/commit/2d019ddba0acc77b162cc00cb182730f208278dc
Author: Yusuke Suzuki <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A
JSTests/stress/eval-fast-transition-move-should-be-activated-only-when-no-proto-use.js
M Source/JavaScriptCore/runtime/LiteralParser.cpp
Log Message:
-----------
Cherry-pick 301765.58@safari-7623-branch (8895b65ce8a3).
https://bugs.webkit.org/show_bug.cgi?id=301129
[JSC] Eval fast path for structure transition should be taken only when we
have never executed "__proto__" before
https://bugs.webkit.org/show_bug.cgi?id=301129
rdar://163041157
Reviewed by Dan Hecht.
Eval mode for JSON.parse (not normal JSON.parse) allows using normal
[[Put]] operation only for `__proto__`. But once we executed it, we
cannot assume that the given object is non-observable to users (and it
may have various random behavior). So, let's disable transitioning
optimization when we detect `__proto__` setter call was done before.
Test:
JSTests/stress/eval-fast-transition-move-should-be-activated-only-when-no-proto-use.js
*
JSTests/stress/eval-fast-transition-move-should-be-activated-only-when-no-proto-use.js:
Added.
(main.):
(main):
* Source/JavaScriptCore/runtime/LiteralParser.cpp:
(JSC::requires):
Identifier: 301765.58@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.324@webkitglib/2.50
Commit: 08ee9117f9f585f0974625f79a22347995cece83
https://github.com/WebKit/WebKit/commit/08ee9117f9f585f0974625f79a22347995cece83
Author: Frédéric Wang <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A
LayoutTests/fast/layout/removing-descendant-from-a-never-laid-out-marquee-crash-expected.txt
A
LayoutTests/fast/layout/removing-descendant-from-a-never-laid-out-marquee-crash.html
M Source/WebCore/html/HTMLMarqueeElement.h
M Source/WebCore/rendering/updating/RenderTreeBuilder.cpp
Log Message:
-----------
Cherry-pick [email protected] (e78d76a4e51b).
https://bugs.webkit.org/show_bug.cgi?id=298301
ASAN_ILL | Layout::LineBuilder::initialize;
Layout::LineBuilder::layoutInlineContent;
Layout::IntrinsicWidthHandler::computedIntrinsicWidthForConstrain
https://bugs.webkit.org/show_bug.cgi?id=298301
Reviewed by Alan Baradlay.
(RenderObjects relying on a) RenderMarquee can run preferred width
computation but not run layout between tree mutations. In general,
we skip invalidation for removal of a never-laid-out renderer. This
patch drops this optimization if the removed renderer is in a
subtree of a never-laid-out RenderMarquee.
*
LayoutTests/fast/layout/removing-descendant-from-a-never-laid-out-marquee-crash-expected.txt:
Added.
*
LayoutTests/fast/layout/removing-descendant-from-a-never-laid-out-marquee-crash.html:
Added.
* Source/WebCore/html/HTMLMarqueeElement.h:
* Source/WebCore/rendering/updating/RenderTreeBuilder.cpp:
(WebCore::isRenderMarquee): New helper to check if a RenderObject has an
associated RenderMarquee.
(WebCore::isWithinNeverLaidOutRenderMarqueeSubtree): New helper to check if
a RenderObject is withing a never laid out subtree of a node with an associated
RenderMarquee.
(WebCore::invalidateLineLayout): For invalidation if we are in a never laid
out RenderMarquee subtree.
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.325@webkitglib/2.50
Commit: 910a4cb5cde43dc83dd3e890d1c26a5a41d2dffa
https://github.com/WebKit/WebKit/commit/910a4cb5cde43dc83dd3e890d1c26a5a41d2dffa
Author: Rob Buis <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A LayoutTests/fast/misc/event-region-with-prohibited-frame-expected.txt
A LayoutTests/fast/misc/event-region-with-prohibited-frame.html
M Source/WebCore/rendering/RenderLayerCompositor.cpp
Log Message:
-----------
Cherry-pick [email protected] (544f117e7985).
https://bugs.webkit.org/show_bug.cgi?id=296870
ASAN_ILL | LayoutIntegration::LineLayout::paint;
WebCore::RenderLayer::collectEventRegionForFragments;
WebCore::RenderLayer::paintLayerContents
https://bugs.webkit.org/show_bug.cgi?id=296870
rdar://157023591
Reviewed by Simon Fraser.
The test case contains a subframe that starts self referencing. Such
subframes
are being prohibited and not guaranteed to have a laid out rendering tree.
So
in that case prevent event region collecting since that would lead to
various ASSERTs.
* LayoutTests/fast/misc/event-region-with-prohibited-frame-expected.txt:
Added.
* LayoutTests/fast/misc/event-region-with-prohibited-frame.html: Added.
* Source/WebCore/rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateEventRegions):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.326@webkitglib/2.50
Commit: 7cdb2ab08b9fa7a0d2cee972ef30f3bcf6d7f22f
https://github.com/WebKit/WebKit/commit/7cdb2ab08b9fa7a0d2cee972ef30f3bcf6d7f22f
Author: Rob Buis <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A
LayoutTests/fast/forms/textarea-with-absolute-placeholder-crash-expected.txt
A LayoutTests/fast/forms/textarea-with-absolute-placeholder-crash.html
M Source/WebCore/css/html.css
Log Message:
-----------
Cherry-pick [email protected] (b4e1ccfd7e27).
https://bugs.webkit.org/show_bug.cgi?id=298078
ASAN_ILL | WebCore::LocalFrameViewLayoutContext::performLayout;
WebCore::LocalFrameViewLayoutContext::layout; WebCore::Document::updateLayout
https://bugs.webkit.org/show_bug.cgi?id=298078
rdar://157023263
Reviewed by Alan Baradlay.
The placeholder text in the RenderTextControl is treated as excluded
content and uses special
layout logic. This special layout logic does not consider that the
placeholder can be absolutely
positioned like in the testcase, resulting in a render tree that ends up
being dirty.
To prevent this problem, do not allow position values other than the
default 'static', which
actually matches the specification [1], since it states a limited number of
properties apply
to the ::placeholder pseudo-element, which does not include the position
property.
[1] https://drafts.csswg.org/css-pseudo/#placeholder-pseudo
*
LayoutTests/fast/forms/textarea-with-absolute-placeholder-crash-expected.txt:
Added.
* LayoutTests/fast/forms/textarea-with-absolute-placeholder-crash.html:
Added.
* Source/WebCore/css/html.css:
(::placeholder):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.327@webkitglib/2.50
Commit: 35ecf804fc7432e5e0ed6520f9cdd99cf0fe0f90
https://github.com/WebKit/WebKit/commit/35ecf804fc7432e5e0ed6520f9cdd99cf0fe0f90
Author: Rob Buis <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A LayoutTests/fast/text/text-wrap-no-hyphenation-crash-expected.txt
A LayoutTests/fast/text/text-wrap-no-hyphenation-crash.html
M
Source/WebCore/layout/formattingContexts/inline/InlineContentConstrainer.cpp
Log Message:
-----------
Cherry-pick [email protected] (c18e654b85ca).
https://bugs.webkit.org/show_bug.cgi?id=296871
ASAN_ILL | Layout::InlineContentConstrainer::prettifyRange;
Layout::InlineContentConstrainer::computeParagraphLevelConstraints;
Layout::InlineFormattingContext::layout
https://bugs.webkit.org/show_bug.cgi?id=296871
rdar://157025106
Reviewed by Alan Baradlay.
In InlineContentConstrainer::prettifyRange, if the hyphenation step does
not yield a new lastValidStateIndex, treat that as hyphenation not creating
a valid solution, since continuing would result in assertion failure.
* LayoutTests/fast/text/text-wrap-no-hyphenation-crash-expected.txt: Added.
* LayoutTests/fast/text/text-wrap-no-hyphenation-crash.html: Added.
*
Source/WebCore/layout/formattingContexts/inline/InlineContentConstrainer.cpp:
(WebCore::Layout::InlineContentConstrainer::prettifyRange):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.328@webkitglib/2.50
Commit: 7bc644563ef39aac95beb994b42dd4f3503f5196
https://github.com/WebKit/WebKit/commit/7bc644563ef39aac95beb994b42dd4f3503f5196
Author: Rob Buis <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts2-expected.txt
A LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts2.html
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Cherry-pick [email protected] (59c02d213d27).
https://bugs.webkit.org/show_bug.cgi?id=298926
ASAN_ILL | WebCore::FloatingObject::renderer;
WebCore::RenderBlockFlow::styleDidChange; WebCore::RenderElement::setStyle
https://bugs.webkit.org/show_bug.cgi?id=298926
rdar://158670568
Reviewed by Alan Baradlay.
In the test case some layout is skipped due to the details open attribute
and later toggled
to unskip it. The skipped subtree has some FloatingObjects and when the img
get recreated
by the RenderTreeUpdater some of those FloatingObjects will have a null
renderer (to said img renderer).
Since 295699@main RenderBlockFlow::subtreeContainsFloat uses childrenOfType
so not all descendents
are being searched, in the test case the slot element and its child are not
found, leaving those FloatingObjects with
destroyed renderers and crashing when iterating over them in
rebuildFloatingObjectSetFromIntrudingFloats.
To fix this revert to using descendantsOfType instead of childrenOfType.
*
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts2-expected.txt:
Added.
*
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts2.html:
Added.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::subtreeContainsFloat const):
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.329@webkitglib/2.50
Commit: 3f150d2e8f2b1fcbb003787f2573581df1d494dc
https://github.com/WebKit/WebKit/commit/3f150d2e8f2b1fcbb003787f2573581df1d494dc
Author: Frédéric Wang <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts3-expected.txt
A LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts3.html
Log Message:
-----------
Cherry-pick [email protected] (8edee3d73524).
https://bugs.webkit.org/show_bug.cgi?id=298924
ASAN_ILL | WTF::HashTable::contains;
WebCore::RenderBlockFlow::subtreeContainsFloat;
WebCore::RenderBlockFlow::markAllDescendantsWithFloatsForLayout
https://bugs.webkit.org/show_bug.cgi?id=298924
rdar://158670568
Reviewed by Alan Baradlay.
Add a non-regression test. This was originally fixed in
https://commits.webkit.org/[email protected]
*
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts3-expected.txt:
Added.
*
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts3.html:
Added.
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.330@webkitglib/2.50
Commit: 1d6167291c150f26293dd873d1767109f4d0ba98
https://github.com/WebKit/WebKit/commit/1d6167291c150f26293dd873d1767109f4d0ba98
Author: Frédéric Wang <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts4-expected.txt
A LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts4.html
M Source/WebCore/rendering/RenderBlockFlow.cpp
Log Message:
-----------
Cherry-pick [email protected] (e26b1271204e).
https://bugs.webkit.org/show_bug.cgi?id=298924
Bug 300371 [WebKit][Main+SU?] [e4d4086839401519] ASAN_ILL |
WTF::HashTable::lookup; WebCore::RenderBlockFlow::layoutBlockChildren;
WebCore::RenderBlockFlow::layoutBlock
rdar://162032638
Reviewed by Alan Baradlay.
Skipped root/subtree may not have their m_floatingObjects up-to-date.
In particular this set may contain dangling pointer to destroyed renderers
causing some null pointer dereference when marking siblings/descendants
with floats for layout. This patch fixes that using the logic of (*):
we always enter skipped root/subtree when marking for layout and at the
same time skip calls to containsFloat()/removeFloatingBox().
(*) https://commits.webkit.org/293889@main.
*
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts4-expected.txt:
Added.
*
LayoutTests/fast/dynamic/stale-floating-state-after-skipped-layouts4.html:
Added.
* Source/WebCore/rendering/RenderBlockFlow.cpp:
(WebCore::isSkippedContentRootOrSkippedContent): New helper method to test
both skipped content root and subtree.
(WebCore::RenderBlockFlow::layoutBlockChildren): Force to descend into the
subtree for skipped root/subtree and don't call containsFloat() on a possible
dirty m_floatingObjects.
(WebCore::RenderBlockFlow::markAllDescendantsWithFloatsForLayout): Don't
call removeFloatingBox() on a possibly dirty m_floatingObjects.
Instead mark the renderer as skipped during layout so that it will be
rebuilt later.
Force to descend into the subtree for skipped root/subtree.
(WebCore::RenderBlockFlow::markSiblingsWithFloatsForLayout): Rewrite the
code from (*) using the new helper.
Canonical link: https://commits.webkit.org/[email protected]
Identifier: 301765.68@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.331@webkitglib/2.50
Commit: 7fdb19358521820b560836ecf6aea00327a2229e
https://github.com/WebKit/WebKit/commit/7fdb19358521820b560836ecf6aea00327a2229e
Author: Said Abou-Hallawa <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A LayoutTests/ipc/convert-to-luminance-mask-float16-expected.txt
A LayoutTests/ipc/convert-to-luminance-mask-float16.html
M Source/WebCore/platform/graphics/ImageBufferBackend.cpp
M Source/WebCore/platform/graphics/ImageBufferBackend.h
Log Message:
-----------
Cherry-pick 301765.69@safari-7623-branch (dd5d2b7d6a4c).
https://bugs.webkit.org/show_bug.cgi?id=300049
[CoreIPC] convertToLuminanceMask() is not ready to work in backend with
RGBA16F pixel format
https://bugs.webkit.org/show_bug.cgi?id=300049
rdar://161079211
Reviewed by Gerald Squelart.
CoreIPC can create a RemoteImageBuffer with RGBA16F pixel format then it
can call
convertToLuminanceMask() for it. Currently convertToLuminanceMask()
calculates
four bytes per pixel. It also deals with standard colorSpace which assumes
all
the channels range from 0 to 1.
The fix is convertToLuminanceMask() should work only for 4-bytes buffers
for now.
Test: ipc/convert-to-luminance-mask-float16.html
* LayoutTests/ipc/convert-to-luminance-mask-float16-expected.txt: Added.
* LayoutTests/ipc/convert-to-luminance-mask-float16.html: Added.
* Source/WebCore/platform/graphics/ImageBufferBackend.cpp:
(WebCore::ImageBufferBackend::convertToLuminanceMaskFloat16):
(WebCore::ImageBufferBackend::convertToLuminanceMaskUint8):
(WebCore::ImageBufferBackend::convertToLuminanceMask):
* Source/WebCore/platform/graphics/ImageBufferBackend.h:
Identifier: 301765.69@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.332@webkitglib/2.50
Commit: 091a6fe9ddec2fcc1917687d1d09c33eb45f3582
https://github.com/WebKit/WebKit/commit/091a6fe9ddec2fcc1917687d1d09c33eb45f3582
Author: Dan Hecht <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A JSTests/wasm/stress/i32-multivalue-truncate.js
M Source/JavaScriptCore/wasm/WasmOperations.cpp
Log Message:
-----------
Cherry-pick 301765.80@safari-7623-branch (dad39caa1d1c).
https://bugs.webkit.org/show_bug.cgi?id=301211
[JSC] operationIterateResults needs to truncate i32 results
https://bugs.webkit.org/show_bug.cgi?id=301211
rdar://153280651
Reviewed by Daniel Liu.
BBQ expects that values are truncated to their proper size when
producing the value. When converting from JS signed 32-bits to
wasm i32, should be zero extending rather than sign extending.
Test: JSTests/wasm/stress/i32-multivalue-truncate.js
* JSTests/wasm/stress/i32-multivalue-truncate.js: Added.
(async test.getTwoI32s):
(async test):
* Source/JavaScriptCore/wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_NOEXCEPT_JIT_OPERATION):
Identifier: 301765.80@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.333@webkitglib/2.50
Commit: 0e601dd004c5855071a83634d133db42af362649
https://github.com/WebKit/WebKit/commit/0e601dd004c5855071a83634d133db42af362649
Author: Sihui Liu <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/WebCore/Modules/indexeddb/IDBTransaction.cpp
M Source/WebCore/Modules/indexeddb/IDBTransaction.h
Log Message:
-----------
Cherry-pick 301765.81@safari-7623-branch (c819f0eceb0a).
https://bugs.webkit.org/show_bug.cgi?id=301211
Fix use-after-free in IDBTransaction::abortInProgressOperations
rdar://161012400
Reviewed by Per Arne Vollan.
Recent crashes indicate that the objects in
m_transactionOperationsInProgressQueue are already freed when we try to
create RefPtr from them in IDBTransaction::abortInProgressOperations. To
fix this, store RefPtr in
m_transactionOperationsInProgressQueue.
* Source/WebCore/Modules/indexeddb/IDBTransaction.cpp:
(WebCore::IDBTransaction::abortInProgressOperations):
* Source/WebCore/Modules/indexeddb/IDBTransaction.h:
Identifier: 301765.81@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.334@webkitglib/2.50
Commit: d89df08268a668927d1def6668ce6534f67ed784
https://github.com/WebKit/WebKit/commit/d89df08268a668927d1def6668ce6534f67ed784
Author: Yusuke Suzuki <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A JSTests/stress/data-view-byte-length-oob-exit.js
M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp
Log Message:
-----------
Cherry-pick 301765.85@safari-7623-branch (2432c9cc358a).
https://bugs.webkit.org/show_bug.cgi?id=301257
[JSC] DataViewGetByteLength resizable-array path is not setting OSR exit
correctly
https://bugs.webkit.org/show_bug.cgi?id=301257
rdar://160383983
Reviewed by Tadeu Zagallo.
There are two issues in the implementation of resizable-array-accepting
DataViewGetByteLength. This is because this node is specially doing OSR
exit from a patchpoint. And other patchpoints are typically (1) not
having a result value and not having a complicated computation or (2)
OSR exits only when exception is thrown and exception-related-OSR-exit
is handled in a different way. This patch fixes DataViewGetByteLength
patchpoint by introducing two changes.
1. resultGPR can be modified before jumping to OSR exit. This is
problematic since OSR exit's stackmap is capturing what we see before
this patchpoint starts. We should def the result only after ensuring
that we will not do OSR exit. This patch adds one scratch register
and storing a result to that. And after OSR exit check is done, we
move it to the resultGPR.
2. osrExitArgumentOffset is not correct as it requires result value
offset. Adding +1 to that offset.
Test: JSTests/stress/data-view-byte-length-oob-exit.js
* JSTests/stress/data-view-byte-length-oob-exit.js: Added.
(i.counter.else.catch):
* Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::typedArrayLength):
Identifier: 301765.85@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.335@webkitglib/2.50
Commit: 9c59d6cbbcb478385ff8a81005297c013cb8f4e7
https://github.com/WebKit/WebKit/commit/9c59d6cbbcb478385ff8a81005297c013cb8f4e7
Author: Yusuke Suzuki <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A JSTests/wasm/stress/catch-pinned-registers.js
M Source/JavaScriptCore/wasm/WasmIRGeneratorHelpers.h
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
Log Message:
-----------
Cherry-pick 301765.98@safari-7623-branch (d8b7d2999677).
https://bugs.webkit.org/show_bug.cgi?id=301324
[JSC] Wasm OMG Catch entry should setup pinned registers at prologue
https://bugs.webkit.org/show_bug.cgi?id=301324
rdar://161754890
Reviewed by Dan Hecht.
When wasm memory is shared or signaling, wasm memory base address never
changes. So when we may execute a code which can clobber instance,
instead of loading it from a instance, we get B3 Value representing it.
However, normal code in the root block touches this value, thus which
can be used before we set up these values from catch entry.
Catch prologue will be executed for each entry case, and it will be
executed before any of OMG code. Thus we should set up all necessary
registers inside this prologue. This patch fills pinned registers when
necessary inside catch prologue thunk.
Test: JSTests/wasm/stress/catch-pinned-registers.js
* JSTests/wasm/stress/catch-pinned-registers.js: Added.
(instantiate):
(async let):
* Source/JavaScriptCore/wasm/WasmIRGeneratorHelpers.h:
(JSC::Wasm::buildEntryBufferForCatch):
* Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp:
(JSC::Wasm::OMGIRGenerator::emitCatchImpl):
(JSC::Wasm::OMGIRGenerator::emitCatchTableImpl):
Identifier: 301765.98@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.336@webkitglib/2.50
Commit: 9b7c4e188ea16e3ef4e67c0c9b7c3b8395d0ed4f
https://github.com/WebKit/WebKit/commit/9b7c4e188ea16e3ef4e67c0c9b7c3b8395d0ed4f
Author: Yulun Wu <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-pretty-long-span-crash-expected.txt
A
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-pretty-long-span-crash.html
A
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-pretty-style-element-crash-expected.txt
A
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-pretty-style-element-crash.html
M
Source/WebCore/layout/formattingContexts/inline/InlineContentConstrainer.cpp
Log Message:
-----------
Cherry-pick 301765.101@safari-7623-branch (86ed16e14826).
https://bugs.webkit.org/show_bug.cgi?id=301324
[text-wrap][pretty] Fix index type mismatch in layoutSingleLineForPretty().
<rdar://162028337>
Reviewed by Alan Baradlay.
This PR fixes a crash caused by passing a break opportunity index instead
of an inline item index to
layoutSingleLineForPretty(). This fix looks up the inline item index from
the break opportunity index to
pass in the correct arguments to layoutSingleLineForPretty().
Combined changes:
Test:
fast/css3-text/css3-text-wrap/text-wrap-pretty-style-element-crash.html
*
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-pretty-style-element-crash-expected.txt:
Added.
*
LayoutTests/fast/css3-text/css3-text-wrap/text-wrap-pretty-style-element-crash.html:
Added.
*
Source/WebCore/layout/formattingContexts/inline/InlineContentConstrainer.cpp:
(WebCore::Layout::InlineContentConstrainer::prettifyRange):
Identifier: 301765.101@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.337@webkitglib/2.50
Commit: fb13e0135cad575fbcfa7520289a55c2a203c7db
https://github.com/WebKit/WebKit/commit/fb13e0135cad575fbcfa7520289a55c2a203c7db
Author: Shu-yu Guo <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/WTF/wtf/HashTable.h
Log Message:
-----------
Cherry-pick 301765.102@safari-7623-branch (bd2c16c27581).
https://bugs.webkit.org/show_bug.cgi?id=301371
[WTF] Check size in WTF::HashTable::expand
https://bugs.webkit.org/show_bug.cgi?id=301371
rdar://162695092
Reviewed by Yijia Huang.
Used checked arithmetic when computing new table sizes during HashTable
expansion to protect against overflows.
No tests are added as testing HashTables with sizes big enough that would
overflow unsigned is both slow and memory intensive.
Identifier: 301765.102@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.338@webkitglib/2.50
Commit: 9ece85d6382cecfd3386f3909838c730c32796bc
https://github.com/WebKit/WebKit/commit/9ece85d6382cecfd3386f3909838c730c32796bc
Author: Alan Baradlay <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A
LayoutTests/fast/block/float/incorrect-float-state-after-align-shift-expected.txt
A LayoutTests/fast/block/float/incorrect-float-state-after-align-shift.html
M Source/WebCore/rendering/FloatingObjects.cpp
Log Message:
-----------
Cherry-pick 301765.105@safari-7623-branch (7d76e40e21d9).
https://bugs.webkit.org/show_bug.cgi?id=301301
[Floats] Crash in WebCore::PODIntervalTree::searchForOverlapsFrom;
WebCore::PODIntervalTree::searchForOverlapsFrom;
WebCore::FloatingObjects::logicalRightOffset
https://bugs.webkit.org/show_bug.cgi?id=301301
<rdar://
Reviewed by Antti Koivisto.
PODIntervalTree node needs to be "updated" when associated float position
changes.
(PODIntervalTree is a red-black tree where nodes are floating objects with
y-maxY intervals.
In order to be able for find such floats in the tree, we have to ensure
their positions are always up-to-date.)
Test: fast/block/float/incorrect-float-state-after-align-shift.html
*
LayoutTests/fast/block/float/incorrect-float-state-after-align-shift-expected.txt:
Added.
*
LayoutTests/fast/block/float/incorrect-float-state-after-align-shift.html:
Added.
* Source/WebCore/rendering/FloatingObjects.cpp:
(WebCore::FloatingObjects::shiftFloatsBy):
Identifier: 301765.105@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.339@webkitglib/2.50
Commit: 47e92fcd264d7626348794e1ce21b4e9fb6f0008
https://github.com/WebKit/WebKit/commit/47e92fcd264d7626348794e1ce21b4e9fb6f0008
Author: Brady Eidson <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A
LayoutTests/http/tests/notifications/request-in-cross-origin-frame-expected.txt
A LayoutTests/http/tests/notifications/request-in-cross-origin-frame.html
A
LayoutTests/http/tests/notifications/resources/request-in-cross-origin-subframe.html
M Source/WebCore/Modules/notifications/Notification.cpp
Log Message:
-----------
Cherry-pick 301765.166@safari-7623-branch (b47fc7e04bef).
https://bugs.webkit.org/show_bug.cgi?id=298963
Cross-origin iframe can trigger native Notification permission prompt
rdar://163197557
Reviewed by Ben Nham.
The spec is currently silent on this, but the other browsers don't allow
cross-origin iframes
to request notification permission.
So we'll now do the same.
Test: http/tests/notifications/request-in-cross-origin-frame.html
*
LayoutTests/http/tests/notifications/request-in-cross-origin-frame-expected.txt:
Added.
* LayoutTests/http/tests/notifications/request-in-cross-origin-frame.html:
Added.
*
LayoutTests/http/tests/notifications/resources/request-in-cross-origin-subframe.html:
Added.
* Source/WebCore/Modules/notifications/Notification.cpp:
(WebCore::Notification::requestPermission):
Identifier: 301765.166@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.340@webkitglib/2.50
Commit: c25f73c28ee5e8742ea2ef758e53be17667eafd4
https://github.com/WebKit/WebKit/commit/c25f73c28ee5e8742ea2ef758e53be17667eafd4
Author: Rob Buis <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A LayoutTests/fast/editing/recursive-unapply-edit-command-crash-expected.txt
A LayoutTests/fast/editing/recursive-unapply-edit-command-crash.html
M Source/WebCore/editing/Editor.cpp
Log Message:
-----------
Cherry-pick [email protected] (e7840d7d1a5e).
https://bugs.webkit.org/show_bug.cgi?id=300375
[WebKit][Main+SU?] [3cff0e3a4d6faa36] ASAN_SEGV |
WebCore::Page::respondToUnappliedWritingToolsEditing;
WebCore::Editor::unappliedEditing; WebCore::EditCommandComposition::unapply
https://bugs.webkit.org/show_bug.cgi?id=300375
rdar://162025465
Reviewed by Ryosuke Niwa.
Make sure page is non null before calling
respondToUnappliedWritingToolsEditing. This is closely related to
284805@main, so base the test case on
recursive-reapply-edit-command-crash.html.
Test: fast/editing/recursive-unapply-edit-command-crash.html
*
LayoutTests/fast/editing/recursive-unapply-edit-command-crash-expected.txt:
Added.
* LayoutTests/fast/editing/recursive-unapply-edit-command-crash.html: Added.
* Source/WebCore/editing/Editor.cpp:
(WebCore::Editor::unappliedEditing):
Canonical link: https://commits.webkit.org/[email protected]
Identifier: 301765.169@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.341@webkitglib/2.50
Commit: 4ec1f21be2d992007e3adba20f079762252113f6
https://github.com/WebKit/WebKit/commit/4ec1f21be2d992007e3adba20f079762252113f6
Author: Tyler Wilcock <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A LayoutTests/accessibility/mac/find-sentence-boundary-crash-expected.txt
A LayoutTests/accessibility/mac/find-sentence-boundary-crash.html
M Source/WTF/wtf/text/TextBreakIterator.cpp
M Source/WTF/wtf/text/TextBreakIterator.h
M Source/WebCore/accessibility/AXTextMarker.cpp
Log Message:
-----------
Cherry-pick 301765.196@safari-7623-branch (ee21633d1dd7).
https://bugs.webkit.org/show_bug.cgi?id=301649
AXTextMarker's use of sentenceBreakIterator off the main-thread is not
threadsafe and can cause crashes
https://bugs.webkit.org/show_bug.cgi?id=301649
rdar://162811597
Reviewed by Joshua Hoffman.
If the main-thread is using sentenceBreakIterator (which uses a static
UBreakIterator*), and the accessibility thread
also simulataneously tries to use it via previousSentenceStartFromOffset or
nextSentenceEndFromOffset, a crash can
happen because UBreakIterators are not threadsafe.
Fix this by introducing a new WTF::NonSharedSentenceBreakIterator, and use
that in AXTextMarker instead.
Test: accessibility/mac/find-sentence-boundary-crash.html
* LayoutTests/accessibility/mac/find-sentence-boundary-crash-expected.txt:
Added.
* LayoutTests/accessibility/mac/find-sentence-boundary-crash.html: Added.
* Source/WTF/wtf/text/TextBreakIterator.cpp:
(WTF::getNonSharedSentenceBreakIterator):
(WTF::cacheNonSharedSentenceBreakIterator):
(WTF::NonSharedSentenceBreakIterator::NonSharedSentenceBreakIterator):
(WTF::NonSharedSentenceBreakIterator::~NonSharedSentenceBreakIterator):
* Source/WTF/wtf/text/TextBreakIterator.h:
(WTF::NonSharedSentenceBreakIterator::operator UBreakIterator* const):
* Source/WebCore/accessibility/AXTextMarker.cpp:
(WebCore::previousSentenceStartFromOffset):
(WebCore::nextSentenceEndFromOffset):
Identifier: 301765.196@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.342@webkitglib/2.50
Commit: d247c059af8504e2fbab3b27ec5ff1b661693294
https://github.com/WebKit/WebKit/commit/d247c059af8504e2fbab3b27ec5ff1b661693294
Author: Dan Hecht <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
M Source/JavaScriptCore/wasm/WasmContext.h
M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp
M Source/JavaScriptCore/wasm/WasmIRGeneratorHelpers.h
M Source/JavaScriptCore/wasm/WasmOperations.cpp
Log Message:
-----------
Cherry-pick 300775@main (e392e01575e3).
https://bugs.webkit.org/show_bug.cgi?id=299831
[JSC] WASM IPInt SIMD: support v128 in IPInt to BBQ loop OSR
https://bugs.webkit.org/show_bug.cgi?id=299831
rdar://161608423
Reviewed by Yusuke Suzuki and Daniel Liu.
Follow the existing BBQ to OMG loop OSR scratch buffer usage pattern,
which is that for functions that use SIMD, allocate two scratch
buffer "slots" (slot is uint64) per item so that v128 sized
values can fit.
Tested by running stress/{simd-osr.js, simd-osr-many-vectors.js}
tests with --useWasmIPIntSIMD=true and see that they now pass.
Canonical link: https://commits.webkit.org/300775@main
Canonical link: https://commits.webkit.org/298234.343@webkitglib/2.50
Commit: 7023ee12ffae0f988c2f1c73329d33d02e327176
https://github.com/WebKit/WebKit/commit/7023ee12ffae0f988c2f1c73329d33d02e327176
Author: Vassili Bykov <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/JavaScriptCore/wasm/js/WebAssemblyGCStructure.cpp
M Source/JavaScriptCore/wasm/js/WebAssemblyGCStructure.h
Log Message:
-----------
Cherry-pick 297297.432@safari-7622-branch (0ff0dfde5222).
https://bugs.webkit.org/show_bug.cgi?id=298963
WebAssemblyGCStructure should retain the transitive closure of all
referenced TypeDefinitions
https://bugs.webkit.org/show_bug.cgi?id=298963
rdar://160601609
Reviewed by Daniel Liu.
As the radar demonstrates, there is a fundamental problem in the existing
scheme of how GC
objects are associated with TypeDefinitions. A TypeDefinition representing
the type of a
GC object is related to a set of other TypeDefinitions: the expanded form
of the type as
well as the transitive closure of the types of struct fields and array
elements. Because
TypeDefinitions and some other system elements internally use raw pointers
to refer to
related TypeDefinitions, this entire set of type dependencies should stay
alive while the
GC object is alive.
The existing GC Object/TypeDefinition design uses GC object structures to
retain the
declared type of the object. Even if a GC object outlives its original Wasm
instance,
the structure stays alive together with the object and keeps the declared
type alive.
Unfortunately, as explained above, the declared type may depend on other
types, but
instances of those related types are not guaranteed to be around to keep
their
TypeDefinitions alive. The radar and the test case of this patch show an
example of a
struct A related to struct B, but without a live instance of B to keep
struct B's
TypeDefinition alive.
To address the root cause of this problem, we must make it so that for any
GC object type
T, all types T depends on are retained independently of the liveness of
their own
instances, for as long as there are live instances of T.
This patch makes WebAssemblyGCStructure collect and retain the set of all
relevant
TypeDefinitions. That includes the transitive closure of all
TypeDefinitions reachable via
struct fields and array elements, as well as the expanded and unexpanded
forms of the
declared type of the GC object. This set of dependencies is collected when
the structure
is created together with its Wasm instance, at a small fixed cost and with
no runtime
penalty.
(In the future, it might make sense to combine m_type and
m_typeDependencies in
WebAssemblyGCStructure and simplify instance creation by not requiring
expanded and
unexpanded types separately. However, at this time this code has
outstanding parallel
changes in two branches, so it will be easier to do such cleanups after
these changes
converge).
Canonical link: https://commits.webkit.org/297297.432@safari-7622-branch
Identifier: 301765.155@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.344@webkitglib/2.50
Commit: 81c06b0d1e4ab07e6ea569c17f67b7e6f908cb06
https://github.com/WebKit/WebKit/commit/81c06b0d1e4ab07e6ea569c17f67b7e6f908cb06
Author: Chris Dumez <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A LayoutTests/fast/loader/navigate-event-crash-expected.txt
A LayoutTests/fast/loader/navigate-event-crash.html
A LayoutTests/fast/loader/navigate-event-info-gc-expected.txt
A LayoutTests/fast/loader/navigate-event-info-gc.html
M Source/WebCore/WebCore.xcodeproj/project.pbxproj
M Source/WebCore/bindings/js/JSNavigationCustom.cpp
M Source/WebCore/page/Navigation.cpp
M Source/WebCore/page/Navigation.h
M Source/WebCore/page/Navigation.idl
Log Message:
-----------
Cherry-pick 301765.190@safari-7623-branch (bb34e112b85b).
https://bugs.webkit.org/show_bug.cgi?id=301560
Use after free in NavigateEvent()
https://bugs.webkit.org/show_bug.cgi?id=301560
rdar://163476354
Reviewed by Ryosuke Niwa.
NavigationAPIMethodTracker was storing a raw JSValue as data member, with
nothing keeping it alive. Use JSValueInWrappedObject instead and visit
it whenever the Navigation object gets visited.
* LayoutTests/fast/loader/navigate-event-crash-expected.txt: Added.
* LayoutTests/fast/loader/navigate-event-crash.html: Added.
* LayoutTests/fast/loader/navigate-event-info-gc-expected.txt: Added.
* LayoutTests/fast/loader/navigate-event-info-gc.html: Added.
* Source/WebCore/Sources.txt:
* Source/WebCore/WebCore.xcodeproj/project.pbxproj:
* Source/WebCore/bindings/js/JSNavigationCustom.cpp: Added.
(WebCore::JSNavigation::visitAdditionalChildren):
* Source/WebCore/page/Navigation.cpp:
(WebCore::Navigation::maybeSetUpcomingNonTraversalTracker):
(WebCore::Navigation::addUpcomingTraverseAPIMethodTracker):
(WebCore::Navigation::navigate):
(WebCore::Navigation::performTraversal):
(WebCore::Navigation::updateForNavigation):
(WebCore::Navigation::promoteUpcomingAPIMethodTracker):
(WebCore::Navigation::cleanupAPIMethodTracker):
(WebCore::Navigation::upcomingTraverseMethodTracker const):
(WebCore::Navigation::abortOngoingNavigation):
(WebCore::Navigation::innerDispatchNavigateEvent):
(WebCore::Navigation::visitAdditionalChildren):
* Source/WebCore/page/Navigation.h:
* Source/WebCore/page/Navigation.idl:
Identifier: 301765.190@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.345@webkitglib/2.50
Commit: d8ab47e336d727d56f5e00228fcb507eaec4cd99
https://github.com/WebKit/WebKit/commit/d8ab47e336d727d56f5e00228fcb507eaec4cd99
Author: Yusuke Suzuki <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
A JSTests/wasm/stress/zero-clear-bbq-address.js
M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT64.h
Log Message:
-----------
Cherry-pick 301765.193@safari-7623-branch (e94cf07c8a92).
https://bugs.webkit.org/show_bug.cgi?id=301634
[JSC] BBQ should not assume Int32 operands are StrictInt32
https://bugs.webkit.org/show_bug.cgi?id=301634
rdar://163201617
Reviewed by Yijia Huang and Dan Hecht.
OMG wasm call and wasm return are using Patchpoint, but these arguments
do not guarantee that Int32 is StrictInt32. But doing it causes massive
performance regression in JetStream3. This makes sense: in most of
cases, Int32 high bits do not matter since users are doing Int32
arithmetics and that ignores high bits. The current "def" side
zero-clearing is too inefficient since B3 is tracking zero-clear def in
Air. And it attempts to remove them when possible. So if "use" side does
zero-clearing, then B3 can optimize it (removing or hoisting). But "def"
side takes this cost early, and B3 cannot do anything when it is
transfered at a function call boundary (arguments and return values).
This is a reverse course of rdar://149685355. BBQ should not assume
Int32's high bits are cleared. Current approach is pessimising OMG to get
a bit cleaner BBQ for this very particular opcodes, and this is not great.
BBQ should ensure that whenever Int32 is used as a pointer-width, BBQ
should zero-extend, and all DFG / FTL are already doing so.
* JSTests/wasm/stress/zero-clear-bbq-address.js: Added.
(main):
* Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::emitAllocateGCArrayUninitialized):
* Source/JavaScriptCore/wasm/WasmBBQJIT64.h:
(JSC::Wasm::BBQJITImpl::BBQJIT::emitCheckAndPrepareAndMaterializePointerApply):
Identifier: 301765.193@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.346@webkitglib/2.50
Commit: bde11f734296d5aea14b759bc91dd51d1221cfb4
https://github.com/WebKit/WebKit/commit/bde11f734296d5aea14b759bc91dd51d1221cfb4
Author: Jean-Yves Avenard <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/WebCore/Modules/mediasource/MediaSource.cpp
M Source/WebCore/html/HTMLMediaElement.cpp
Log Message:
-----------
Cherry-pick 301765.208@safari-7623-branch (4c366859c744).
https://bugs.webkit.org/show_bug.cgi?id=301674
WebCore::MediaSource::~MediaSource; WebCore::MediaSource::~MediaSource;
mpark::detail::destructor::~destructor
https://bugs.webkit.org/show_bug.cgi?id=301674
rdar://163479310
Reviewed by Jer Noble.
In 285110@main, we handled the case where the MediaSource object would be
destructed and the attempt to ref itself, causing an assertion. 285110@main
handled the case where the resource selection algorithm had already run
and HTMLMediaElement::m_mediaSource would have already been set.
It is apparently possible however, for the HTMLMediaElement to be GCed
before the
resource selection algorithm got to run, in which case the MediaSource
reference
is hold in HTMLMediaElement::m_mediaProvider hold the MediaSource.
For this to occur, the HTMLMediaElement to which we just set the srcObj
attribute
must be GCed within that same runloop.
We now handle such case.
Additionally we exit early in MediaSource::detachFromElement if the
MediaSource
is no yet or no longer attached to any element, which allows to call this
method multiple times on the same MediaSource object.
* Source/WebCore/Modules/mediasource/MediaSource.cpp:
(WebCore::MediaSource::detachFromElement):
* Source/WebCore/html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::~HTMLMediaElement):
Identifier: 301765.208@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.347@webkitglib/2.50
Commit: 93aabbdaf524717941d917849d0a15ba492a3e3d
https://github.com/WebKit/WebKit/commit/93aabbdaf524717941d917849d0a15ba492a3e3d
Author: Daniel Liu <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/JavaScriptCore/bytecode/CodeBlock.cpp
Log Message:
-----------
Cherry-pick 301765.223@safari-7623-branch (178c4858a787).
https://bugs.webkit.org/show_bug.cgi?id=301726
CodeBlock jettison should deref, rather than reset, StructureStubInfo
https://bugs.webkit.org/show_bug.cgi?id=301726
rdar://162487754
Reviewed by Yusuke Suzuki and Mark Lam.
Other CodeBlocks may still be referring to that StructureStubInfo, thus
we cannot just blindly reset it. Instead, we'll deref it, which updates
the reference count to indicate we're no longer using it.
* Source/JavaScriptCore/bytecode/CodeBlock.cpp:
(JSC::CodeBlock::jettison):
Identifier: 301765.223@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.348@webkitglib/2.50
Commit: 555594057c23463361108510186af89790d33b77
https://github.com/WebKit/WebKit/commit/555594057c23463361108510186af89790d33b77
Author: Dan Hecht <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/bmalloc/libpas/src/libpas/pas_local_allocator_inlines.h
M Source/bmalloc/libpas/src/libpas/pas_segregated_heap.c
M Source/bmalloc/libpas/src/libpas/pas_segregated_heap.h
M Source/bmalloc/libpas/src/test/ExpendableMemoryTests.cpp
Log Message:
-----------
Cherry-pick 301765.261@safari-7623-branch (1164239a5354).
https://bugs.webkit.org/show_bug.cgi?id=301940
[libpas] fix lock-free reads of the medium directory tuple table
https://bugs.webkit.org/show_bug.cgi?id=301940
rdar://163964480
Reviewed by Yusuke Suzuki and Keith Miller.
Some paths read the medium directory tuple table using a lock-free
algorithm. However, they return a pointer into this table and
load from the pointer after checking for mutations to the table,
potentially reading the wrong entry.
Fix this by performing the read in the lock free critical section
(unless the heap lock is held along the path, in which case the pointer
is still used).
Thanks to Phil Pizlo for finding the issue and proposing the fix.
Testing: added asserts to verify this race condition
* Source/bmalloc/libpas/src/libpas/pas_local_allocator_inlines.h:
(pas_local_allocator_try_allocate):
* Source/bmalloc/libpas/src/libpas/pas_segregated_heap.c:
(medium_directory_tuple_for_index_impl):
(medium_directory_tuple_for_index_with_lock):
(pas_segregated_heap_medium_directory_tuple_for_index):
(pas_segregated_heap_medium_allocator_index_for_index):
(pas_segregated_heap_medium_size_directory_for_index):
(pas_segregated_heap_ensure_allocator_index):
(pas_segregated_heap_ensure_size_directory_for_size):
* Source/bmalloc/libpas/src/libpas/pas_segregated_heap.h:
(pas_segregated_heap_medium_directory_result_create_empty):
Identifier: 301765.261@safari-7623-branch
Canonical link: https://commits.webkit.org/298234.349@webkitglib/2.50
Commit: 5d91e9ca0577cbe836c67be24cd0a80f1e14637f
https://github.com/WebKit/WebKit/commit/5d91e9ca0577cbe836c67be24cd0a80f1e14637f
Author: Kimmo Kinnunen <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/ThirdParty/ANGLE/src/libANGLE/capture/capture_gles_2_0_params.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/formatutils.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/formatutils.h
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/d3d/FramebufferD3D.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/d3d/d3d11/Image11.cpp
M
Source/ThirdParty/ANGLE/src/libANGLE/renderer/d3d/d3d11/TextureStorage11.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/gl/FramebufferGL.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/gl/TextureGL.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/FrameBufferMtl.mm
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/TextureMtl.mm
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/null/FramebufferNULL.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/vulkan/vk_helpers.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/wgpu/TextureWgpu.cpp
M Source/ThirdParty/ANGLE/src/libANGLE/renderer/wgpu/wgpu_helpers.cpp
M Source/ThirdParty/ANGLE/src/tests/gl_tests/TextureTest.cpp
Log Message:
-----------
Cherry-pick 02d2cd92abb8. <bug>
ANGLE: Avoid using UNPACK_SKIP_IMAGES, UNPACK_IMAGE_HEIGHT for non-3d
textures <rdar://164155603>
Reviewed by Mike Wyrzykowski.
Avoid using UNPACK_SKIP_IMAGES, UNPACK_IMAGE_HEIGHT when uploading
textures with TexImage2D. The UNPACK_IMAGE_HEIGHT was being
being used in Metal texture uploads even when slices was == 1. This
causes validation failure. During TexImage2D the values are not
validated at ANGLE validation level since they are not supposed to
affect anything.
Consider pattern:
formatInfo.computeRowPitch(type, area.width, unpack.alignment,
unpack.rowLength, &rowPitch);
formatInfo.computeDepthPitch(area.height, unpack.imageHeight,
sourceRowPitch, &depthPitch);
formatInfo.computeSkipBytes(type, sourceRowPitch, sourceDepthPitch,
unpack, index.usesTex3D(), &sourceSkipBytes);
Computing the depthPitch would not take into account wheter the
originating command was Tex*Image2D or Tex*Image3D. It would
unconditionally use UNPACK_SKIP_IMAGES, UNPACK_IMAGE_HEIGHT.
The computed depthPitch would then be used to size buffers, read amounts
and write amounts by the implementations.
Combine the pattern to InternalFormat::computeRowDepthSkipBytes(...)
call that uses PixelUnpackState::imageHeight,
PixelUnpackState::imageSkip only for 3D texture uploads.
Compine the pack buffer parameter resolution logic other to function:
InternalFormat::computeRowSkipBytes(..., PixelPackState&,...).
* Source/ThirdParty/ANGLE/src/libANGLE/Context.cpp:
(gl::Context::texImage2D):
* Source/ThirdParty/ANGLE/src/libANGLE/capture/capture_gles_2_0_params.cpp:
(gl::CaptureTexImage2D_pixels):
* Source/ThirdParty/ANGLE/src/libANGLE/formatutils.cpp:
(gl::InternalFormat::computeRowDepthSkipBytes const):
(gl::InternalFormat::computeSkipBytes const):
(gl::InternalFormat::computePackUnpackEndByte const):
* Source/ThirdParty/ANGLE/src/libANGLE/formatutils.h:
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/d3d/d3d11/Image11.cpp:
(rx::Image11::loadData):
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/gl/TextureGL.cpp:
(rx::TextureGL::setSubImageRowByRowWorkaround):
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/TextureMtl.mm:
(rx::TextureMtl::setSubImageImpl):
* Source/ThirdParty/ANGLE/src/libANGLE/renderer/vulkan/vk_helpers.cpp:
(rx::vk::ImageHelper::calculateBufferInfo):
Change-Id: Iefac5156412787709ee577a9a71f19a480778e78
Identifier: 301765.268@safari-7623-branch
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.350@webkitglib/2.50
Commit: e8ea9a9e926862a48342db21269980c33a70086d
https://github.com/WebKit/WebKit/commit/e8ea9a9e926862a48342db21269980c33a70086d
Author: Yusuke Suzuki <[email protected]>
Date: 2025-12-15 (Mon, 15 Dec 2025)
Changed paths:
M Source/JavaScriptCore/dfg/DFGStoreBarrierInsertionPhase.cpp
Log Message:
-----------
Cherry-pick 0cfb4a033f7e. https://bugs.webkit.org/show_bug.cgi?id=302502
[JSC] StoreBarrierInsertionPhase's escape should mark all transitively
incoming values to phi
https://bugs.webkit.org/show_bug.cgi?id=302502
rdar://164593392
Reviewed by Keith Miller and Mark Lam.
Let's have the following code.
BB#1
a: NewObject
b: NewObject
...
c: Upsilon(@b, ^f)
Branch(BB#2, BB#3)
BB#2
...
d: Something
e: Upsilon(@d, ^f)
Jump(BB#3)
BB#3
f: Phi(@c, @e)
...
g: PutByOffset(@a, @f)
...
h: PutByOffset(@b, ...)
...
Since @b can cause GC, epoch is bumped and @a can be in the old region.
As a result, in @g, we should insert a StoreBarrier after that. And
because this old @a can leak @f to the world scanned by concurrent GC,
we need to escape @f and subsequent code must insert a StoreBarrier when
@f's properties are modified. However we are marking @f, but not marking
all incoming values @b and @d propagated through Upsilon. As a result,
@h can use @b directly (since BB#3 is dominated by BB#1, it is fine),
and we failed to insert a StoreBarrier after @h since @b is not marked!
This patch fixes it by marking all transitively incoming values for the
escaped one. The code will mark the node itself, and then mark all
incoming nodes when the node is Phi.
* Source/JavaScriptCore/dfg/DFGStoreBarrierInsertionPhase.cpp:
Identifier: 301765.315@safari-7623-branch
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/298234.351@webkitglib/2.50
Commit: 73d61a51f8f18299fc1e8cba9181fdd5078be84e
https://github.com/WebKit/WebKit/commit/73d61a51f8f18299fc1e8cba9181fdd5078be84e
Author: Adrian Perez de Castro <[email protected]>
Date: 2025-12-16 (Tue, 16 Dec 2025)
Changed paths:
M Source/WebCore/Modules/mediastream/gstreamer/GStreamerWebRTCUtils.cpp
M Source/WebCore/page/linux/ResourceUsageThreadLinux.cpp
M Source/WebCore/platform/graphics/filters/FilterImage.h
M Source/WebCore/platform/graphics/gbm/MemoryMappedGPUBuffer.cpp
M Source/WebCore/platform/graphics/gstreamer/VideoFrameGStreamer.cpp
M Source/WebCore/platform/graphics/skia/SkiaReplayCanvas.cpp
M Source/WebCore/platform/graphics/skia/SkiaReplayCanvas.h
M Source/WebCore/platform/graphics/skia/SkiaSystemFallbackFontCache.cpp
M Source/WebCore/platform/graphics/skia/SkiaSystemFallbackFontCache.h
M Source/WebKit/UIProcess/XR/openxr/OpenXRInputSource.cpp
M Source/WebKit/UIProcess/XR/openxr/OpenXRLayer.cpp
M Source/WebKit/UIProcess/glib/DRMMainDevice.cpp
Log Message:
-----------
Unreviewed. Fix building with Clang due to unsafe buffer usage errors.
Sprinkle WTF_IGNORE_WARNINGS_IN_THIRD_PARTY_CODE_{BEGIN,END} and
WTF_ALLOW_UNSAFE_BUFFER_{BEGIN,END} as needed to prevent Clang
erroring/warning during the build.
Canonical link: https://commits.webkit.org/298234.352@webkitglib/2.50
Commit: 0de4ba6f7682bf8501eeecbaf37706f0de91811c
https://github.com/WebKit/WebKit/commit/0de4ba6f7682bf8501eeecbaf37706f0de91811c
Author: Adrian Perez de Castro <[email protected]>
Date: 2025-12-16 (Tue, 16 Dec 2025)
Changed paths:
M Source/WebCore/page/Quirks.cpp
M Source/WebCore/platform/gamepad/manette/ManetteGamepadProvider.cpp
M Source/WebCore/rendering/line/LineWidth.cpp
M Source/WebCore/style/values/grid/StyleGridPositionsResolver.cpp
Log Message:
-----------
Unreviewed. Remove unused definitions.
This fixes builds with warnings-as-errors.
* Source/WebCore/page/Quirks.cpp:
(WebCore::Quirks::scriptToEvaluateBeforeRunningScriptFromURL): Move
chromeUserAgentScript into the corresponding PLATFORM(IOS_FAMILY) guard.
* Source/WebCore/platform/gamepad/manette/ManetteGamepadProvider.cpp:
Remove unused connectionDelayInterval constant.
* Source/WebCore/rendering/line/LineWidth.cpp:
(WebCore::availableWidthAtOffset): Deleted.
* Source/WebCore/style/values/grid/StyleGridPositionsResolver.cpp:
(WebCore::Style::isColumnSide): Deleted.
Canonical link: https://commits.webkit.org/298234.353@webkitglib/2.50
Commit: 2489fd123c4f1008d3fd59734672037cca4742b1
https://github.com/WebKit/WebKit/commit/2489fd123c4f1008d3fd59734672037cca4742b1
Author: Adrian Perez de Castro <[email protected]>
Date: 2025-12-16 (Tue, 16 Dec 2025)
Changed paths:
M Source/WebCore/svg/SVGUnknownElement.h
Log Message:
-----------
Unreviewed. Non-unified build fixes.
* Source/WebCore/svg/SVGUnknownElement.h: Add missing includes.
Canonical link: https://commits.webkit.org/298234.354@webkitglib/2.50
Commit: 09b58d958e2737089391b855a55c0347e2fccba7
https://github.com/WebKit/WebKit/commit/09b58d958e2737089391b855a55c0347e2fccba7
Author: Adrian Perez de Castro <[email protected]>
Date: 2025-12-16 (Tue, 16 Dec 2025)
Changed paths:
M Source/WebKit/UIProcess/XR/openxr/OpenXRLayer.cpp
Log Message:
-----------
Unreviewed. Avoid compiler warning about missing initializer braces.
* Source/WebKit/UIProcess/XR/openxr/OpenXRLayer.cpp:
(WebKit::OpenXRLayerProjection::startFrame): Add missing braces around
compound initializer.
Canonical link: https://commits.webkit.org/298234.355@webkitglib/2.50
Compare: https://github.com/WebKit/WebKit/compare/bdac6690294a...09b58d958e27
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
