Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: d0c18b999649f850d457a6e1d3f4f80dd5134f00
https://github.com/WebKit/WebKit/commit/d0c18b999649f850d457a6e1d3f4f80dd5134f00
Author: Chris Dumez <[email protected]>
Date: 2026-08-03 (Mon, 03 Aug 2026)
Changed paths:
M
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiocontext-interface/suspend-with-navigation-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-constantsourcenode-interface/constant-source-onended-not-connected-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-constantsourcenode-interface/constant-source-onended-not-connected.html
M Source/WebCore/Modules/webaudio/BaseAudioContext.cpp
M Tools/TestRunnerShared/TestFeatures.cpp
Log Message:
-----------
AudioScheduledSourceNode does not fire "ended" event when not connected to
the destination
https://bugs.webkit.org/show_bug.cgi?id=320884
Reviewed by Darin Adler.
WebKit renders the audio graph by pulling from the destination node, so a source
node is only processed if it is reachable from the destination. As a result, a
scheduled source node (ConstantSourceNode, OscillatorNode,
AudioBufferSourceNode)
that is started and stopped but never connected to the destination was never
processed: it never reached its stop time and never fired its "ended" event.
This
diverges from the specification and from Blink, which process active source
nodes
regardless of whether they are connected.
Fix this by registering a playing scheduled source node as an automatic pull
node,
WebKit's existing mechanism for nodes that must be processed on every render
quantum
even without a downstream connection. The node is registered when it begins
playback
and unregistered once it finishes or when the context is torn down. Nodes that
are
also connected to the destination are processed only once per quantum, since
AudioNode::processIfNecessary() already guards against reprocessing.
Removal happens in derefFinishedSourceNodes(), which runs on the audio thread,
so the
call is wrapped in a DisableMallocRestrictionsForCurrentThreadScope: removing
an entry
from the automatic pull node hash set can reallocate its backing store.
Add a dedicated regression test that starts and stops a ConstantSourceNode
without
connecting it to the destination and waits for the "ended" event; it times out
without this fix. This also makes imported/w3c/web-platform-tests/webaudio/
the-audio-api/the-audiocontext-interface/suspend-with-navigation.html pass,
since it
relies on an ended event from an unconnected source. That test also needs the
back/forward cache, so it is added to shouldUseBackForwardCache() in the test
harness.
*
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-constantsourcenode-interface/constant-source-onended-not-connected.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-constantsourcenode-interface/constant-source-onended-not-connected-expected.txt:
Added.
Add WPT test coverage for this. This test fails in shipping Safari but
passes in both Chrome and Firefox.
*
LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiocontext-interface/suspend-with-navigation-expected.txt:
Rebaseline bfcache test that was failing due to this bug. This test fails
in shipping Safari but passes in both Chrome and Firefox.
* Source/WebCore/Modules/webaudio/BaseAudioContext.cpp:
(WebCore::BaseAudioContext::uninitialize):
(WebCore::BaseAudioContext::derefFinishedSourceNodes):
(WebCore::BaseAudioContext::sourceNodeWillBeginPlayback):
* Tools/TestRunnerShared/TestFeatures.cpp:
(WTR::shouldUseBackForwardCache):
Canonical link: https://commits.webkit.org/318515@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications