I have been trying to get this to run correctly so days now with no luck.
I have created a custom audio player, that accesses an MP3 on a S3 Amazon server. The audio player has custom controls enabled by Javascript, and a Audio Visualizer made possible by the Web Audio API.
Now the problem I am running into is this: Work fine on Chrome. Safari out right says it can't run the Web Audio API, but the audio will still play. In Firefox, the entire thing shuts down. Click play... nothing. I thought it was a CORS issue, so we set the proper headers on the server and still nothing. BUT... if I deactivate the Web Audio API visualizer, then I can get the player to play just fine.
http://jsfiddle.net/murphy1976/yqqf7uL1/1/
Here is my jFiddle. I have separated the Audio Player controls Script from the Visualizer Script with comments so you can see how it will work in Firefox, and how it will NOT work in Firefox.
I read somewhere that this issue that I'm running into MAY be a bug with Firefox. I just want to make sure so that I can stop beating my skull over this.
Could I put a call to CORS here?:
<source crossorigin="anonymous" src="audioFiles/35022797.mp3" id="srcMP3" type="audio/mp3">
The same-origin policy says that scripts run on some origin cannot read resources from another origin. (An origin is a domain, plus a scheme and port, like http://foo.example.com:80.)
Note that the same-origin policy does not prevent cross-origin media from being displayed to the user. Rather, it prevents scripts from programmatically reading cross-origin resources. Consider the <img> tag: a page on example.com can show a cross-origin image from other.com, but a script on example.com's page cannot read the contents of that image. The user can see it; the page cannot.
The Web Audio API can read the contents of audio files. If an audio file is from a different origin, this kind of reading is not allow by the same-origin policy. A user can listen to a cross-origin audio file, but a script on the page cannot read the contents of the file. When you attempt to feed a cross-origin audio file into an analyzer script (e.g., so that you can draw a visualization on a canvas), the same-origin policy should stop you. You are attempting to violate the same-origin policy, and the browser is correctly stopping you by refusing to play the audio in way that would allow you to read the file contents.
Note that Chrome does not prevent such cross-origin file reading for audio files, and this is incorrect behavior.
The correct solution is to have your media servers serve the audio files with a CORS Access-Control-Allow-Origin: * HTTP response header. However, this currently does not work in Firefox, which is incorrect behavior. If Firefox hopes to have a compliant implementation, this will be fixed eventually.
Confirmed that there is a bug in Firefox for using the createMediaElementSource method on a cross domain source:
https://bugzilla.mozilla.org/show_bug.cgi?id=937718
Related
I am building a web app to be locally hosted on a Kindle Fire HD 10, in an area (an open-air museum) that does not have internet access.
All files and libraries have been loaded onto the device, and I am using Firefox to access the app. The app consists of locally-hosted javascript files for a panorama Javascript library (https://pannellum.org/), images, css files and an index.html file.
I am able to successfully point to the index.html file on the Kindle Fire through the browser, and load the app. However, I am not able to load the panorama images, and receive this CORS-related error in the console:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///E:/The%20Pith/Consultancy%20Projects/Boscobel%20Photo%20Sphere/panoramas/introroom.jpg. (Reason: CORS request not http).
I originally received this on desktop, but was able to change circumvent it by changing the strict_origin_policy setting on Firefox. But this does not seem possible on Firefox Android.
Is there a way that I can do this otherwise (perhaps through Javascript, or through the of my HTML file?
Update: Based on Callum Morrisson's comments below, there does not seem to be an easy solution to this.
I'm building a web audio player like SoundCloud footer player using jQuery and HTML5 audio tag. The only-one problem is how to stream an audio file from another domain? (This player plugin could be installed in any website with some basic setup in JSON).
This is the console response when trying to stream an audio file:
The expected answers should be in jQuery.
Update: I've tried to use 'crossdomain' html5 attribute and crossDomain property in jQuery.ajax() but no effect.
Thanks a lot.
A couple routes...
Firstly, if you're not reading that audio data or doing anything client-side with that audio, you can just use <audio src="..." /> as normal. CORS doesn't come into play until you're actually trying to use script to read that audio. If you're using some sort of special player code... don't. Just use a normal HTML5 <audio> tag or the Audio class.
Next, if you do need to read the raw audio data, either direct from the URL or to record/process the resulting decoded audio, your server must be configured to allow for CORS for this resource. Access-Control-Allow-Origin: * in the response headers is the easiest way to get there, but you should read up on CORS and understand it before proceeding so that you don't accidentally make something insecure on that server.
I'm using Google's SW-Toolbox library in my app for handling service worker duties; however, whenever I try to load a video from Parse (using Parse for file hosting), I get a series of CORS-related errors in the console and the video doesn't display. I know SW-Toolbox is involved because when I remove the service worker, or in browsers where service worker is not supported, the video loads fine. Could anyone help decipher these errors, and/or provide a workaround? Thanks.
My code for rendering the video is literally just the HTML5 video element:
<video src="https://files.parsetfss.com/0e1eb489-e25d-429b-86a9-d75a65253a09/tfss-1eedfc22-4219-443d-9f16-0d879f2c378a-Taylor%20Swift%20-%20Blank%20Space.mp4" controls>
NOTE: this isn't just a Parse issue; I tried another random mp4 URL from the web (http://techslides.com/demos/sample-videos/small.mp4) and had the same exact issue.
The first error, "Fetch API cannot load…", says that your service worker is intercepting the request for the video, which is a cross-origin request, and attempting to fetch the file itself; but the server doesn't permit cross-origin requests, so the fetch is failing.
This sounds a lot like sw-toolbox bug https://github.com/GoogleChrome/sw-toolbox/issues/49, which is affected by Chrome bug https://bugs.chromium.org/p/chromium/issues/detail?id=546076.
The suggested workaround in https://github.com/GoogleChrome/sw-toolbox/issues/49#issuecomment-170868923 is to not call event.respondWith() in the fetch handler for the request, which for sw-toolbox means ensuring that you don't define a route that handles the request with event.respondWith() (neither a specific route nor the default route).
I found there is a strange thing about the youtube javascript api.The javascript api actually requests the player inside the iframe to do something. How can the api ignore the same origin policy? I have no idea about how it works.
What you're looking for is HTML5's postMessage feature. It allows for sending data messages between two windows/frames across domains, currently supported on all major browsers. See this demo for an example (open the console to see messages getting passed).
I have been having a very strange and seemingly unlikely problem. I made a custom python server based off of SimpleHTTPServer, which requires me to set all my own headers. I started using it to serve .wav files and while they would play in an HTML5 tag in chrome they would not replay (via setting currentTime=0 and calling play() again). If I hosted them on standard Apache server, however, they would replay just fine. I open dev tools and slowly added and removed headers to my python server until they started playing properly. It turns out that the missing element was the "Accept-Ranges: bytes" header. Without it the wav file will not replay and with it everything works fine. Does anyone know why this happens?
I've found this same thing -- browsers require the Accept-Ranges header when playing audio via the <audio> tag. In my case, this was happening with MP3s (I didn't try with WAVs).
I don't know why that happens, but if you want to avoid it, use the new Web Audio API. In my experience, Chrome/Safari/Firefox will play (and replay) audio just fine without the Accept-Ranges header if you use the Web Audio API. Here's a good starter article.