Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 6cd0f1e70c125a9811f79a5ab26c5458583a51eb
https://github.com/WebKit/WebKit/commit/6cd0f1e70c125a9811f79a5ab26c5458583a51eb
Author: Dan Hecht <[email protected]>
Date: 2025-12-13 (Sat, 13 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:
-----------
[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):
Originally-landed-as: 301765.30@safari-7623-branch (8b1890640ebd).
rdar://166340517
Canonical link: https://commits.webkit.org/304414@main
Commit: 26d50a4d4b2df76c67b95603f9a96ebdc586de9b
https://github.com/WebKit/WebKit/commit/26d50a4d4b2df76c67b95603f9a96ebdc586de9b
Author: Yusuke Suzuki <[email protected]>
Date: 2025-12-13 (Sat, 13 Dec 2025)
Changed paths:
A JSTests/wasm/stress/bbq-array-set-consume.js
M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp
Log Message:
-----------
[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):
Originally-landed-as: 301765.31@safari-7623-branch (3de827f24294).
rdar://166340230
Canonical link: https://commits.webkit.org/304415@main
Commit: 8445e94cd3b6762a963a434468526492de4e0e76
https://github.com/WebKit/WebKit/commit/8445e94cd3b6762a963a434468526492de4e0e76
Author: Yusuke Suzuki <[email protected]>
Date: 2025-12-13 (Sat, 13 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:
-----------
[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):
Originally-landed-as: 301765.58@safari-7623-branch (8895b65ce8a3).
rdar://166340169
Canonical link: https://commits.webkit.org/304416@main
Commit: e6d893deee18f27f15917321f75c8bc41d9b1fbe
https://github.com/WebKit/WebKit/commit/e6d893deee18f27f15917321f75c8bc41d9b1fbe
Author: Jessica Lee <[email protected]>
Date: 2025-12-13 (Sat, 13 Dec 2025)
Changed paths:
M Source/WebKitLegacy/mac/WebView/WebView.mm
Log Message:
-----------
Apply settings for captive portal mode in UIWebView (LegacyWebKit)
https://bugs.webkit.org/show_bug.cgi?id=300819
rdar://161118215
Reviewed by Brent Fulgham, Wenson Hsieh, and Ryosuke Niwa.
We should propogate lockdown mode settings in WebkitLegacy.
There was also a timing issue where somehow there was thread contention
for the web thread during _willStartRenderingUpdateDisplay. We have added
a WebThreadLock() call to mitigate this.
* Source/WebKitLegacy/mac/WebView/WebView.mm:
(isLockdownModeEnabled):
(-[WebView _preferencesChanged:]):
(-[WebView _willStartRenderingUpdateDisplay]):
Originally-landed-as: 301765.59@safari-7623-branch (a2d4d3de8a51).
rdar://166340163
Canonical link: https://commits.webkit.org/304417@main
Commit: 20c98ec7d3f9b7fb490158e42f3c23b39ca725c4
https://github.com/WebKit/WebKit/commit/20c98ec7d3f9b7fb490158e42f3c23b39ca725c4
Author: Frédéric Wang <[email protected]>
Date: 2025-12-13 (Sat, 13 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:
-----------
ASAN_ILL | Layout::LineBuilder::initialize;
Layout::LineBuilder::layoutInlineContent;
Layout::IntrinsicWidthHandler::computedIntrinsicWidthForConstrain
https://bugs.webkit.org/show_bug.cgi?id=298301
rdar://154646612
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.
Originally-landed-as: [email protected] (e78d76a4e51b).
rdar://166340697
Canonical link: https://commits.webkit.org/304418@main
Compare: https://github.com/WebKit/WebKit/compare/75bf730541b2...20c98ec7d3f9
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
