Bug 135379 - iOS 8 / OSX 10.10 WebGL - using a video from an other domain fails (CORS bug)
Summary: iOS 8 / OSX 10.10 WebGL - using a video from an other domain fails (CORS bug)
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media Elements (show other bugs)
Version: 528+ (Nightly build)
Hardware: iPhone / iPad Unspecified
: P2 Normal
Assignee: Nobody
URL: http://krpano.com/ios/bugs/ios8-webgl...
Keywords: InRadar
: 170455 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-07-29 03:03 PDT by Klaus Reinfeld
Modified: 2017-04-09 08:56 PDT (History)
38 users (show)

See Also:


Attachments
Proof of concept patch (5.88 KB, patch)
2015-12-09 01:43 PST, Tong Shen
jer.noble: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Reinfeld 2014-07-29 03:03:46 PDT
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.
Comment 1 Alex Christensen 2014-07-31 13:57:36 PDT
This would be fixed by implementing MediaPlayerPrivateAVFoundationObjC::didPassCORSAccessCheck.  See https://bugs.webkit.org/show_bug.cgi?id=99037
Comment 2 Klaus Reinfeld 2014-09-17 12:25:32 PDT
iOS 8 release and still not fixed!
Very bad!
Comment 3 Radar WebKit Bug Importer 2014-09-17 13:58:09 PDT
<rdar://problem/18370945>
Comment 4 Dean Jackson 2014-09-17 19:13:11 PDT
This is a media bug. Our AVFoundation backend does not check CORS for tainting.
Comment 5 Radar WebKit Bug Importer 2014-09-17 19:13:40 PDT
<rdar://problem/18375542>
Comment 6 Klaus Reinfeld 2014-09-25 22:18:38 PDT
Still not fixed in iOS 8.0.2!
Comment 7 Klaus Reinfeld 2014-09-29 23:57:11 PDT
iOS 8.1 beta and still not fixed...

