Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: d329e095fc8c1874f7df4910c6aada1589a96d7c
https://github.com/WebKit/WebKit/commit/d329e095fc8c1874f7df4910c6aada1589a96d7c
Author: Daniel Liu <[email protected]>
Date: 2025-11-12 (Wed, 12 Nov 2025)
Changed paths:
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
WasmFunctionParser should reference its signature
https://bugs.webkit.org/show_bug.cgi?id=299313
rdar://159603856
Reviewed by Yijia Huang and Keith Miller.
The WasmFunctionParser needs to ref its signature, or else we could end up
in a state where the signature is referenced by just the FunctionParser.
This patch updates m_signature to become a Ref<>, and edits all uses.
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parse):
(JSC::Wasm::FunctionParser<Context>::parseConstantExpression):
(JSC::Wasm::FunctionParser<Context>::parseBody):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
Originally-landed-as: 297297.469@safari-7622-branch (57746c0c92d0).
rdar://164213063
Canonical link: https://commits.webkit.org/302948@main
Commit: 58ba53ce85b1d71eba9de55554aafd5174af2510
https://github.com/WebKit/WebKit/commit/58ba53ce85b1d71eba9de55554aafd5174af2510
Author: Shu-yu Guo <[email protected]>
Date: 2025-11-12 (Wed, 12 Nov 2025)
Changed paths:
A JSTests/wasm/stress/simd-global-v128.js
M Source/JavaScriptCore/wasm/WasmSectionParser.cpp
Log Message:
-----------
[JSC] Fix Wasm global V128 parsing
https://bugs.webkit.org/show_bug.cgi?id=299331
rdar://161060967
Reviewed by Dan Hecht.
This PR fix Wasm global parsing which assumes that a V128 type always has a
constant vector, while it will only have it for constant SIMD opcodes.
Also fixes a related issue where when parsing SIMD constant initializers, the
extended SIMD opcode is treated as a non-extension opcode.
* JSTests/wasm/stress/simd-global-v128.js: Added.
Originally-landed-as: 297297.470@safari-7622-branch (be2f211a40c2).
rdar://164212908
Canonical link: https://commits.webkit.org/302949@main
Commit: cd945f0c3fe21294c6a5c277cd08dfce27e0b5f2
https://github.com/WebKit/WebKit/commit/cd945f0c3fe21294c6a5c277cd08dfce27e0b5f2
Author: Jer Noble <[email protected]>
Date: 2025-11-12 (Wed, 12 Nov 2025)
Changed paths:
M Source/WebCore/platform/cocoa/WebAVPlayerLayerView.mm
Log Message:
-----------
CRASH in WebAVPlayerLayerView_dealloc()
rdar://159231838
https://bugs.webkit.org/show_bug.cgi?id=299391
Reviewed by Andy Estes.
WebAVPlayerLayerView_dealloc() will sometimes cause a crash, due to the way
UIKit handles
UIViews and their CALayers, and the assumptions it makes about the view
hierarchy of
layer-backed UIViews.
When WebAVPlayerLayerView is given a videoView, it adds that videoView as its
own subview,
but adds the videoView's layer as the subview of its own playerLayer. During
teardown,
UIKit makes some assumptions about the superview/subview relationship of these
layers,
and will sometimes message a recently deallocated object.
To fix this bug, explicitly remove both the videoView and its layer from our
view and
layer hierarchy before -[UIView dealloc] is called. This should remove the
potential for
hierarchy confusion when the superclass's dealloc walks over its layers and
subviews.
* Source/WebCore/platform/cocoa/WebAVPlayerLayerView.mm:
(WebCore::WebAVPlayerLayerView_dealloc):
Originally-landed-as: 297297.471@safari-7622-branch (cc75478a578f).
rdar://164212857
Canonical link: https://commits.webkit.org/302950@main
Commit: 12a1f8fc725cbd16cfd9bdbfac9261be6e6b8985
https://github.com/WebKit/WebKit/commit/12a1f8fc725cbd16cfd9bdbfac9261be6e6b8985
Author: Keith Miller <[email protected]>
Date: 2025-11-12 (Wed, 12 Nov 2025)
Changed paths:
A LayoutTests/workers/worker-terminate-crash-expected.txt
A LayoutTests/workers/worker-terminate-crash.html
M Source/JavaScriptCore/runtime/JSObject.cpp
Log Message:
-----------
Creating ArrayStorage should DeferTerminationForAWhile during setup
https://bugs.webkit.org/show_bug.cgi?id=299499
rdar://156134962
Reviewed by Yijia Huang.
While converting to ArrayStorage if we handle a termination exception we can
leave the object
in an inconsistent state. We should just DeferTermination while doing this
transisition for
consistency.
Originally-landed-as: 297297.475@safari-7622-branch (552426566310).
rdar://164212378
Canonical link: https://commits.webkit.org/302951@main
Commit: 7a01f6cdef7ab92024c1d52118f321d41c9d02ce
https://github.com/WebKit/WebKit/commit/7a01f6cdef7ab92024c1d52118f321d41c9d02ce
Author: Vassili Bykov <[email protected]>
Date: 2025-11-12 (Wed, 12 Nov 2025)
Changed paths:
A JSTests/wasm/regress/299491.js
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
FunctionParser::resetLocalInitStackToHeight should capture the stack size
before iterating
https://bugs.webkit.org/show_bug.cgi?id=299491
rdar://161097132
Reviewed by Yijia Huang.
The loop is intended to repeat (stackSize - height) times, popping an element
each time.
Because popping an element reduces the current stack size, it should save the
size in a
local variable and use the saved value instead of retrieving it repeatedly while
iterating.
I'm also using this as an opportunity to make this and a couple of surrounding
multi-line
functions more readable by adding line breaks between them.
Originally-landed-as: 297297.473@safari-7622-branch (9a6b5549c26a).
rdar://164212488
Canonical link: https://commits.webkit.org/302952@main
Compare: https://github.com/WebKit/WebKit/compare/b011d3f4dbd8...7a01f6cdef7a
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
