When trying to use a video as WebGL texture and that video is located on an other domain, then there will be wrong 'Security Error'.
The CORS / crossOrigin settings are all set correctly, the bug is inside Webkit.
See here a simple example for testing:
http://krpano.com/ios/bugs/ios8-webgl-video-cors/
This fails currently on iOS 8 beta iPads and also in the current OSX 10.10 Desktop Safari. The current Android Chrome 36 has the same bug (just as note if internally some code has been shared). All other Browsers are fine.

We are experiencing the same issue and would love to have the web standard 'crossorigin' attribute be supported on the Video element in IOS and Mac Safari.
I wish I would have found this bug report before I created my own test page (https://vidmaker.com/test/safari_crossorigin_test) to reproduce the issue, hehe.
The workaround we've had to employ at the moment to support our HTML5 video editor (https://vidmaker.com) in Safari is to proxy all of our videos stored in AWS S3 through nginx running on one of our servers just for Safari users. It works for the moment, but it will not at any sort of scale (unless we continue to add more proxy servers).

This bug is now almost one year old and there were more than ten iOS updates since then without any fixes.
It will be interesting to see if something will change now when a big player like Google is requesting a fix...

YouTube 360 videos ( https://www.youtube.com/watch?v=edcJ_JNeyhg ) recently shipped for the versions of Firefox and Opera that support MSE. It would be great to bring 3D and 360 videos to WebKit browsers that support MSE, too.

Hey guys,
I am looking into this.
I have confirmed that implementing MediaPlayerPrivateAVFoundationObjC::didPassCORSAccessCheck by always returning true can make the example work, so what we need to do is properly implementing this function.
I'm studying https://bugs.webkit.org/show_bug.cgi?id=99037 and try to figure out how to do the same for MediaPlayerPrivateAVFoundationObjC::didPassCORSAccessCheck.
Any code pointers/suggestions is more than welcome!
Thanks!

Hey guys,
Put together a proof of concept patch for this. Verified on OSX 10.11, the demo works in MiniBrowser. Hooray!
Is there any reviewer willing to look at this? I know very little about Webkit (never hacked on Webkit before), so let's evaluate the approach first. If it's OK, then we move on to coding style/webkit details/reusing previous GStreamer code.
Thank you very much :D
=== TL;DR ===
The following is implementation detail of the proof of concept patch.
AVAssetResourceLoader only calls its delegate when the AVURLAsset does not start with http or https. Also, it does not handle CORS check.
So, the situation leaves us 3 possible solutions:
1. do not use AVFoundation APIs. Well that does not seems like the right way to go.
2. wait for AVFoundation to handle CORS check. I personally do not want to wait. Besides, AVFoundation API is for general purpose Internet media resource loading (not limited to web browsers), while CORS checking is a very specific use case in web browsers. For this reason, I think we should handle CORS on Webkit side instead of AVFounation side. We already have mature and well-tested code for CORS, right?
3. hack into AVFoundation API, perform the CORS check somewhere in the progress.
This patch uses approach 3. Implementation is a little hacky.
- We replace http/https URLs with mock protocols mock-http/mock-https, so AVAssetResourceLoader will call our delegate
- In the delegate, use CachedResourceLoader to get response, perform CORS check.
- If CORS check passes, fill response data into the original AVAssetResourceLoadingRequest.
Except for the first step, the latter 2 steps look exactly like what we did for GStreamer backend: http://trac.webkit.org/changeset/167073/ , which is another reason I am happy about it.

Comment on attachment 266976[details]
Proof of concept patch
View in context: https://bugs.webkit.org/attachment.cgi?id=266976&action=review
Thanks for the patch. We've previously looked into this mechanism for custom data loading of media resources, and our experiments revealed a number of problems with this approach. Namely:
This will only work for initial requests. Subsequent requests (for additional byte ranges, for sub-resources, or due to HTTP redirects) will not come through this path, and will thus we will not get a chance to do a CORS check on those requests. We have to assume that these requests would not pass CORS, or we would risk opening up a hole in CORS support. Additionally, this path is only triggered for the HLS manifest load, but requests for HLS media segments does not come through this API.
I am going to give this a r- due to the above, but only due to the shortcomings of the approach in the patch, not because of the patch itself. In addition, there are a few things in your patch I'd like to call out that would need to be fixed in the hypothetical case that the approach was valid.
> avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h:412
> + int m_didPassCORSAccessCheck;
This should be defined in terms of an enum, with defined states. Such as:
enum CORSAccessCheckResult {
CORSAccessUnknown,
CORSAccessDenied,
CORSAccessAllowed,
};
CORSAccessCheckResult m_didPassCORSAccessCheck { CORSAccessUnknown };
> avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:514
> + , m_didPassCORSAccessCheck(0)
With C++11, this style of initialization can be put in the header.
> avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:839
> + if (parsedURL.protocol().lower() == "http") {
> + parsedURL.setProtocol("mock-http");
> + } else if (parsedURL.protocol().lower() == "https") {
> + parsedURL.setProtocol("mock-https");
> + }
WebKit coding style guidelines <https://webkit.org/code-style-guidelines/> specify dropping braces on single-line control statements.
> avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:2222
> +bool MediaPlayerPrivateAVFoundationObjC::didPassCORSAccessCheck() const
> +{
> + //ASSERT(m_didPassCORSAccessCheck != 0);
> + return m_didPassCORSAccessCheck == 2;
These should use the enum values i mentioned above. So this would become:
return m_didPassCORSAccessCheck == CORSAccessAllowed;
> avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:2227
> +void MediaPlayerPrivateAVFoundationObjC::didFinishCORSAccessCheck(bool passed) {
> + m_didPassCORSAccessCheck = passed ? 2 : 1;
> +}
And this would become:
m_didPassCORSAccessCheck = passed ? CORSAccessCheckAllowed : CORSAccessCheckDenied;
> avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:3445
> + URL url([m_avAsset resolvedURL]);
> + if (url.protocol() == "mock-http") {
> + url.setProtocol("http");
> + } else if (url.protocol() == "mock-https") {
> + url.setProtocol("https");
> + }
> + return url;
Ditto about the WebKit coding style guidelines.
> avfoundation/objc/WebCoreAVFResourceLoader.mm:75
> + if (requestURL.protocol() == "mock-http") {
> + requestURL.setProtocol("http");
> + } else if (requestURL.protocol() == "mock-https") {
> + requestURL.setProtocol("https");
> + }
Ditto.
> avfoundation/objc/WebCoreAVFResourceLoader.mm:83
> + m_origin = loader->document() ? loader->document()->securityOrigin() : nullptr;
> + ASSERT(m_origin.get());
No need to add .get() to a RefPtr or RetainPtr when testing nullity. Those classes provide a convenience bool operator.
> avfoundation/objc/WebCoreAVFResourceLoader.mm:117
> + bool didPassCORSAccessCheck = resource->passesAccessControlCheck(*m_origin.get());
Also, they override operator*(), so no need to add a .get() before dereferencing.

(In reply to comment #15)
> YouTube 360 videos (https://www.youtube.com/watch?v=BNqW6uE-Q_o) now work on
> IE where IE supports Media Source Extensions. It would be great to bring 3D
> and 360 videos to WebKit browsers that support MSE, too.
Richard, would YouTube 360 videos use MSE on Safari desktop?

(In reply to comment #20)
Hi Jer, thanks a lot for the reply! Clarify things a lot. A few questions though, still hoping we can find a way to fix this:
> This will only work for initial requests. Subsequent requests (for
> additional byte ranges, for sub-resources, or due to HTTP redirects) will
> not come through this path, and will thus we will not get a chance to do a
> CORS check on those requests.
Do you mean subsequent requests will not reach code in MediaPlayerPrivateAVFoundationObjC, or CachedResourceLoader does not give us a chance to handle subsequent requests?
Either way, if so, how did we handle this situation in other backends (namely GStreamer backend, as in https://bugs.webkit.org/show_bug.cgi?id=99037 )? Did we leave a loophole there?...
> Additionally, this path is only triggered for the HLS manifest load, but
> requests for HLS media segments does not come through this API.
Is this caused by AVFoundation API? If so, that would be a blocker.
Thanks again for your time!

(In reply to comment #23)
> (In reply to comment #20)
>
> Hi Jer, thanks a lot for the reply! Clarify things a lot. A few questions
> though, still hoping we can find a way to fix this:
>
> > This will only work for initial requests. Subsequent requests (for
> > additional byte ranges, for sub-resources, or due to HTTP redirects) will
> > not come through this path, and will thus we will not get a chance to do a
> > CORS check on those requests.
>
> Do you mean subsequent requests will not reach code in
> MediaPlayerPrivateAVFoundationObjC, or CachedResourceLoader does not give us
> a chance to handle subsequent requests?
Well, there's a related problem I haven't mentioned: if you simply do the CORS check, and notify AVFoundation of the final URL (provided CORS passes), then AVFoundation will proceed to use that final URL for all new requests, and thus you won't get a chance to handle subsequent requests due to redirects, additional sub-resources, etc. If you provide the data directly, you fall into a separate performance category:
The AVAssetResourceLoaderDelegate API was designed for on-disk resources which were not stored as files which AVFoundation could parse directly. E.g., database entries, UUEncoded e-mail attachments, etc. So AVFoundation makes a lot of decisions about buffering, enqueueing load requests, etc. based on the assumption that the file is entirely available and exists locally (on disk). So doing the "bait-and-switch" with "mock-http://" breaks a lot of features, such as when the "canplaythrough" event fires, how much pre-buffering occurs, and more.
Looking more carefully at the patch, I see that is exactly the trap this approach falls into.
> Either way, if so, how did we handle this situation in other backends
> (namely GStreamer backend, as in
> https://bugs.webkit.org/show_bug.cgi?id=99037 )? Did we leave a loophole
> there?...
No I think this is a problem specific to AVFoundation.
> > Additionally, this path is only triggered for the HLS manifest load, but
> > requests for HLS media segments does not come through this API.
>
> Is this caused by AVFoundation API? If so, that would be a blocker.
Yes it is.
> Thanks again for your time!
No problem. Rest assured we care very much about making this work in Safari.

(In reply to comment #22)
> Yes, YouTube would use MSE for 360 videos on Safari desktop.
In that case, there's the bigger issue: MSE-backed <video> elements cannot currently paint to Canvas or WebGL. That's a known issue which we are also working on.

Hi somebody mentioned about doing the proxy work around. This works fine for capturing image data uris from the canvas but it is not working for webGL. It still complains about a security issue with texImage2D
ie
"SecurityError: DOM Exception 18: An attempt was made to break through the security policy of the user agent."
You can test with this example file and changing your hosts to match the sub-domain exactly which is silly it should be matching top-level domains.
flowplayer.electroteque.org/video/bitrate/big_buck_bunny_600k.mp4
Any ideas if this crossorigin attr is finally getting in there it's years a bit too late.

The proxy work around is totally no good for production and defeats the purpose of using CDN's for videos ! My nginx proxy path has to redirect to cloudfront internally.
I suggest a 2D video alternative plays back, and then the user can turn on 360 video and play back the proxy video. If this even works of course!
The fact that it has to match the sub domain exactly is the issue here. Any wonder why Youtube can't even support Safari yet ?

Excuse me. Confirming the proxy work around works. I forgot not only sub domains need to match but also ports.
I believe this may require what I suggested. A 2D version of the video with user controls to turn on 360 which will need to run through the proxy.
So for Safari and IE and anything with no crossorigin attribute, play 2D, and turn on 360 on demand. Unfortunately there is no way to make a 360 video a flat plane without webgl on.
This is one of the most important features to have not implemented and it kind of cripples html5 video a lot ironically requiring FLASH ! The proxy is the only known work around. I needed this for a video capture feature when extracting the image data uri from the canvas.
I believe the corssorigin attribute is required on TextTracks too while I'm at it.

here is a working example with the silly fallback hacks.
It will replace the video with a "2D" version of the video, then a button will switch to the proxy source.
as far as UI goes it as good as it gets rather than attempt to use the proxy source by default.
https://flowplayer.electroteque.org/vr360/fp6
I hope this serious non compliant bug fix manages to find its way into OSX and Safari soon.
How could something as important as this manage to be evaded for so many years I wonder ?
BTW this bug tracker server is blocking my ip for some reason all of a sudden. I have to use a VPN to get access !

Any updates on this bug?? I have confirmed the CORS rules are not respected in safari for the latest iOS 9. The only workaround we were able to use was to create a proxy to our CDN so the videos are loaded from the same domain. But that's pointless. We have also tried 301/302 redirects but to no avail.
Firefox, chrome and edge all support it now. Safari is lagging behind.
We really need a solution for this. Can someone advise on a workaround?

This "bug" is a standards flaw. It has been a problem for years.
This is a serious show stopper for WebVR. At a time Apple is trying to show off their new Iphone VR case, this makes it a complete farce.
WebVR has been exploding very rapidly over the past year and Safari is dragging it's heels making it completely unusable.
Something as trivial as this should have been added years ago.

I've had to do the same proxy workaround for video snapshot features but a single frame on a reverse proxy is much different than streaming through it. It won't scale and makes a CDN pointless. It is not a production ready solution.
The only solution is to add the crossOrigin property on the video tag and while you are at it on the text tracks also.
https://flowplayer.electroteque.org/snapshot/fp6

Interestingly, I have images working fine with the crossOrigin set to anonymous, but video seems to be the culprit.
Amazing that Apple just hired an entire VR team to explore this explosive industry, and their flagship phone and browser are generations behind the competition. C'mon guys. This case is still assigned to "Nobody". We've already done all the work for you. Chop chop!

FYI, even MS Edge now supports the video textures and CORS correctly for webgl with the latest update (MS Edge 10586 TH2 Update). So all browsers seem to correctly support it, except Safari which is lacking proper support.
Can we get an update on this bug when it will be fixed for Safari on MacOS and iOS?

(In reply to comment #37)
> Can we get an update on this bug when it will be fixed for Safari on MacOS
> and iOS?
Apple does not comment on the timing or content of future releases. If you would like to register your desire to have this bug fixed, and to be notified when a fix is available in a public build, please file a Radar, and include your use case which is blocked by the current behavior.

(In reply to comment #39)
> Yeah VR on IOS is a complete farce right now. A complete show stopper.
>
> CORS has been on images for a while now. Video has been broken for years.
>
> Sheer arrogance from Apple.
David and Daniel, this is not a blog comment section. If you would like to comment about Apple's arrogance and how this bug is proof of it, I recommend you do so on Twitter. As the Apple employee who is working on this bug, you can accuse me of arrogance there at @jernoble.
Otherwise, if you do have constructive additions to this bug, (e.g., test cases, patches, etc.) please continue to post them.

I will take this up with Apple because this has gone on for too long. This should take priority.
This flaw has been an issue for years and years.
Only that people now are only realising it, working with webgl. It was reported in July 2014 and nobody is even assigned to it that just shows contempt.
It is only just going to keep getting duped now.
I'm not treating this issue as a forum its serious.
Again this should be an embarrassment for Apple because it completely disables VR.
If there is a fix I would be happy to test it, I am closely monitoring this.

https://bugs.webkit.org/show_bug.cgi?id=125157
I believe these two are related. WebGL and canvas video drawing does not work with MediaSource / mpeg dash even with the reverse proxy work around which normally works on mp4. I have tested this myself and runs into the CORS security error.
These should be merged into one. They are the same problem.
More and more people once they find out trying to do VR on Safari are going to start making duplicates.
I can't understand why that ticket is assigned and this one which is far more serious and the actual problem is not.

Just letting developers know that after updating to iOS 9.2.1, I have confirmed that this bug is still not yet fixed.
On a good note, my iPad is running only slightly slower than expected. So that's good.

It may take years to get into an IOS update unless there is mass duplicate tickets with Apple. I have made a ticket but they closed it pending a duplicate with a much earlier ticket number. Which means the bug ticket has been there for years.
It seems Firefox on IOS also uses and relies on webkit which is why it also is broken with CORS on IOS.
Even with a CORS fix guys you still have to deal with the inline video playback issue with Iphone. It will prevent viewing the webgl canvas. I have no idea how to get through to Apple's thick heads about that one but I tried.
You must wait until webkit nightly has a fix then hassle Apple I guess.

Please keep track of this ticket, it seems to be related. They are doing their best it seems to fix it even though its years too late. They missed the opportunity already and way behind because they have never bothered to fix CORS and this video inline playback issue.
Apple should be interfering with this but don't give a damn because they are hopeless.
https://bugs.webkit.org/show_bug.cgi?id=125157#c29

Any ideas of the status of this ? I sent this to the other ticket which has dropped off the radar for two months now.
I know it's pretty much crept up and steamrolled, many people trying to do WebVR including Youtube and Facebook of all people are also waiting.
They should pay to make this happen.
This problem has been left exposed for many years now and was just an accident waiting to happen. For some reason a few of us have to do the run around for many others.
Obviously the reverse proxy work around is not ok for production so not even Facebook or Youtube are doing that and therefore Safari is broken.
If there is a nightly fix to test please let me know.

Yes, definitely still not fixed in iOS 10!
I think iOS is more important to become fixed, on Mac it's possible to use other browsers (e.g. show a screen like 'your browser is bad, please use another one'), on iOS this is not possible...

Apologies to use this as a forum.
are you kidding ?
So they forked the code and fixed it in an OS and browser nobody even has yet ?
Well that is useful. There should be a patch going out because it's broken right now. Well it has been broken for years especially for canvas captures.
Why not merge it back into webkit ?

(In reply to comment #55)
> Why not merge it back into webkit ?
All of the work was done in WebKit (153669 and others). This doesn't work on iOS, yet, because some of the lower level frameworks WebKit uses don't have the functionality required.

It needs inline play back support to make it useful which I believe has been made available in 10. The show stopper as they mentioned is working around some framework constraints or waiting for them to be fixed ? It kind of needed to be implemented years ago so none of this would have been a problem now.
Have to sit and wait. From my understanding they reckon this has been fixed in nightly webkit. ? I will try and have a look as it also affects canvas image captures not having CORs support.

(In reply to comment #59)
> Not sure where that has been changed. I just had a look at the latest
> nightly.
>
> Still no crossorigin attribute supported so not even canvas captures will
> work. Requires the proxy hack.
>
As I noted above, the WebKit changes depend on features in lower level frameworks.

People watching this thread might be interested in another issue here:
https://bugs.webkit.org/show_bug.cgi?id=153588
At unpredictable times, safari only renders the first video frame to a canvas, regardless of seek position If the first frame is black then canvas is painted black and remains that way.
Even if *this* issue here is resolved (135379), issue 153588 makes it impractical to use video with canvas. That issue is also listed as P2 and assigned to Nobody.

That has nothing to do with this issue I'm afraid. Best not to deviate. That requires a further hack by drawing twice.
It is really funny but IE11 also suffers the CORS problem but with mediasource appending it doesn't require the proxy hack to draw and get the data from canvas. So for dash it is fine.
Safari is not. It requires a secondary dash stream to seek and capture via the CORS proxy.

Just a heads up about this crazy issue. I can't test VR mode on IOS yet unless I deploy to my Ipad.
Cordova apps use WebView. It has options to play inline so works around that pesky problem. It works around user interaction. This one is the craziest of them all and has been driving me crazy.
WebView seems to work around CORS completely even if its a local html file running on file://.
WebGL is working in Cordova apps without the need for the crossorigin attribute.
This is both shocking and good news. It won't need the proxy hack but Safari IOS/OSX will.
I can't check pseudo VR orientation controls but touch controls is working so is the old cardboard stereo effect.
I'll have to properly deploy to make it works outside the emulator hopefully.

Hi rick I didn't know they had a html5 solution yet or is that the case now ? I provide a Flowplayer alternative.
I commented on another bug ticket.
The CORS is still a problem. but even working around that with the proxy serrver hack, HLS now does not render in WebGL.
That has become an issue recently and other people have picked it up asking questions. I am 100% certain testing before it was working. Going crazy.
No wonder nobody can support Safari.

Yes you are trying to use HLS and will run into the same WebGL rendering issue. Still trying to hunt down a "solution" now. You can try an Mp4 for now over a reverse proxy path and it will work in Safari, IOS but WebView apps completely avoid CORS restrictions.
There is also now a feature detection issue, Safari is reporting that the crossOrigin attribute is available but still broken. You have to detect for both Safari and Trident browsers and switch to proxy urls.
I have an example of it live but I need to fix this feature detection break first.
I am presuming all of this will be resolved in macOS not earlier. IOS 10 will have the CORS issue still as far as I am aware but have inline video playback. A royal mess if you ask me.

(In reply to comment #66)
> Yes you are trying to use HLS and will run into the same WebGL rendering
> issue. Still trying to hunt down a "solution" now. You can try an Mp4 for
> now over a reverse proxy path and it will work in Safari, IOS but WebView
> apps completely avoid CORS restrictions.
>
> There is also now a feature detection issue, Safari is reporting that the
> crossOrigin attribute is available but still broken. You have to detect for
> both Safari and Trident browsers and switch to proxy urls.
>
> I have an example of it live but I need to fix this feature detection break
> first.
>
> I am presuming all of this will be resolved in macOS not earlier. IOS 10
> will have the CORS issue still as far as I am aware but have inline video
> playback. A royal mess if you ask me.
Reverse proxying is not an option for us at this point of time.
I'm still having CORS issues with Safari 10 on macOS Sierra:
texImage2D:
SecurityError (DOM Exception 18): The operation is insecure.
Chrome, Firefox and Opera work fine.

hahaha so something that was supposed to be fixed in macOS isn't ?
Here is the deal breaker for HLS. I am so certain it was working for me. Someone is reporting it is not working for them in Safari 9 but I now have it rendering but in Safari 10 but not 9.
It certainly does not work in IOS but on OSX Safari 10 it does.
Some kind of regression or sabotage if you will changes have happened I have noticed then.
A recent update to IOS has now officially broken the proxy hack to stop it working. Says source not supported.
If people want Apple device support they need the proxy hack but it seems they've gone to great lengths to kill it off completely.

Hi Daniel Rossi,
You mentioned in your comment on 2016-07-06 08:45:36 PDT that you were able to make VR work using Cordova on iOS. Can you please elaborate on how you did that? I am trying to make a web view app that plays inline html5 360 video.
I really appreciate your help!!
Regards,
Tim

You don't need the CORS proxy url for Cordova based apps. For some reason it is completely ignored.
It can play inline , you just need the inline attribute configured on the video element and then configure inline playback configs in Cordova.
It is only working with mp4 files.
I am now having webgl rendering issues with HLS that I'm trying to resolved. It's not pretty. Webkit is pretty buggered up really and unstable for webvr.
I saw the CORS issue becoming a problem years ago trying to implement snapshot features and it was never fixed of course.

Edwin I have made a bug report here but zero response.
I have eventually figured out a work around for OSX Safari if using three.js. They are using this flag that is referred in this ticket that needs to be turned off.
WebGL seems to render textures in reverse and needs to be flipped around. This flip flag for now reason at all causes the issue. The UV property on the geometry needs to be reverse.
I tried absolutely everything and nothing. It was working that is for sure. It has been sabotaged. I will keep trying to find work arounds which is standard with Apple.
https://bugs.webkit.org/show_bug.cgi?id=163866#c3

All these problems together is why the big end of town doesn't support Safari / IOS at all.
I prefer not to use apps though like many don't and stick with WebVR / Html5 streaming. which on IOS would be HLS especially for live streaming.

Apparently the CORS issue is fixed in Safari in macOS but the very latest updates. The inline video playback is also working in IOS.
Here is two tests on for mp4 streaming another for HLS. The HLS one requires extra work because of a separate bug with FlipY that is still a problem on OSX Safari.
HLS rendering on IOS 10 is displaying but has colour artifact issues. The frames stop working but I believe its an issue with the emulator and frames dropping. I now have no device that can be updated to IOS 10. It doesn't show up at all on IOS 9. Both require the CORS proxy for mp4 and HLS.
http://dev.electroteque.org/webgl/threejscors.htmlhttp://dev.electroteque.org/webgl/threejscors-hls.html

Now I'm stuck with a situation that the crossOrigin feature detection cannot be used because it reports of support in OSX 10.11 but there is no such thing.
I have to try and detect which OSX safari is used in also. very bad.
var testVideo = document.createElement("video");
testVideo.crossOrigin = "anonymous";
testVideo.hasAttribute("crossOrigin")
This used to work but now it doesn't. Safari in 10.10 / 10.11 will report the attribute is available.

Here is some Es6 from static utils to deal with the CORS detection problem. It has driven me over the edge. I know people have given up on Safari but people want and need this to work.
Both IOS 10 Safari and Yosemite Safari 10 report CORS feature detection but obviously do not, this was a recent sabotage in Safari 10.
Extra platform and version checks are required. This is rough as guts but I have no time or stomach to fine tune it further. If it doesn't support CORS the property should not be available as before.
I have to specifically check for both Safari and OSX 10.12 and above. This will break in the future of course.
static supportsCORS() {
let testVideo = document.createElement("video"),
hasCORS = false;
testVideo.crossOrigin = "anonymous";
hasCORS = testVideo.hasAttribute("crossOrigin");
testVideo = null;
if (hasCORS) {
if (WebVRUtils.isSafari) {
if (WebVRUtils.isIpad) return false;
return WebVRUtils.isNewSafari;
}
return true;
}
return false;
}
static get isSafari() {
const userAgent = navigator.userAgent;
return (/Safari/i).test(userAgent) && !(/Chrome/i).test(userAgent);
}
static get isIpad() {
const userAgent = navigator.userAgent;
return (/iP(hone|od|ad)/i).test(userAgent);
}
static get isNewSafari() {
const version = /Mac OS X (10[\.\_\d]+)/.exec(navigator.userAgent)[1].split("_")[1];
return +version >= 12;
}

Confirmed this works as expected (bug fixed) when testing against the URL on this ticket using latest macOS Sierra 10.12.1 (16B2659) Safari Version 10.0.1 (12602.2.14.0.7).
Bug is still NOT fixed in Mobile Safari on iOS 10.2 Public Beta 3 (14C5077b). There is a newer Beta 4 available but I have not yet installed or tested.

Any update or ETA when this fix will get into iOS Safari? That seems to be the lone holdout and even once an update is pushed we have to factor adoption time leaving most publishers in the situation of having to setup or keep doing the proxy workaround...

(In reply to comment #83)
> Any update or ETA when this fix will get into iOS Safari? That seems to be
> the lone holdout and even once an update is pushed we have to factor
> adoption time leaving most publishers in the situation of having to setup or
> keep doing the proxy workaround...
We will absolutely update this bug as soon as there is anything to announce.

(In reply to comment #84)
> (In reply to comment #83)
> > Any update or ETA when this fix will get into iOS Safari? That seems to be
> > the lone holdout and even once an update is pushed we have to factor
> > adoption time leaving most publishers in the situation of having to setup or
> > keep doing the proxy workaround...
>
> We will absolutely update this bug as soon as there is anything to announce.
Thanks Jer, we also filed a bug report with bugreport.apple.com, ticket 31066138. Do appreciate anything that can be done to get a fix into the next update.

You would have to wait for the entire video to finish no ? I guess that wouldn't work with HLS videos either so live streaming.
It has certainly caused problems for alot of people. The only work around for IOS is inside a Cordova app.
Hopefully what I just said means Apple don't try and sabotage and block it. It doesn't do any CORS check whatsoever. Works with Mp4 and HLS.
Please Apple and don't try and block that now !
This bug has been a problem for half a decade or more. It's just only that people are wanting to do 360 videos and webgl video textures it has come back to bite them.
This is not a problem anymore on macOS. Have a look.

Just make a player as you would any player and build inside a Webview Cordova / Ionic app.
Does not need CORS proxy, no crossorigin attribute , any source.
I believe pinned WebView apps also do not use CORS as far as I tests go.

(In reply to Sergei Soloviev from comment #91)
> Hi! Any planning updates here? We have the same problems with showing videos
> as textures in Canvas.
I strongly urge everyone who's interested in this feature to sign up with the developer.apple.com portal and try it out with iOS 11 Beta.

So IOS10 no good. The only thing IOS10 provided was inline playback.
The fix is in IOS11 but won't be ready for months ?
My subscription ended sadly, I don't need it at all.
Underlying frameworks prevent the issue being rolled out for IOS1- then ?
Its getting a bit much having to ask people to implement the CORS proxy workarounds that dont scale.

(In reply to Jer Noble from comment #92)
> (In reply to Sergei Soloviev from comment #91)
> > Hi! Any planning updates here? We have the same problems with showing videos
> > as textures in Canvas.
>
> I strongly urge everyone who's interested in this feature to sign up with
> the developer.apple.com portal and try it out with iOS 11 Beta.
Your response is vague. Will this three-year old bug be resolved or not? When?

(In reply to chris from comment #94)
> (In reply to Jer Noble from comment #92)
> > (In reply to Sergei Soloviev from comment #91)
> > > Hi! Any planning updates here? We have the same problems with showing videos
> > > as textures in Canvas.
> >
> > I strongly urge everyone who's interested in this feature to sign up with
> > the developer.apple.com portal and try it out with iOS 11 Beta.
>
> Your response is vague. Will this three-year old bug be resolved or not?
> When?
We believe it will be fixed in iOS 11. But interested parties (e.g., you) should try out your test cases against iOS 11 to verify (one way or another) whether it fixes the issues you're seeing.
Apple has released a public beta for iOS 11, which does not require a developer account: <https://beta.apple.com/sp/betaprogram/>.

"try it out yourself"
it either is committed and reported as fixed in this ticket or not.
Seems like it's still has not been fixed. This has been a problem for years. I've been needing to use CORS proxies for canvas capture features.
It only became a bigger issue once people started to try and use webgl video textures !

(In reply to Daniel Rossi from comment #99)
> I just tried IOS 11 in Xcode 9 beta and CORS is still not there it seems.
> Not sure how to get the specific IOS 11 simulator version.
Looks like this regressed in general, because the same site now fails in Safari Tech Preview on Desktop as well.

Wow.
macOS Safari in production definitely had CORS fixed.
At the same time as the IOS 10 release CORS wasn't fixed in that sadly.
Detecting it was a problem though, it requires platform version checks. It returns true when checking if the crossorigin attribute is set. Previously it's empty.

(In reply to Daniel Rossi from comment #101)
> Wow.
>
> macOS Safari in production definitely had CORS fixed.
>
> At the same time as the IOS 10 release CORS wasn't fixed in that sadly.
>
> Detecting it was a problem though, it requires platform version checks. It
> returns true when checking if the crossorigin attribute is set. Previously
> it's empty.
The test is failing on desktop because the HTMLMediaElement::hasSingleSecurityOrigin() is failing; and that's failing because the media element url was redirected from http: to https:. Can you try this test without the redirection, or is it possible the CDN changed policies to do the redirect to https:?

(In reply to Jer Noble from comment #102)
> (In reply to Daniel Rossi from comment #101)
> > Wow.
> >
> > macOS Safari in production definitely had CORS fixed.
> >
> > At the same time as the IOS 10 release CORS wasn't fixed in that sadly.
> >
> > Detecting it was a problem though, it requires platform version checks. It
> > returns true when checking if the crossorigin attribute is set. Previously
> > it's empty.
>
> The test is failing on desktop because the
> HTMLMediaElement::hasSingleSecurityOrigin() is failing; and that's failing
> because the media element url was redirected from http: to https:. Can you
> try this test without the redirection, or is it possible the CDN changed
> policies to do the redirect to https:?
To be clear, this part of the code hasn't changed in about 3 years, so it's unlikely that this test regression was caused by a change in WebKit.

Yes that is a standard procedure. CORS won't work over http / https. Has to be the same protocol. So that is a non issue. It's just IOS everyone is waiting on.
I just tested again and Safari 10.1.2 and mac OS 10.12.6 is perfectly fine.
If you mean 3 years since macOS then yes it was when that was fixed.
You can see on my own feature and demos. same ssl protocol for site and streams on cloudfront.
https://flowplayer.electroteque.org/vr360/fp6

(In reply to Daniel Rossi from comment #104)
> Yes that is a standard procedure. CORS won't work over http / https. Has to
> be the same protocol. So that is a non issue. It's just IOS everyone is
> waiting on.
>
> I just tested again and Safari 10.1.2 and mac OS 10.12.6 is perfectly fine.
>
> If you mean 3 years since macOS then yes it was when that was fixed.
>
> You can see on my own feature and demos. same ssl protocol for site and
> streams on cloudfront.
>
> https://flowplayer.electroteque.org/vr360/fp6
Daniel, your site seems to work fine on iOS 11 (hardware, not simulator). Can you confirm?

It's using a CORS Proxy work around feature as fallback.
What source is it using ?
this is the cors proxy
//flowplayer.electroteque.org/video/360/ultra_light_flight_720p.mp4
I don't have access to a Device that can run IOS11 yet I am afraid, my focus has been Android VR. I need a brand new device there.
I only have access to IOS 11 Simulator inside Xcode 9 beta.

OK. Ive added the new spec flag which is in production, those demos came from threejs so has the old flag.
The IOS11 simulator has problems and wont even start playing video. I get a frame up on IOs10 simulator with the proxy.
So regarding this ticket there is a possibility IOS 11 beta on a device not a simulator has CORS fixed.
I have to somehow get a new device that supports IOS11 to properly test and confirm further thanks.

Confirming CORS is fixed in IOS 11.1. I just finally got the budget to get a hardware device for testing.
There is no need for CORS proxy with 11.1. I don't think CORS attribute support can be properly tested with Safari. Have to do client version checks.
There is major HLS/webgl regression issues to go through now though.

I haven't checked WebView under IOS11 as in a Cordova app.
But as before WebView didn't even factor in CORS at all, it was working. I hope that is not broken too now !
I have to check myself.
I believe this is possibly what you are talking about.