New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with Firefox #6

Closed
tim-thimmaiah opened this Issue Apr 6, 2014 · 13 comments

Comments

Projects
None yet
6 participants
@tim-thimmaiah
Contributor

tim-thimmaiah commented Apr 6, 2014

Music doesn't seem to be playing in firefox

@tim-thimmaiah tim-thimmaiah added the bug label Apr 6, 2014

@tim-thimmaiah

This comment has been minimized.

Show comment
Hide comment
@tim-thimmaiah

tim-thimmaiah Apr 6, 2014

Contributor

Addressed soundManager issues with b74fc66

Seeing an issue caught as "SecurityError: The operation is insecure." Line 4181 of soundmanager2.js.

EQ data is null.

Slider start and stop times seem unresponsive.

Contributor

tim-thimmaiah commented Apr 6, 2014

Addressed soundManager issues with b74fc66

Seeing an issue caught as "SecurityError: The operation is insecure." Line 4181 of soundmanager2.js.

EQ data is null.

Slider start and stop times seem unresponsive.

@tim-thimmaiah

This comment has been minimized.

Show comment
Hide comment
@tim-thimmaiah

tim-thimmaiah Apr 7, 2014

Contributor

"SecurityError: The operation is insecure." error has to do with mozilla origin request. You can circumvent when testing on local by going to about:config in firefox url bar and setting security.fileuri.strict_origin_policy to false...

The larger issue seems to be related to usage of the mozilla's web audio api. Ability to access local metadata values like mozFrameBufferLength or mozSampleRate seems to be deprecated. See https://developer.mozilla.org/en-US/docs/Introducing_the_Audio_API_Extension.

Contributor

tim-thimmaiah commented Apr 7, 2014

"SecurityError: The operation is insecure." error has to do with mozilla origin request. You can circumvent when testing on local by going to about:config in firefox url bar and setting security.fileuri.strict_origin_policy to false...

The larger issue seems to be related to usage of the mozilla's web audio api. Ability to access local metadata values like mozFrameBufferLength or mozSampleRate seems to be deprecated. See https://developer.mozilla.org/en-US/docs/Introducing_the_Audio_API_Extension.

@elsbree

This comment has been minimized.

Show comment
Hide comment
@elsbree

elsbree Apr 15, 2014

Member

