[Webkit-unassigned] [Bug 186353] iOS 11.4 breaks video playback in Cordova apps

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=186353

--- Comment #4 from Ashley Gullen <ashley at scirra.com> ---
The log simply says "SecurityError: The operation is insecure." It's logged from a catch handler caused by an exception thrown in the following line:

gl.texSubImage2D(gl.TEXTURE_2D, 0, 0, 0, formatspec.format, formatspec.type, data);

where 'data' is a <video> whose src is a blob URL similar to "blob:null/...". The error appears to be due to the fact the video is considered a cross-origin video, since it has a 'null' origin, even though it was created by script in the same document - presumably a change to the file: protocol that the page is running on.

None of this code uses ImageBitmap at all. Does Safari use ImageBitmap internally for the texSubImage2D call? If not, then I believe that ImageBitmap is not involved in this.

If you want a repro that doesn't involve Cordova, it's simple: make an app that loads a HTML file from the bundle in a WKWebView. (This is the basis of a Cordova app.) In that HTML file, try to load a video and upload it to a WebGL texture. Any existing "video playback in WebGL" sample should do, e.g.: https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Animating_textures_in_WebGL

You'll quickly run in to a bunch of difficult problems:
- if you just set the video src to the video file in the bundle, it counts as cross-origin so blocks the texture upload
- XMLHttpRequest fails since it counts as cross-origin
- fetch() fails since it is not supported on file://
- you can't host all the files on a HTTP server, since you can't pick a fixed port that is guaranteed to be free, and if you pick a varying port, then the storage origin changes so you keep losing saved data
- using Cordova APIs, or otherwise calling in to native code, can read the file and return it to JavaScript as a Blob. This used to work. Now it's broken again due to the problem reported here.

It does seem like nobody has ever really thought about how to properly support apps like this. The CORS restrictions are incredibly severe so you have to use hacks to work around them; then those hacks occasionally break with iOS updates, causing existing apps to break. It would be great if there was better support for this in general so WKWebView was easier to use and we didn't have to risk apps breaking when things are changed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180619/4a12aee9/attachment-0001.html>