135379 2014-07-29 03:03:46 -0700 iOS 8 / OSX 10.10 WebGL - using a video from an other domain fails (CORS bug) 2023-03-23 08:38:47 -0700 1 1 1 Unclassified WebKit Media 528+ (Nightly build) iPhone / iPad Unspecified RESOLVED FIXED http://krpano.com/ios/bugs/ios8-webgl-video-cors/ InRadar P2 Normal --- 1 mail webkit-unassigned achristensen alexwriter2003 andykenward ap bfulgham brendan chris cjl_hyz dbates Dczaretsky denny.ferrassoli dino donni ebrahim edwin.cen electroteque eoconnor eric.carlson ewagner gmsyrimis gtk2k jari.bakken jer.noble joepeck jonobrandel kfarr kkinnunen lon9man madjid.taha mehmetgelisin m.goleb+bugzilla minhthanh91sg moo_lj89 mrosellini priv5 rik rleider sam sean simon.fraser ssoloviev webkit-bug-importer yannick.delwiche yuri.zapuchlak zeno oldest_to_newest 1025429 0 mail 2014-07-29 03:03:46 -0700 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. 1026058 1 achristensen 2014-07-31 13:57:36 -0700 This would be fixed by implementing MediaPlayerPrivateAVFoundationObjC::didPassCORSAccessCheck. See https://bugs.webkit.org/show_bug.cgi?id=99037 1035749 2 mail 2014-09-17 12:25:32 -0700 iOS 8 release and still not fixed! Very bad! 1035766 3 webkit-bug-importer 2014-09-17 13:58:09 -0700 <rdar://problem/18370945> 1035816 4 dino 2014-09-17 19:13:11 -0700 This is a media bug. Our AVFoundation backend does not check CORS for tainting. 1035817 5 webkit-bug-importer 2014-09-17 19:13:40 -0700 <rdar://problem/18375542> 1037405 6 mail 2014-09-25 22:18:38 -0700 Still not fixed in iOS 8.0.2! 1038157 7 mail 2014-09-29 23:57:11 -0700 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? 1038158 8 ap 2014-09-30 00:04:57 -0700 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. 1038306 9 yuri.zapuchlak 2014-09-30 12:54:25 -0700 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). 1073921 10 sean 2015-03-03 18:27:35 -0800 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! 1095817 11 rleider 2015-05-18 21:26:08 -0700 This issue is a blocker for YouTube 360 and 3D videos in webkit. 1096212 12 mail 2015-05-20 01:53:49 -0700 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... 1100440 13 mail 2015-06-08 13:29:07 -0700 Still not fixed in iOS 9 beta 1... 1111080 14 rleider 2015-07-21 15:20:36 -0700 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. 1116750 15 rleider 2015-08-11 15:30:29 -0700 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. 1133680 16 denny.ferrassoli 2015-10-15 16:49:58 -0700 This also fails on most recent desktop Safari 9.0 (11601.1.56). 1147573 17 endlessroad 2015-12-08 19:47:24 -0800 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! 1147632 18 266976 endlessroad 2015-12-09 01:43:01 -0800 Created attachment 266976 Proof of concept patch 1147641 19 endlessroad 2015-12-09 02:00:29 -0800 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. 1148193 20 266976 jer.noble 2015-12-10 08:40:19 -0800 Comment on attachment 266976 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. 1148194 21 jer.noble 2015-12-10 08:41:18 -0800 (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? 1148198 22 rleider 2015-12-10 08:53:50 -0800 Yes, YouTube would use MSE for 360 videos on Safari desktop. 1148211 23 endlessroad 2015-12-10 09:12:31 -0800 (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! 1148224 24 jer.noble 2015-12-10 09:31:51 -0800 (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. 1148230 25 endlessroad 2015-12-10 09:49:49 -0800 (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 ) 1148244 26 jer.noble 2015-12-10 10:19:31 -0800 (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. 1148292 27 rleider 2015-12-10 13:32:25 -0800 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? 1148694 28 electroteque 2015-12-12 02:06:59 -0800 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. 1148695 29 electroteque 2015-12-12 02:09:38 -0800 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 ? 1148795 30 electroteque 2015-12-13 01:09:47 -0800 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. 1150503 31 electroteque 2015-12-18 22:34:32 -0800 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 ! 1162393 32 Dczaretsky 2016-02-05 08:46:21 -0800 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? 1162395 33 electroteque 2016-02-05 08:55:55 -0800 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. 1162397 34 electroteque 2016-02-05 08:58:41 -0800 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 1162398 35 electroteque 2016-02-05 09:02:34 -0800 Inline video is just another issue altogether and for another day. WebVR is unusable full stop on Iphone because of it :) 1162415 36 Dczaretsky 2016-02-05 09:44:16 -0800 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! 1162881 37 Dczaretsky 2016-02-08 08:26:41 -0800 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? 1162885 38 jer.noble 2016-02-08 08:45:50 -0800 (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. 1162904 39 electroteque 2016-02-08 10:06:41 -0800 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. 1162930 40 jer.noble 2016-02-08 11:03:12 -0800 (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. 1164337 41 jer.noble 2016-02-12 14:21:38 -0800 *** Bug 154189 has been marked as a duplicate of this bug. *** 1164456 42 electroteque 2016-02-12 18:09:14 -0800 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. 1164600 43 electroteque 2016-02-13 20:02:02 -0800 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. 1164789 44 Dczaretsky 2016-02-15 11:06:01 -0800 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. 1176767 45 Dczaretsky 2016-03-21 10:48:15 -0700 Can someone verify if this bug has been fixed in the new iOS 9.3 released today? 1176789 46 ap 2016-03-21 11:15:43 -0700 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. 1176826 47 mail 2016-03-21 13:21:35 -0700 Just finished updating and testing - unfortunately again nothing had been fixed, neither the CORS bug nor the bad video-to-WebGL-texture performance... 1176911 48 electroteque 2016-03-21 19:26:04 -0700 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. 1176912 49 electroteque 2016-03-21 19:28:20 -0700 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 1176917 50 electroteque 2016-03-21 19:31:57 -0700 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 1198932 51 electroteque 2016-06-03 08:16:48 -0700 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. 1198957 52 ap 2016-06-03 09:56:20 -0700 Please see <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>. 1202257 53 zeno 2016-06-14 11:43:04 -0700 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) 1202263 54 mail 2016-06-14 11:54:35 -0700 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... 1202436 55 electroteque 2016-06-14 18:58:09 -0700 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 ? 1202619 56 eric.carlson 2016-06-15 10:32:07 -0700 (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. 1205065 57 zeno 2016-06-24 06:27:10 -0700 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? 1205068 58 electroteque 2016-06-24 06:33:17 -0700 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. 1205344 59 electroteque 2016-06-25 01:36:39 -0700 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. 1205381 60 eric.carlson 2016-06-25 10:09:01 -0700 (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. 1205842 61 chris 2016-06-27 19:05:12 -0700 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. 1205863 62 electroteque 2016-06-27 21:23:28 -0700 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. 1208229 63 electroteque 2016-07-06 08:45:36 -0700 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. 1232495 64 rik 2016-09-22 10:35:18 -0700 This is also a blocker for JW Player 360 video playback on iOS/Safari. 1232576 65 electroteque 2016-09-22 13:02:13 -0700 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. 1232580 66 electroteque 2016-09-22 13:14:48 -0700 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. 1232584 67 rik 2016-09-22 13:29:12 -0700 (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. 1233094 68 electroteque 2016-09-23 20:07:01 -0700 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. 1234258 69 minhthanh91sg 2016-09-27 23:09:13 -0700 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 1234269 70 electroteque 2016-09-27 23:50:10 -0700 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. 1247690 71 edwin.cen 2016-11-03 06:05:46 -0700 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 1247691 72 electroteque 2016-11-03 06:27:48 -0700 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 1247692 73 electroteque 2016-11-03 06:28:51 -0700 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. 1247693 74 electroteque 2016-11-03 06:32:28 -0700 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. 1248470 75 edwin.cen 2016-11-05 03:47:09 -0700 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 1248473 76 electroteque 2016-11-05 04:32:11 -0700 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. 1249100 77 electroteque 2016-11-08 11:59:00 -0800 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 1249270 78 electroteque 2016-11-09 06:17:49 -0800 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. 1249601 79 electroteque 2016-11-09 17:23:20 -0800 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; } 1255529 80 kfarr 2016-12-01 15:49:36 -0800 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. 1273445 81 ewagner 2017-02-05 18:41:10 -0800 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 1273449 82 electroteque 2017-02-05 18:59:01 -0800 IOS 10 still not fixed. IOS 10 required framework changes I believe. Which they are fixing underlying issues first ? 1288092 83 mrosellini 2017-03-15 09:50:23 -0700 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... 1288145 84 jer.noble 2017-03-15 11:22:30 -0700 (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. 1288184 85 mrosellini 2017-03-15 12:30:05 -0700 (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. 1289426 86 gtk2k 2017-03-19 18:31:45 -0700 I have been waiting for a long time for this bug to be fixed. 1292368 87 madjid.taha 2017-03-29 06:35:26 -0700 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/ 1292383 88 electroteque 2017-03-29 07:44:45 -0700 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. 1292385 89 electroteque 2017-03-29 07:49:45 -0700 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. 1295803 90 jonlee 2017-04-09 08:56:38 -0700 *** Bug 170455 has been marked as a duplicate of this bug. *** 1332081 91 ssoloviev 2017-07-25 14:01:39 -0700 Hi! Any planning updates here? We have the same problems with showing videos as textures in Canvas. 1332086 92 jer.noble 2017-07-25 14:11:31 -0700 (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. 1332265 93 electroteque 2017-07-25 22:46:49 -0700 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. 1332267 94 chris 2017-07-25 22:59:43 -0700 (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? 1332269 95 jer.noble 2017-07-25 23:18:53 -0700 (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/>. 1332318 96 mail 2017-07-26 04:31:02 -0700 In the latest iOS 11 beta 4 from 24. July 2017 it is still NOT working! 1332321 97 electroteque 2017-07-26 04:45:22 -0700 "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 ! 1332327 98 electroteque 2017-07-26 05:28:55 -0700 According to the specs. like IOS 10. IOS 11 won't run on anything newer than a 2017 Ipad. Requires a new device. 1336359 99 electroteque 2017-08-07 21:59:17 -0700 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. 1336598 100 jer.noble 2017-08-08 12:57:49 -0700 (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. 1336811 101 electroteque 2017-08-08 18:13:53 -0700 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. 1336994 102 jer.noble 2017-08-09 09:19:54 -0700 (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:? 1337006 103 jer.noble 2017-08-09 09:50:30 -0700 (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. 1337026 104 electroteque 2017-08-09 10:27:26 -0700 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 1337063 105 jer.noble 2017-08-09 11:33:47 -0700 (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? 1337068 106 electroteque 2017-08-09 11:55:22 -0700 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. 1337397 107 electroteque 2017-08-10 05:33:27 -0700 I made a few extra examples from previous examples. hopefully these work as I was unable to get click and video playback in the simulator. one is the cors proxy. Works on Android. https://dev.electroteque.org/safari/example/ https://dev.electroteque.org/safari/example/proxy.html 1337447 108 jer.noble 2017-08-10 09:11:59 -0700 (In reply to Daniel Rossi from comment #107) > I made a few extra examples from previous examples. > > hopefully these work as I was unable to get click and video playback in the > simulator. one is the cors proxy. > > Works on Android. > > https://dev.electroteque.org/safari/example/ > https://dev.electroteque.org/safari/example/proxy.html The <video> element in these examples needs the “playsinline” attribute in order to not play in full screen mode on iPhone, but the non-proxy example seems to work correctly on iOS 11. 1337838 109 electroteque 2017-08-10 23:28:15 -0700 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. 1349889 110 donni 2017-09-18 07:50:20 -0700 I just tried the iOS 11 GM and the issue seems to persist. 1358679 111 moo_lj89 2017-10-10 01:44:13 -0700 Ios11 has solved the cross problem http://res7.utovr.com/player_src.html http://res7.utovr.com/player_src.html?src=http://cache.utovr.com/201508240527049953.mp4 1364138 112 cjl_hyz 2017-10-25 00:42:58 -0700 (In reply to MooLee from comment #111) > Ios11 has solved the cross problem > > > > http://res7.utovr.com/player_src.html > > > http://res7.utovr.com/player_src.html?src=http://cache.utovr.com/ > 201508240527049953.mp4 CROS problems really fixed in ios11. This UtoVR sample solved ios11 hls FLIP_Y problem，but the code is mixed by UtoVR， could you tell us how to fixing FLIP_Y problem. thanks! 1368425 113 electroteque 2017-11-04 23:34:30 -0700 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. 1377842 114 gmsyrimis 2017-12-04 13:10:32 -0800 @Daniel Rossi I can't seem to run VRView from the Cardboard SDK on iOS 11. Any pointers? https://codepen.io/anon/pen/VrRBNg 1378051 115 electroteque 2017-12-04 18:52:20 -0800 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. 1378185 116 gmsyrimis 2017-12-05 09:16:09 -0800 @Daniel Rossi The VRView in question is HTML5. https://developers.google.com/vr/concepts/vrview https://codepen.io/anon/pen/VrRBNg Could you have a look? 1741125 117 kkinnunen 2021-03-18 03:17:49 -0700 If I understand the comments correctly, the use case now works. I'll close this as fixed. Please file a new bug report if there are new problems around this area. 1741144 118 mail 2021-03-18 04:05:46 -0700 This is not fixed, the bug is still there and still annoying! Just try the link from the initial post on any iOS device: http://krpano.com/ios/bugs/ios8-webgl-video-cors/ 1741147 119 mail 2021-03-18 04:10:00 -0700 Sorry for the last post, I was wrong, it seems to work now. 1915600 122 electroteque 2022-11-30 06:56:59 -0800 I've had nobody complaining of CORS bugs. It was Fixed in IOS 11.1. Ive not seen a problem. Is this still happening ? HLS rendering has always been patchy and unstable however. 266976 2015-12-09 01:43:01 -0800 2015-12-10 08:40:19 -0800 Proof of concept patch video_cors.patch text/plain 6020 endlessroad SW5kZXg6IGF2Zm91bmRhdGlvbi9vYmpjL01lZGlhUGxheWVyUHJpdmF0ZUFWRm91bmRhdGlvbk9i akMuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSBhdmZvdW5kYXRpb24vb2JqYy9NZWRpYVBsYXllclByaXZhdGVB VkZvdW5kYXRpb25PYmpDLmgJKHJldmlzaW9uIDE5Mzc0NikKKysrIGF2Zm91bmRhdGlvbi9vYmpj L01lZGlhUGxheWVyUHJpdmF0ZUFWRm91bmRhdGlvbk9iakMuaAkod29ya2luZyBjb3B5KQpAQCAt MjExLDYgKzIxMSw4IEBACiAgICAgdmlydHVhbCB2b2lkIHVwZGF0ZVZpZGVvTGF5ZXJHcmF2aXR5 KCkgb3ZlcnJpZGU7CiAKICAgICB2aXJ0dWFsIGJvb2wgaGFzU2luZ2xlU2VjdXJpdHlPcmlnaW4o KSBjb25zdCBvdmVycmlkZTsKKyAgICB2aXJ0dWFsIGJvb2wgZGlkUGFzc0NPUlNBY2Nlc3NDaGVj aygpIGNvbnN0IG92ZXJyaWRlOworICAgIHZvaWQgZGlkRmluaXNoQ09SU0FjY2Vzc0NoZWNrKGJv b2wpOwogCiAgICAgTWVkaWFUaW1lIGdldFN0YXJ0RGF0ZSgpIGNvbnN0IG92ZXJyaWRlOwogCkBA IC00MDcsNiArNDA5LDcgQEAKICAgICBtdXRhYmxlIGJvb2wgbV9hbGxvd3NXaXJlbGVzc1ZpZGVv UGxheWJhY2s7CiAgICAgYm9vbCBtX3Nob3VsZFBsYXlUb1BsYXliYWNrVGFyZ2V0IHsgZmFsc2Ug fTsKICNlbmRpZgorICAgIGludCBtX2RpZFBhc3NDT1JTQWNjZXNzQ2hlY2s7CiB9OwogCiB9Cklu ZGV4OiBhdmZvdW5kYXRpb24vb2JqYy9NZWRpYVBsYXllclByaXZhdGVBVkZvdW5kYXRpb25PYmpD Lm1tCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIGF2Zm91bmRhdGlvbi9vYmpjL01lZGlhUGxheWVyUHJpdmF0ZUFW Rm91bmRhdGlvbk9iakMubW0JKHJldmlzaW9uIDE5Mzc0NikKKysrIGF2Zm91bmRhdGlvbi9vYmpj L01lZGlhUGxheWVyUHJpdmF0ZUFWRm91bmRhdGlvbk9iakMubW0JKHdvcmtpbmcgY29weSkKQEAg LTUxMSw2ICs1MTEsNyBAQAogI2lmIEVOQUJMRShXSVJFTEVTU19QTEFZQkFDS19UQVJHRVQpCiAg ICAgLCBtX2FsbG93c1dpcmVsZXNzVmlkZW9QbGF5YmFjayh0cnVlKQogI2VuZGlmCisgICAgLCBt X2RpZFBhc3NDT1JTQWNjZXNzQ2hlY2soMCkKIHsKICNpZiBFTkFCTEUoRU5DUllQVEVEX01FRElB X1YyKQogICAgIHBsYXllclRvUHJpdmF0ZU1hcCgpLnNldChwbGF5ZXIsIHRoaXMpOwpAQCAtODMw LDcgKzgzMSwxNCBAQAogCiBzdGF0aWMgTlNVUkwgKmNhbm9uaWNhbFVSTChjb25zdCBTdHJpbmcm IHVybCkKIHsKLSAgICBOU1VSTCAqY29jb2FVUkwgPSBVUkwoUGFyc2VkVVJMU3RyaW5nLCB1cmwp OworICAgIFVSTCBwYXJzZWRVUkwoUGFyc2VkVVJMU3RyaW5nLCB1cmwpOworICAgIGlmIChwYXJz ZWRVUkwucHJvdG9jb2woKS5sb3dlcigpID09ICJodHRwIikgeworICAgICAgICBwYXJzZWRVUkwu c2V0UHJvdG9jb2woIm1vY2staHR0cCIpOworICAgIH0gZWxzZSBpZiAocGFyc2VkVVJMLnByb3Rv Y29sKCkubG93ZXIoKSA9PSAiaHR0cHMiKSB7CisgICAgICAgIHBhcnNlZFVSTC5zZXRQcm90b2Nv bCgibW9jay1odHRwcyIpOworICAgIH0KKyAgICAKKyAgICBOU1VSTCAqY29jb2FVUkwgPSBwYXJz ZWRVUkw7CiAgICAgaWYgKHVybC5pc0VtcHR5KCkpCiAgICAgICAgIHJldHVybiBjb2NvYVVSTDsK IApAQCAtMjIwOCw2ICsyMjE2LDE2IEBACiAgICAgcmV0dXJuIHJlc29sdmVkT3JpZ2luLmdldCgp LmlzU2FtZVNjaGVtZUhvc3RQb3J0KCZyZXF1ZXN0ZWRPcmlnaW4uZ2V0KCkpOwogfQogCitib29s IE1lZGlhUGxheWVyUHJpdmF0ZUFWRm91bmRhdGlvbk9iakM6OmRpZFBhc3NDT1JTQWNjZXNzQ2hl Y2soKSBjb25zdAoreworICAgIC8vQVNTRVJUKG1fZGlkUGFzc0NPUlNBY2Nlc3NDaGVjayAhPSAw KTsKKyAgICByZXR1cm4gbV9kaWRQYXNzQ09SU0FjY2Vzc0NoZWNrID09IDI7Cit9CisKK3ZvaWQg TWVkaWFQbGF5ZXJQcml2YXRlQVZGb3VuZGF0aW9uT2JqQzo6ZGlkRmluaXNoQ09SU0FjY2Vzc0No ZWNrKGJvb2wgcGFzc2VkKSB7CisgICAgbV9kaWRQYXNzQ09SU0FjY2Vzc0NoZWNrID0gcGFzc2Vk ID8gMiA6IDE7Cit9CisKICNpZiBIQVZFKEFWRk9VTkRBVElPTl9WSURFT19PVVRQVVQpCiB2b2lk IE1lZGlhUGxheWVyUHJpdmF0ZUFWRm91bmRhdGlvbk9iakM6OmNyZWF0ZVZpZGVvT3V0cHV0KCkK IHsKQEAgLTM0MTgsNyArMzQzNiwxMyBAQAogICAgIGlmICghbV9hdkFzc2V0IHx8IFttX2F2QXNz ZXQgc3RhdHVzT2ZWYWx1ZUZvcktleTpAInJlc29sdmVkVVJMIiBlcnJvcjpudWxscHRyXSAhPSBB VktleVZhbHVlU3RhdHVzTG9hZGVkKQogICAgICAgICByZXR1cm4gTWVkaWFQbGF5ZXJQcml2YXRl QVZGb3VuZGF0aW9uOjpyZXNvbHZlZFVSTCgpOwogCi0gICAgcmV0dXJuIFVSTChbbV9hdkFzc2V0 IHJlc29sdmVkVVJMXSk7CisgICAgVVJMIHVybChbbV9hdkFzc2V0IHJlc29sdmVkVVJMXSk7Cisg ICAgaWYgKHVybC5wcm90b2NvbCgpID09ICJtb2NrLWh0dHAiKSB7CisgICAgICAgIHVybC5zZXRQ cm90b2NvbCgiaHR0cCIpOworICAgIH0gZWxzZSBpZiAodXJsLnByb3RvY29sKCkgPT0gIm1vY2st aHR0cHMiKSB7CisgICAgICAgIHVybC5zZXRQcm90b2NvbCgiaHR0cHMiKTsKKyAgICB9CisgICAg cmV0dXJuIHVybDsKIH0KIAogTlNBcnJheSogYXNzZXRNZXRhZGF0YUtleU5hbWVzKCkKSW5kZXg6 IGF2Zm91bmRhdGlvbi9vYmpjL1dlYkNvcmVBVkZSZXNvdXJjZUxvYWRlci5oCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIGF2Zm91bmRhdGlvbi9vYmpjL1dlYkNvcmVBVkZSZXNvdXJjZUxvYWRlci5oCShyZXZpc2lv biAxOTM3NDYpCisrKyBhdmZvdW5kYXRpb24vb2JqYy9XZWJDb3JlQVZGUmVzb3VyY2VMb2FkZXIu aAkod29ya2luZyBjb3B5KQpAQCAtNDIsNiArNDIsNyBAQAogY2xhc3MgQ2FjaGVkUmF3UmVzb3Vy Y2U7CiBjbGFzcyBDYWNoZWRSZXNvdXJjZUxvYWRlcjsKIGNsYXNzIE1lZGlhUGxheWVyUHJpdmF0 ZUFWRm91bmRhdGlvbk9iakM7CitjbGFzcyBTZWN1cml0eU9yaWdpbjsKIAogY2xhc3MgV2ViQ29y ZUFWRlJlc291cmNlTG9hZGVyIDogcHVibGljIFJlZkNvdW50ZWQ8V2ViQ29yZUFWRlJlc291cmNl TG9hZGVyPiwgQ2FjaGVkUmF3UmVzb3VyY2VDbGllbnQgewogICAgIFdURl9NQUtFX05PTkNPUFlB QkxFKFdlYkNvcmVBVkZSZXNvdXJjZUxvYWRlcik7IFdURl9NQUtFX0ZBU1RfQUxMT0NBVEVEOwpA QCAtNjcsNiArNjgsNyBAQAogICAgIE1lZGlhUGxheWVyUHJpdmF0ZUFWRm91bmRhdGlvbk9iakMq IG1fcGFyZW50OwogICAgIFJldGFpblB0cjxBVkFzc2V0UmVzb3VyY2VMb2FkaW5nUmVxdWVzdD4g bV9hdlJlcXVlc3Q7CiAgICAgQ2FjaGVkUmVzb3VyY2VIYW5kbGU8Q2FjaGVkUmF3UmVzb3VyY2U+ IG1fcmVzb3VyY2U7CisgICAgUmVmUHRyPFNlY3VyaXR5T3JpZ2luPiBtX29yaWdpbjsKIH07CiAK IH0KSW5kZXg6IGF2Zm91bmRhdGlvbi9vYmpjL1dlYkNvcmVBVkZSZXNvdXJjZUxvYWRlci5tbQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBhdmZvdW5kYXRpb24vb2JqYy9XZWJDb3JlQVZGUmVzb3VyY2VMb2FkZXIu bW0JKHJldmlzaW9uIDE5Mzc0NikKKysrIGF2Zm91bmRhdGlvbi9vYmpjL1dlYkNvcmVBVkZSZXNv dXJjZUxvYWRlci5tbQkod29ya2luZyBjb3B5KQpAQCAtMzEsOCArMzEsMTAgQEAKICNpbXBvcnQg IkNhY2hlZFJhd1Jlc291cmNlLmgiCiAjaW1wb3J0ICJDYWNoZWRSZXNvdXJjZUxvYWRlci5oIgog I2ltcG9ydCAiQ2FjaGVkUmVzb3VyY2VSZXF1ZXN0LmgiCisjaW1wb3J0ICJDcm9zc09yaWdpbkFj Y2Vzc0NvbnRyb2wuaCIKICNpbXBvcnQgIk1lZGlhUGxheWVyUHJpdmF0ZUFWRm91bmRhdGlvbk9i akMuaCIKICNpbXBvcnQgIlJlc291cmNlTG9hZGVyT3B0aW9ucy5oIgorI2ltcG9ydCAiU2VjdXJp dHlPcmlnaW4uaCIKICNpbXBvcnQgIlNoYXJlZEJ1ZmZlci5oIgogI2ltcG9ydCAiU29mdExpbmtp bmcuaCIKICNpbXBvcnQgIlVUSVV0aWxpdGllcy5oIgpAQCAtNjYsMTIgKzY4LDIwIEBACiAgICAg ICAgIHJldHVybjsKIAogICAgIFVSTCByZXF1ZXN0VVJMID0gW1ttX2F2UmVxdWVzdC5nZXQoKSBy ZXF1ZXN0XSBVUkxdOworICAgIGlmIChyZXF1ZXN0VVJMLnByb3RvY29sKCkgPT0gIm1vY2staHR0 cCIpIHsKKyAgICAgICAgcmVxdWVzdFVSTC5zZXRQcm90b2NvbCgiaHR0cCIpOworICAgIH0gZWxz ZSBpZiAocmVxdWVzdFVSTC5wcm90b2NvbCgpID09ICJtb2NrLWh0dHBzIikgeworICAgICAgICBy ZXF1ZXN0VVJMLnNldFByb3RvY29sKCJodHRwcyIpOworICAgIH0KIAogICAgIC8vIENvbnRlbnRT ZWN1cml0eVBvbGljeUltcG9zaXRpb246OkRvUG9saWN5Q2hlY2sgaXMgYSBwbGFjZWhvbGRlciB2 YWx1ZS4gSXQgZG9lcyBub3QgYWZmZWN0IHRoZSByZXF1ZXN0IHNpbmNlIENvbnRlbnQgU2VjdXJp dHkgUG9saWN5IGRvZXMgbm90IGFwcGx5IHRvIHJhdyByZXNvdXJjZXMuCiAgICAgQ2FjaGVkUmVz b3VyY2VSZXF1ZXN0IHJlcXVlc3QoUmVzb3VyY2VSZXF1ZXN0KHJlcXVlc3RVUkwpLCBSZXNvdXJj ZUxvYWRlck9wdGlvbnMoU2VuZENhbGxiYWNrcywgRG9Ob3RTbmlmZkNvbnRlbnQsIEJ1ZmZlckRh dGEsIERvTm90QWxsb3dTdG9yZWRDcmVkZW50aWFscywgRG9Ob3RBc2tDbGllbnRGb3JDcm9zc09y aWdpbkNyZWRlbnRpYWxzLCBEb1NlY3VyaXR5Q2hlY2ssIFVzZURlZmF1bHRPcmlnaW5SZXN0cmlj dGlvbnNGb3JUeXBlLCBEb05vdEluY2x1ZGVDZXJ0aWZpY2F0ZUluZm8sIENvbnRlbnRTZWN1cml0 eVBvbGljeUltcG9zaXRpb246OkRvUG9saWN5Q2hlY2ssIERlZmVyc0xvYWRpbmdQb2xpY3k6OkFs bG93RGVmZXJzTG9hZGluZykpOwogCiAgICAgcmVxdWVzdC5tdXRhYmxlUmVzb3VyY2VSZXF1ZXN0 KCkuc2V0UHJpb3JpdHkoUmVzb3VyY2VMb2FkUHJpb3JpdHk6Okxvdyk7CiAgICAgQ2FjaGVkUmVz b3VyY2VMb2FkZXIqIGxvYWRlciA9IG1fcGFyZW50LT5wbGF5ZXIoKS0+Y2FjaGVkUmVzb3VyY2VM b2FkZXIoKTsKKyAgICBtX29yaWdpbiA9IGxvYWRlci0+ZG9jdW1lbnQoKSA/IGxvYWRlci0+ZG9j dW1lbnQoKS0+c2VjdXJpdHlPcmlnaW4oKSA6IG51bGxwdHI7CisgICAgQVNTRVJUKG1fb3JpZ2lu LmdldCgpKTsKKyAgICB1cGRhdGVSZXF1ZXN0Rm9yQWNjZXNzQ29udHJvbChyZXF1ZXN0Lm11dGFi bGVSZXNvdXJjZVJlcXVlc3QoKSwgbV9vcmlnaW4uZ2V0KCksIERvTm90QWxsb3dTdG9yZWRDcmVk ZW50aWFscyk7CiAgICAgbV9yZXNvdXJjZSA9IGxvYWRlciA/IGxvYWRlci0+cmVxdWVzdFJhd1Jl c291cmNlKHJlcXVlc3QpIDogMDsKICAgICBpZiAobV9yZXNvdXJjZSkKICAgICAgICAgbV9yZXNv dXJjZS0+YWRkQ2xpZW50KHRoaXMpOwpAQCAtMTA0LDYgKzExNCwxNCBAQAogICAgIEFTU0VSVChy ZXNvdXJjZSA9PSBtX3Jlc291cmNlKTsKICAgICBVTlVTRURfUEFSQU0ocmVzb3VyY2UpOwogCisg ICAgYm9vbCBkaWRQYXNzQ09SU0FjY2Vzc0NoZWNrID0gcmVzb3VyY2UtPnBhc3Nlc0FjY2Vzc0Nv bnRyb2xDaGVjaygqbV9vcmlnaW4uZ2V0KCkpOworICAgIG1fcGFyZW50LT5kaWRGaW5pc2hDT1JT QWNjZXNzQ2hlY2soZGlkUGFzc0NPUlNBY2Nlc3NDaGVjayk7CisgICAgaWYgKCFkaWRQYXNzQ09S U0FjY2Vzc0NoZWNrKSB7CisgICAgICAgIFttX2F2UmVxdWVzdC5nZXQoKSBmaW5pc2hMb2FkaW5n XTsKKyAgICAgICAgc3RvcExvYWRpbmcoKTsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKwogICAg IGludCBzdGF0dXMgPSByZXNwb25zZS5odHRwU3RhdHVzQ29kZSgpOwogICAgIGlmIChzdGF0dXMg JiYgKHN0YXR1cyA8IDIwMCB8fCBzdGF0dXMgPiAyOTkpKSB7CiAgICAgICAgIFttX2F2UmVxdWVz dC5nZXQoKSBmaW5pc2hMb2FkaW5nV2l0aEVycm9yOjBdOwo=