Firefox does support the web audio API (https://blog.mozilla.org/blog/2013/10/29/listen-up-web-audio-api-now-in-firefox-completes-web-as-a-platform-for-gaming/), but the waveform data still appears to be coming back as an array of zeros.

Member

elsbree commented Apr 15, 2014

Firefox does support the web audio API (https://blog.mozilla.org/blog/2013/10/29/listen-up-web-audio-api-now-in-firefox-completes-web-as-a-platform-for-gaming/), but the waveform data still appears to be coming back as an array of zeros.

@padenot

This comment has been minimized.

Show comment
Hide comment
@padenot

padenot Apr 15, 2014

Hi, I'm a developer for the Web Audio API in Firefox.

The "bug" you are seeing is because your source is cross-origin, and does not have the HTTP header:

Access-Control-Allow-Origin: *

so inspecting the resource is prohibited. Asking SoundCloud to use CORS to allow third parties to use their songs is one way to fix this. Using a CORS proxy is another, but please be aware of the security risks.

This is now in the w3c specification for Web Audio 1, the issue has been acknowledged by other implementers, and will be fixed (hopefully) soon, which, in your case, means that unfortunately your visualization will break (everywhere). 2 hopefully makes a good job at explaining the issue and gives some background. If you have questions, feel free to ask them here, or via email at padenot at mozilla dot com.

padenot commented Apr 15, 2014

Hi, I'm a developer for the Web Audio API in Firefox.

The "bug" you are seeing is because your source is cross-origin, and does not have the HTTP header:

Access-Control-Allow-Origin: *

so inspecting the resource is prohibited. Asking SoundCloud to use CORS to allow third parties to use their songs is one way to fix this. Using a CORS proxy is another, but please be aware of the security risks.

This is now in the w3c specification for Web Audio 1, the issue has been acknowledged by other implementers, and will be fixed (hopefully) soon, which, in your case, means that unfortunately your visualization will break (everywhere). 2 hopefully makes a good job at explaining the issue and gives some background. If you have questions, feel free to ask them here, or via email at padenot at mozilla dot com.

@elsbree

This comment has been minimized.

Show comment
Hide comment
@elsbree

elsbree Apr 15, 2014

Member

@padenot thanks for the explanation! I realized that this was the issue after some extensive googling. Unfortunately SoundCloud's dev team is pretty unresponsive to issues like this, so we probably can't count on them adding the CORS headers anytime soon. Our hope was that they would add the headers if we can show them that the community desires it.

If SoundCloud doesn't add CORS headers to their tracks before Chrome implements the cross origin requirements, we may have to nix the visualizer altogether. Hopefully we can convince SoundCloud to make this change!

We toyed with the idea of a proxy, but determined that it probably wouldn't be worth the additional overhead and potential security issues.

Member

elsbree commented Apr 15, 2014

@padenot thanks for the explanation! I realized that this was the issue after some extensive googling. Unfortunately SoundCloud's dev team is pretty unresponsive to issues like this, so we probably can't count on them adding the CORS headers anytime soon. Our hope was that they would add the headers if we can show them that the community desires it.

If SoundCloud doesn't add CORS headers to their tracks before Chrome implements the cross origin requirements, we may have to nix the visualizer altogether. Hopefully we can convince SoundCloud to make this change!

We toyed with the idea of a proxy, but determined that it probably wouldn't be worth the additional overhead and potential security issues.

@elsbree

This comment has been minimized.

Show comment
Hide comment
@elsbree

elsbree Apr 15, 2014

Member

Though it would be great if Firefox reported an error for the case where no CORS headers are present, instead of failing silently. It took me a while to figure out what was causing the visualizer to fail.

Member

elsbree commented Apr 15, 2014

Though it would be great if Firefox reported an error for the case where no CORS headers are present, instead of failing silently. It took me a while to figure out what was causing the visualizer to fail.

@yvg

This comment has been minimized.

Show comment
Hide comment
@yvg

yvg Apr 15, 2014

On which responses would you like to see this additional header?

yvg commented Apr 15, 2014

On which responses would you like to see this additional header?

@padenot

This comment has been minimized.

Show comment
Hide comment
@padenot

padenot Apr 15, 2014

Though it would be great if Firefox reported an error for the case where no CORS headers are present, instead of failing silently. It took me a while to figure out what was causing the visualizer to fail.

I've got a patch for that at the moment, for Firefox, it looks like this:
the screenshot

Follow along in bug 996685 if you want, but it's part of a larger patch that aims to provide better errors in the console for users of the Web Audio API in Firefox, and I'm pretty busy at the moment. We'll see.

padenot commented Apr 15, 2014

Though it would be great if Firefox reported an error for the case where no CORS headers are present, instead of failing silently. It took me a while to figure out what was causing the visualizer to fail.

I've got a patch for that at the moment, for Firefox, it looks like this:
the screenshot

Follow along in bug 996685 if you want, but it's part of a larger patch that aims to provide better errors in the console for users of the Web Audio API in Firefox, and I'm pretty busy at the moment. We'll see.

@elsbree

This comment has been minimized.

Show comment
Hide comment
@elsbree

elsbree Apr 17, 2014

Member

@padenot awesome, thanks. Did you happen to see which requests weren't getting sent with the CORS headers? When I inspect the response from SoundCloud for the URL "http://ec-media.soundcloud.com/Pki3mCjqRAE5.128.mp3", which I believe is the audio stream URL, I see the following headers:

image

It looks like the CORS headers are present. Is there an additional response that is missing the CORS headers? If not, this could still be a bug on our end.

Member

elsbree commented Apr 17, 2014

@padenot awesome, thanks. Did you happen to see which requests weren't getting sent with the CORS headers? When I inspect the response from SoundCloud for the URL "http://ec-media.soundcloud.com/Pki3mCjqRAE5.128.mp3", which I believe is the audio stream URL, I see the following headers:

image

It looks like the CORS headers are present. Is there an additional response that is missing the CORS headers? If not, this could still be a bug on our end.

@padenot

This comment has been minimized.

Show comment
Hide comment
@padenot

padenot Apr 17, 2014

Not sure what's up with that, but I've seen some weirdness in SoundManager in your code (or SoundCloud's, not sure). I can't remember the details, though, sorry.

padenot commented Apr 17, 2014

Not sure what's up with that, but I've seen some weirdness in SoundManager in your code (or SoundCloud's, not sure). I can't remember the details, though, sorry.

@brampta

This comment has been minimized.

Show comment
Hide comment
@brampta

brampta Nov 1, 2014

Hi padenot. I notice that you say that adding Access-Control-Allow-Origin: * should allow different domain createMediaElementSource() to work but in my tests it does not appear to be the case, as also mentionned by others on the following pages: http://stackoverflow.com/questions/20180550/firefox-webaudio-createmediaelementsource-not-working https://bugzilla.mozilla.org/show_bug.cgi?id=937718

In my case I am creator of a video host and am trying to use Audio Web API to add a functionality to boost the volume past 100% to help people hear low volume videos better. I am setting header('Access-Control-Allow-Origin: *'); (in PHP) on my video *pseudo-streamer (based on http://www.tuxxin.com/php-mp4-streaming/ ) and am fiddling with a test function to boost the volume.

That is my test function:

function awaa(){ //apply Web Audio API
var audioCtx = new (window.AudioContext || window.webkitAudioContext)();
var gainNode = audioCtx.createGain();
var HTML5Barbavideo=document.getElementById("HTML5Barbavideo");
var source=audioCtx.createMediaElementSource(HTML5Barbavideo);
source.connect(gainNode);
gainNode.connect(audioCtx.destination);
gainNode.gain.value = 2;
}

This works in Chrome (which from my understanding does not apply the same domain restriction on createMediaElementSource at all). And it also works on Firefox when the src is on the same domain, but when the src is on a subdomain (remote video server..) calling the createMediaElementSource freezes the video and sometimes even freezes Firefox in a way that it cannot be restarted after until I kill the process.

Is cross domain createMediaElementSource with CORS currently in a broken state? If yes when can we expect it to work? Do you suggest any work-around?

note I have pulled my headers from the video file remotely to make sure the Access-Control-Allow-Origin: * was properly set and it seems to be, heres what it looks like:

HTTP/1.1 200 OK Date: Sat, 01 Nov 2014 04:02:09 GMT Server: Apache/2.4.7 (Ubuntu) Content-Location: play.php Vary: negotiate TCN: choice X-Powered-By: PHP/5.5.9-1ubuntu4.3 Accept-Ranges: bytes Content-Range: bytes 0-250897381/250897382 Content-Length: 250897382 Access-Control-Allow-Origin: * Content-Type: video/mp4

Any info would be appreciated.

brampta commented Nov 1, 2014

Hi padenot. I notice that you say that adding Access-Control-Allow-Origin: * should allow different domain createMediaElementSource() to work but in my tests it does not appear to be the case, as also mentionned by others on the following pages: http://stackoverflow.com/questions/20180550/firefox-webaudio-createmediaelementsource-not-working https://bugzilla.mozilla.org/show_bug.cgi?id=937718

In my case I am creator of a video host and am trying to use Audio Web API to add a functionality to boost the volume past 100% to help people hear low volume videos better. I am setting header('Access-Control-Allow-Origin: *'); (in PHP) on my video *pseudo-streamer (based on http://www.tuxxin.com/php-mp4-streaming/ ) and am fiddling with a test function to boost the volume.

That is my test function:

function awaa(){ //apply Web Audio API
var audioCtx = new (window.AudioContext || window.webkitAudioContext)();
var gainNode = audioCtx.createGain();
var HTML5Barbavideo=document.getElementById("HTML5Barbavideo");
var source=audioCtx.createMediaElementSource(HTML5Barbavideo);
source.connect(gainNode);
gainNode.connect(audioCtx.destination);
gainNode.gain.value = 2;
}

This works in Chrome (which from my understanding does not apply the same domain restriction on createMediaElementSource at all). And it also works on Firefox when the src is on the same domain, but when the src is on a subdomain (remote video server..) calling the createMediaElementSource freezes the video and sometimes even freezes Firefox in a way that it cannot be restarted after until I kill the process.

Is cross domain createMediaElementSource with CORS currently in a broken state? If yes when can we expect it to work? Do you suggest any work-around?

note I have pulled my headers from the video file remotely to make sure the Access-Control-Allow-Origin: * was properly set and it seems to be, heres what it looks like:

HTTP/1.1 200 OK Date: Sat, 01 Nov 2014 04:02:09 GMT Server: Apache/2.4.7 (Ubuntu) Content-Location: play.php Vary: negotiate TCN: choice X-Powered-By: PHP/5.5.9-1ubuntu4.3 Accept-Ranges: bytes Content-Range: bytes 0-250897381/250897382 Content-Length: 250897382 Access-Control-Allow-Origin: * Content-Type: video/mp4

Any info would be appreciated.

@padenot

This comment has been minimized.

Show comment
Hide comment
@padenot

padenot Nov 2, 2014

This is filed in the mozilla bug tracker, we'll get to it when we have time: https://bugzilla.mozilla.org/show_bug.cgi?id=937718

padenot commented Nov 2, 2014

This is filed in the mozilla bug tracker, we'll get to it when we have time: https://bugzilla.mozilla.org/show_bug.cgi?id=937718

@mattdesl

This comment has been minimized.

Show comment
Hide comment
@mattdesl

mattdesl Apr 17, 2015

@brampta
Hae you tried HTML5Barbavideo.setAttribute('crossorigin', 'anonymous') ?

mattdesl commented Apr 17, 2015

@brampta
Hae you tried HTML5Barbavideo.setAttribute('crossorigin', 'anonymous') ?

@elsbree elsbree closed this Aug 21, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment