[webkit-changes] [WebKit/WebKit] 0105c6: REGRESSION(264489 at main): wpt/webaudio/the-audio-ap...
Chris Dumez
noreply at github.com
Fri Jun 30 17:55:37 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0105c62ef91b4f82e7f09f42287bbd445ed65ddc
https://github.com/WebKit/WebKit/commit/0105c62ef91b4f82e7f09f42287bbd445ed65ddc
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-06-30 (Fri, 30 Jun 2023)
Changed paths:
M LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audioworklet-interface/audioworkletnode-onerror.https-expected.txt
M Source/WebCore/Modules/webaudio/AudioWorkletGlobalScope.cpp
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
REGRESSION(264489 at main): wpt/webaudio/the-audio-api/the-audioworklet-interface/audioworkletnode-onerror.https.html
https://bugs.webkit.org/show_bug.cgi?id=258209
rdar://110900370
Reviewed by Jer Noble.
The test was passing a blob inside the options passed to the AudioWorklet
processor constructor and expecting a processorerror event to get fired.
The reason for this expectation is that Blobs (as well as all other
non-builtin JS types) are not exposed to AudioWorklet and we thus expect
the deserialization of the Blob to fail for the AudioWorkletGlobalScope.
To address the issue, we now check the deserialized type inside
SerializedScriptValue's CloneDeserializer to make sure the type is
exposed to the current global scope. If it isn't, we fail deserialization.
We now also do proper deserialization error handling inside
AudioWorkletGlobalScope::createProcessor().
* LayoutTests/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audioworklet-interface/audioworkletnode-onerror.https-expected.txt:
* Source/WebCore/Modules/webaudio/AudioWorkletGlobalScope.cpp:
(WebCore::AudioWorkletGlobalScope::createProcessor):
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::isTypeExposedToGlobalObject):
(WebCore::CloneDeserializer::readTerminal):
Canonical link: https://commits.webkit.org/265678@main
More information about the webkit-changes
mailing list