Bug 214932

<rdar://problem/66300050>

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

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

(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.

(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?

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

Created attachment 409504 [details]
Patch

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

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

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

(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

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

Re-opened since this is blocked by bug 216923

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