It seems to be hopeless...
Is it really that hard to fix that bug or what's the problem with it? Why doesn't it get fixed? No developer resources?
Comment 8 Alexey Proskuryakov 2014-09-30 00:04:57 PDT
There is no reason to post status of every iOS beta or update - there is no fix here in this bug yet. Nothing is going to change before this bug is resolved.
Comment 9 Yuri Zapuchlak 2014-09-30 12:54:25 PDT
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).
Comment 10 Sean 2015-03-03 18:27:35 PST
I'd like to chime in that this is a problem for many 360 video players including our own. Would be great to get a fix!
Comment 11 Richard Leider 2015-05-18 21:26:08 PDT
This issue is a blocker for YouTube 360 and 3D videos in webkit.
Comment 12 Klaus Reinfeld 2015-05-20 01:53:49 PDT
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...
Comment 13 Klaus Reinfeld 2015-06-08 13:29:07 PDT
Still not fixed in iOS 9 beta 1...
Comment 14 Richard Leider 2015-07-21 15:20:36 PDT
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.
Comment 15 Richard Leider 2015-08-11 15:30:29 PDT
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.
Comment 16 Denny 2015-10-15 16:49:58 PDT
This also fails on most recent desktop Safari 9.0 (11601.1.56).
Comment 17 Tong Shen 2015-12-08 19:47:24 PST
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!
Comment 18 Tong Shen 2015-12-09 01:43:01 PST
Created attachment 266976 [details]
Proof of concept patch
Comment 19 Tong Shen 2015-12-09 02:00:29 PST
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 20 Jer Noble 2015-12-10 08:40:19 PST
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.
Comment 21 Jer Noble 2015-12-10 08:41:18 PST
(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?
Comment 22 Richard Leider 2015-12-10 08:53:50 PST
Yes, YouTube would use MSE for 360 videos on Safari desktop.
Comment 23 Tong Shen 2015-12-10 09:12:31 PST
(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!
Comment 24 Jer Noble 2015-12-10 09:31:51 PST
(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.
Comment 25 Tong Shen 2015-12-10 09:49:49 PST
(In reply to comment #24)

Aha, I rest my case:-) Seems this can only be fixed in AVFoundation side.

BTW the performance decision thing really teaches me a lesson about improving user experience. Kudos on that!

Thank you, and look forward to seeing this bug resolved (hopefully soon :D )
Comment 26 Jer Noble 2015-12-10 10:19:31 PST
(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.
Comment 27 Richard Leider 2015-12-10 13:32:25 PST
Is there an existing bug/feature request I could cc myself on that represents the known issue about MSE-backed <video> elements being unable to paint to Canvas or WebGL?
Comment 28 Daniel Rossi 2015-12-12 02:06:59 PST
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.
Comment 29 Daniel Rossi 2015-12-12 02:09:38 PST
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 ?
Comment 30 Daniel Rossi 2015-12-13 01:09:47 PST
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.
Comment 31 Daniel Rossi 2015-12-18 22:34:32 PST
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 !
Comment 32 David 2016-02-05 08:46:21 PST
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?
Comment 33 Daniel Rossi 2016-02-05 08:55:55 PST
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.
Comment 34 Daniel Rossi 2016-02-05 08:58:41 PST
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
Comment 35 Daniel Rossi 2016-02-05 09:02:34 PST
Inline video is just another issue altogether and for another day. WebVR is unusable full stop on Iphone because of it :)
Comment 36 David 2016-02-05 09:44:16 PST
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!
Comment 37 David 2016-02-08 08:26:41 PST
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?
Comment 38 Jer Noble 2016-02-08 08:45:50 PST
(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.
Comment 39 Daniel Rossi 2016-02-08 10:06:41 PST
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.
Comment 40 Jer Noble 2016-02-08 11:03:12 PST
(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.
Comment 41 Jer Noble 2016-02-12 14:21:38 PST
*** Bug 154189 has been marked as a duplicate of this bug. ***
Comment 42 Daniel Rossi 2016-02-12 18:09:14 PST
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.
Comment 43 Daniel Rossi 2016-02-13 20:02:02 PST
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.
Comment 44 David 2016-02-15 11:06:01 PST
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.
Comment 45 David 2016-03-21 10:48:15 PDT
Can someone verify if this bug has been fixed in the new iOS 9.3 released today?
Comment 46 Alexey Proskuryakov 2016-03-21 11:15:43 PDT
No need to check that.

The bug is in NEW state, meaning that it hasn't been fixed in WebKit trunk. That will change before it's fixed in shipping software.
Comment 47 Klaus Reinfeld 2016-03-21 13:21:35 PDT
Just finished updating and testing  - unfortunately again nothing had been fixed, neither the CORS bug nor the bad video-to-WebGL-texture performance...
Comment 48 Daniel Rossi 2016-03-21 19:26:04 PDT
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.
Comment 49 Daniel Rossi 2016-03-21 19:28:20 PDT
So once webkit is fixed kindly ask Firefox to update their webkit code. I have a ticket for this here already, no point wasting time. If Firefox works Safari can just go jump in the bin. 

https://bugzilla.mozilla.org/show_bug.cgi?id=1256083
Comment 50 Daniel Rossi 2016-03-21 19:31:57 PDT
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
Comment 51 Daniel Rossi 2016-06-03 08:16:48 PDT
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.
Comment 52 Alexey Proskuryakov 2016-06-03 09:56:20 PDT
Please see <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>.
Comment 53 Zeno Crivelli 2016-06-14 11:43:04 PDT
Ok, I haven't tested it yet, but this is apparently fixed in Safari 10 on macOS:

https://twitter.com/zenoc/status/742770789880111104

(but not yet on iOS)
Comment 54 Klaus Reinfeld 2016-06-14 11:54:35 PDT
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...
Comment 55 Daniel Rossi 2016-06-14 18:58:09 PDT
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 ?
Comment 56 Eric Carlson 2016-06-15 10:32:07 PDT
(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.
Comment 57 Zeno Crivelli 2016-06-24 06:27:10 PDT
Regarding fix on iOS, do you think there's a chance it will land in the final iOS 10 release, or we are looking at iOS 11?
Comment 58 Daniel Rossi 2016-06-24 06:33:17 PDT
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.
Comment 59 Daniel Rossi 2016-06-25 01:36:39 PDT
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.
Comment 60 Eric Carlson 2016-06-25 10:09:01 PDT
(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.
Comment 61 chris 2016-06-27 19:05:12 PDT
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.
Comment 62 Daniel Rossi 2016-06-27 21:23:28 PDT
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.
Comment 63 Daniel Rossi 2016-07-06 08:45:36 PDT
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.
Comment 64 Rik Heijdens 2016-09-22 10:35:18 PDT
This is also a blocker for JW Player 360 video playback on iOS/Safari.
Comment 65 Daniel Rossi 2016-09-22 13:02:13 PDT
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.
Comment 66 Daniel Rossi 2016-09-22 13:14:48 PDT
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.
Comment 67 Rik Heijdens 2016-09-22 13:29:12 PDT
(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.
Comment 68 Daniel Rossi 2016-09-23 20:07:01 PDT
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.
Comment 69 Tim Pham 2016-09-27 23:09:13 PDT
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
Comment 70 Daniel Rossi 2016-09-27 23:50:10 PDT
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.
Comment 71 Edwin 2016-11-03 06:05:46 PDT
Hi Daniel Rossi,

I'm trying to make HLS work with WebGL in iOS Safari, but still no luck for now, it's driving me like crazy. How's your progress, any luck on solving this issue? 

Regards,
Edwin
Comment 72 Daniel Rossi 2016-11-03 06:27:48 PDT
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
Comment 73 Daniel Rossi 2016-11-03 06:28:51 PDT
Still requires the CORS proxy of course because of this CORS nightmare issue.  As a reduction method  I will try HLS on the same host without CORS proxy and see what happens.
Comment 74 Daniel Rossi 2016-11-03 06:32:28 PDT
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.
Comment 75 Edwin 2016-11-05 03:47:09 PDT
Hi Daniel,

I've tried your demo:
http://dev.electroteque.org/threejs/webglworking.html
and it seems worked in iOS 10.1.1 safari with image rendered but flipped.

Regards,
Edwin
Comment 76 Daniel Rossi 2016-11-05 04:32:11 PDT
Edwin is it possible to comment here ?

https://bugs.webkit.org/show_bug.cgi?id=163866#c3

OK so the fixes may work on IOS 10 not IOS 9. 

The actual Three.js variant fix is here, the texture is flipped via the mesh instead of in the shader program which happens per frame. 

http://dev.electroteque.org/threejs/hls.html

This ticket is about CORS issues.
Comment 77 Daniel Rossi 2016-11-08 11:59:00 PST
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.html
http://dev.electroteque.org/webgl/threejscors-hls.html
Comment 78 Daniel Rossi 2016-11-09 06:17:49 PST
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.
Comment 79 Daniel Rossi 2016-11-09 17:23:20 PST
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;
    }
Comment 80 Kieran Farr 2016-12-01 15:49:36 PST
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.
Comment 81 Esteban 2017-02-05 18:41:10 PST
Any news on this bug fix for iOS? Currently this is blocking us from deploying 360 video to production using iOs and videos hosted in CDN
Comment 82 Daniel Rossi 2017-02-05 18:59:01 PST
IOS 10 still not fixed. IOS 10 required framework changes I believe. Which they are fixing underlying issues first ?
Comment 83 mrosellini 2017-03-15 09:50:23 PDT
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...
Comment 84 Jer Noble 2017-03-15 11:22:30 PDT
(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.
Comment 85 mrosellini 2017-03-15 12:30:05 PDT
(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.
Comment 86 gtk2k 2017-03-19 18:31:45 PDT
I have been waiting for a long time for this bug to be fixed.
Comment 87 Madjid Taha 2017-03-29 06:35:26 PDT
Hi guys,

Lately I got that problem at work and I found a client-side workaround waiting for this bug to be fixed so I decide to write an article about it.
I hope it can help some of you.
https://blog.madj.me/safari-ios-problems-when-drawing-video/
Comment 88 Daniel Rossi 2017-03-29 07:44:45 PDT
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.
Comment 89 Daniel Rossi 2017-03-29 07:49:45 PDT
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.
Comment 90 Jon Lee 2017-04-09 08:56:38 PDT
*** Bug 170455 has been marked as a duplicate of this bug. ***