Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: b4e5456e5a949a61c0cef77215b57e0ae362da7d
https://github.com/WebKit/WebKit/commit/b4e5456e5a949a61c0cef77215b57e0ae362da7d
Author: Sosuke Suzuki <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
A JSTests/modules/arbitrary-module-names-star.js
A JSTests/modules/arbitrary-module-names-star/export.js
M JSTests/test262/expectations.yaml
M Source/JavaScriptCore/parser/NodesAnalyzeModule.cpp
M Source/JavaScriptCore/parser/Parser.cpp
M Source/JavaScriptCore/runtime/CommonIdentifiers.cpp
M Source/JavaScriptCore/runtime/CommonIdentifiers.h
Log Message:
-----------
Cherry-pick 310776@main (46479ddbd5e6).
https://bugs.webkit.org/show_bug.cgi?id=311509
[JSC] `import { "*" as x }` should not be treated as a namespace import
https://bugs.webkit.org/show_bug.cgi?id=311509
Reviewed by Yusuke Suzuki.
ES2022 introduced ModuleExportName, allowing arbitrary string literals as
import/export binding names. JSC was using the public string "*" as a
sentinel to mark NamespaceImport (`import * as ns`) in ImportSpecifier
nodes, which collides with the user-written `import { "*" as x }`.
The export side (`export * as ns`) was already fixed to use
starNamespacePrivateName when ModuleExportName was implemented, but the
import side was missed. This patch aligns the import side to use the same
PrivateName sentinel, and removes the now-unused timesIdentifier.
Tests: JSTests/modules/arbitrary-module-names-star.js
JSTests/modules/arbitrary-module-names-star/export.js
* JSTests/modules/arbitrary-module-names-star.js: Added.
* JSTests/modules/arbitrary-module-names-star/export.js: Added.
* JSTests/test262/expectations.yaml:
* Source/JavaScriptCore/parser/NodesAnalyzeModule.cpp:
(JSC::ImportDeclarationNode::analyzeModule):
* Source/JavaScriptCore/parser/Parser.cpp:
(JSC::Parser<LexerType>::parseImportClauseItem):
* Source/JavaScriptCore/runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::CommonIdentifiers):
* Source/JavaScriptCore/runtime/CommonIdentifiers.h:
Canonical link: https://commits.webkit.org/310776@main
Canonical link: https://commits.webkit.org/305877.393@webkitglib/2.52
Commit: ba67198703cc9a5841857f15a5805c8f24da0a55
https://github.com/WebKit/WebKit/commit/ba67198703cc9a5841857f15a5805c8f24da0a55
Author: Antoine Quint <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
A
LayoutTests/webanimations/custom-effect/custom-effect-set-to-null-in-callback-expected.txt
A
LayoutTests/webanimations/custom-effect/custom-effect-set-to-null-in-callback.html
M Source/WebCore/animation/AnimationEffect.h
M Source/WebCore/animation/KeyframeEffect.h
M Source/WebCore/animation/WebAnimation.cpp
Log Message:
-----------
Cherry-pick 310785@main (106edd02a3cc).
https://bugs.webkit.org/show_bug.cgi?id=311072
[web-animations] setting effect to null in `CustomEffect` callback leads to
a crash
https://bugs.webkit.org/show_bug.cgi?id=311072
rdar://173671661
Reviewed by Anne van Kesteren.
The callback for a `CustomEffect`, which is called under
`CustomEffect::animationDidTick()`,
can reset the associated animation's effect to null. We must make sure that
the subsequent
call to `AnimationEffect::animationBecameReady()` is performed on a valid
effect.
Since the only concrete implementation of
`AnimationEffect::animationBecameReady()` was for
`KeyframeEffect`, we move this function to `KeyframeEffect` instead of
being a virtual function
on the superclass.
Test: webanimations/custom-effect/custom-effect-set-to-null-in-callback.html
*
LayoutTests/webanimations/custom-effect/custom-effect-set-to-null-in-callback-expected.txt:
Added.
*
LayoutTests/webanimations/custom-effect/custom-effect-set-to-null-in-callback.html:
Added.
* Source/WebCore/animation/AnimationEffect.h:
(WebCore::AnimationEffect::animationDidTick):
(WebCore::AnimationEffect::animationBecameReady): Deleted.
* Source/WebCore/animation/KeyframeEffect.h:
* Source/WebCore/animation/WebAnimation.cpp:
(WebCore::WebAnimation::tick):
Canonical link: https://commits.webkit.org/310785@main
Canonical link: https://commits.webkit.org/305877.394@webkitglib/2.52
Commit: 568afceb5b124dddda77eb23a88a40c4eed3743e
https://github.com/WebKit/WebKit/commit/568afceb5b124dddda77eb23a88a40c4eed3743e
Author: Chris Dumez <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/dom/ranges/Range-extractContents-dynamic-end-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/dom/ranges/Range-extractContents-dynamic-end.html
M Source/WebCore/dom/Range.cpp
Log Message:
-----------
Cherry-pick 310770@main (9dac73538145).
https://bugs.webkit.org/show_bug.cgi?id=311700
Range.extractContents should not extract out-of-bounds nodes if end
container is removed during extraction
https://bugs.webkit.org/show_bug.cgi?id=311700
Reviewed by Anne van Kesteren.
When Range::extractContents() processes nodes, removing an iframe can fire
a synchronous
unload event. If that event handler removes the Range's end container from
the DOM, the
extraction loop loses its end boundary (processEnd becomes null) and
continues extracting
all remaining siblings of the common root, including nodes that were
outside the original range.
Fix this by skipping the middle node processing when processEnd is null and
the original
end container is no longer a descendant of the common root.
Test:
imported/w3c/web-platform-tests/dom/ranges/Range-extractContents-dynamic-end.html
This test was contributed upstream by Blink. It fails in shipping Safari
but passes with
this fix. This is thus aligning our behavior with Blink.
*
LayoutTests/imported/w3c/web-platform-tests/dom/ranges/Range-extractContents-dynamic-end-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/dom/ranges/Range-extractContents-dynamic-end.html:
Added.
* Source/WebCore/dom/Range.cpp:
(WebCore::Range::processContents):
Canonical link: https://commits.webkit.org/310770@main
Canonical link: https://commits.webkit.org/305877.395@webkitglib/2.52
Commit: afc70fa5b9aa60bd1e1d395fa95676310c8a425b
https://github.com/WebKit/WebKit/commit/afc70fa5b9aa60bd1e1d395fa95676310c8a425b
Author: Anand Srinivasan <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
A JSTests/stress/validate-does-gc-heap-bigint-compare-watchdog.js
M Source/JavaScriptCore/dfg/DFGDoesGCCheck.cpp
M Source/JavaScriptCore/dfg/DFGDoesGCCheck.h
M Source/JavaScriptCore/runtime/VM.cpp
Log Message:
-----------
Cherry-pick 310722@main (f5b52841f6b5).
https://bugs.webkit.org/show_bug.cgi?id=311229
Reset doesGC expectation upon VM termination to avoid stale assertion
https://bugs.webkit.org/show_bug.cgi?id=311229
rdar://172191300
Reviewed by Yusuke Suzuki.
If the VM terminates in the middle of DFG/FTL JIT code, right now
m_doesGC contains the value corresponding to the last node executed. If
this happens, the next time a thread tries to acquire a JSLock it will
read the stale value in m_doesGC and potentially crash. OSR exits from
JIT code already reset the value to true, so throwTerminationException
should do the same thing.
Test: JSTests/stress/validate-does-gc-heap-bigint-compare-watchdog.js
* JSTests/stress/validate-does-gc-heap-bigint-compare-watchdog.js: Added.
(vm.useJIT):
* Source/JavaScriptCore/dfg/DFGDoesGCCheck.cpp:
(JSC::DFG::DoesGCCheck::verifyCanGC):
* Source/JavaScriptCore/dfg/DFGDoesGCCheck.h:
* Source/JavaScriptCore/runtime/VM.cpp:
(JSC::VM::throwTerminationException):
Canonical link: https://commits.webkit.org/310722@main
Canonical link: https://commits.webkit.org/305877.396@webkitglib/2.52
Commit: 4bef4b69e00616fdb55b1820a75417c98b4460eb
https://github.com/WebKit/WebKit/commit/4bef4b69e00616fdb55b1820a75417c98b4460eb
Author: Chris Dumez <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/dom/nodes/ParentNode-append-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/dom/nodes/ParentNode-append.html
M Source/WebCore/dom/Node.cpp
Log Message:
-----------
Cherry-pick 310807@main (eda04d24c262).
https://bugs.webkit.org/show_bug.cgi?id=311708
ParentNode.append() should de-duplicate nodes when the same node is passed
multiple times
https://bugs.webkit.org/show_bug.cgi?id=311708
Reviewed by Ryosuke Niwa.
When the same node is passed multiple times to ParentNode.append() (e.g.,
append(x, y, x)),
convertNodesOrStringsIntoNodeVector() would produce a vector with duplicate
entries. This
caused a crash in appendChildCommon() which asserts that the node has no
parent, since the
first insertion already parented the node.
Fix by de-duplicating nodes in convertNodesOrStringsIntoNodeVector(),
keeping only the last
occurrence of each duplicate node. This matches the spec behavior as if a
temporary
DocumentFragment was used, and matches Blink and Gecko.
No new tests, covered by
imported/w3c/web-platform-tests/dom/nodes/ParentNode-append.html
which was resync'd from upstream to gain test coverage. This test is
already passing in
Chrome and Firefox so this aligns our behavior with them.
*
LayoutTests/imported/w3c/web-platform-tests/dom/nodes/ParentNode-append-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/dom/nodes/ParentNode-append.html:
* Source/WebCore/dom/Node.cpp:
(WebCore::Node::convertNodesOrStringsIntoNodeVector):
Canonical link: https://commits.webkit.org/310807@main
Canonical link: https://commits.webkit.org/305877.397@webkitglib/2.52
Commit: 1e5332e094d45c3b412a33d3587fb353aeaaac25
https://github.com/WebKit/WebKit/commit/1e5332e094d45c3b412a33d3587fb353aeaaac25
Author: Karl Dubost <[email protected]>
Date: 2026-04-09 (Thu, 09 Apr 2026)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/svg/animations/syncbase-escaped-dots-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/svg/animations/syncbase-escaped-dots.html
M Source/WebCore/svg/animation/SVGSMILElement.cpp
Log Message:
-----------
Cherry-pick 310805@main (ba227e713a99).
https://bugs.webkit.org/show_bug.cgi?id=42871
Cannot escape Id-value in SVG animation timing attributes
https://bugs.webkit.org/show_bug.cgi?id=42871
rdar://94260935
Reviewed by Antoine Quint.
The SMIL3 specification (ยง Parsing timing specifiers) requires that
the reverse solidus character '\' be used to escape full stop '.'
characters within Id-values in timing attributes, so that dots in
element IDs are not confused with the Id/event separator.
For example, begin="my\.anim.end" should reference an element with
id="my.anim" and its "end" event. WebKit's parseCondition() used a
simple find('.') which matched the first dot regardless of escaping.
The fix finds the first unescaped dot (not preceded by '\') when
splitting the condition string, then strips backslash escapes from
the resolved element ID before lookup.
The tests use only .begin events since parseCondition() handles
begin and end attributes through the same code path.
Spec: https://www.w3.org/TR/SMIL3/smil-timing.html#q22
Test:
imported/w3c/web-platform-tests/svg/animations/syncbase-escaped-dots.html
*
LayoutTests/imported/w3c/web-platform-tests/svg/animations/syncbase-escaped-dots-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/svg/animations/syncbase-escaped-dots.html:
Added.
* Source/WebCore/svg/animation/SVGSMILElement.cpp:
(WebCore::SVGSMILElement::parseCondition):
Canonical link: https://commits.webkit.org/310805@main
Canonical link: https://commits.webkit.org/305877.398@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/522253d02265...1e5332e094d4
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
