web audio api outputs silence for 302 redirected resource in safari

[Nico]

In Safari, when an AudioContext is assigned to an audio element linked to a source with a 302 redirect in front of it, it outputs silence instead of normal audio without any errors in the log. By contrast, Chrome and Firefox have no issues with the same source.

See the demo with a simple visualizer and three options to attach the source and play the audio:

The first option links directly to the media source with a 200 response, assigns the AudioContext, and plays correctly in safari. 

The second option shows the issue when the link instead goes to a 302 redirect before going to the source audio, and outputs silence when the AudioContext is assigned.

The third option attaches the 302 redirect resource, but does not assign an AudioContext, and plays correctly in safari.

[Radar WebKit Bug Importer]

<rdar://problem/66300050>

[Chris Dumez]

I wonder if this is a regression from https://trac.webkit.org/changeset/231513/webkit.

[Nico]

I originally thought it was a CORS issue because the behavior seems to be specified in the web audio spec https://www.w3.org/TR/webaudio/#MediaElementAudioSourceOptions-security

But I haven't been able to resolve the issue with Access-Control-Allow-Origin, Access-Control-Expose-Headers, or Access-Control-Allow-Methods, which suggests to me that it's taking issue with the redirect itself for some reason

[Chris Dumez]

(In reply to Nico from comment #3)
> I originally thought it was a CORS issue because the behavior seems to be
> specified in the web audio spec
> https://www.w3.org/TR/webaudio/#MediaElementAudioSourceOptions-security
> 
> But I haven't been able to resolve the issue with
> Access-Control-Allow-Origin, Access-Control-Expose-Headers, or
> Access-Control-Allow-Methods, which suggests to me that it's taking issue
> with the redirect itself for some reason

Probably because the redirect is cross-origin. My bet is that a same-origin redirect would cause no issue.

[Nico]

(In reply to Chris Dumez from comment #4)
> (In reply to Nico from comment #3)
> > I originally thought it was a CORS issue because the behavior seems to be
> > specified in the web audio spec
> > https://www.w3.org/TR/webaudio/#MediaElementAudioSourceOptions-security
> > 
> > But I haven't been able to resolve the issue with
> > Access-Control-Allow-Origin, Access-Control-Expose-Headers, or
> > Access-Control-Allow-Methods, which suggests to me that it's taking issue
> > with the redirect itself for some reason
> 
> Probably because the redirect is cross-origin. My bet is that a same-origin
> redirect would cause no issue.


Gotcha — it's a bug and not a feature in this case, I hope?

[Chris Dumez]

This is caused by this check:
--- a/Source/WebCore/Modules/webaudio/MediaElementAudioSourceNode.cpp
+++ b/Source/WebCore/Modules/webaudio/MediaElementAudioSourceNode.cpp
@@ -107,8 +107,8 @@ void MediaElementAudioSourceNode::setFormat(size_t numberOfChannels, float sourc
 
 bool MediaElementAudioSourceNode::wouldTaintOrigin()
 {
-    if (!m_mediaElement->hasSingleSecurityOrigin())
-        return true;
+    //if (!m_mediaElement->hasSingleSecurityOrigin())
+    //    return true;
 
     if (m_mediaElement->didPassCORSAccessCheck())
         return false;

If I comment it out then it passes. Seems we are stricter than other browsers here and likely not matching the spec [1]. Hopefully, Jer and Youenn can help here. I think Jer made this change and Youenn is the Fetch expert (since Fetch spec is referenced here).

[1] https://www.w3.org/TR/webaudio/#MediaElementAudioSourceOptions-security

[Chris Dumez]

Created attachment 409504 [details]
Patch

[EWS]

commit-queue failed to commit attachment 409504 [details] to WebKit repository.

[EWS]

Committed r267507: <https://trac.webkit.org/changeset/267507>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 409504 [details].

[Aakash Jain]

(In reply to EWS from comment #9)
> Committed r267507: <https://trac.webkit.org/changeset/267507>
These 2 newly added tests are consistently failing on windows, as also indicated by EWS.

http/tests/security/webaudio-render-remote-audio-allowed-crossorigin-redirect.html
http/tests/security/webaudio-render-remote-audio-blocked-no-crossorigin-redirect.html

History: https://results.webkit.org/?suite=layout-tests&suite=layout-tests&test=js%2Fdom%2Ftransform-stream.html&test=http%2Ftests%2Fsecurity%2Fwebaudio-render-remote-audio-blocked-no-crossorigin-redirect.html&platform=win

[Aakash Jain]

Also these tests seems to be causing false positives on EWS as well.
e.g.: https://ews-build.webkit.org/#/builders/10/builds/37152

[WebKit Commit Bot]

Re-opened since this is blocked by bug 216923

[Chris Dumez]

Committed r267532: <https://trac.webkit.org/changeset/267532>