We definitely have to explore this more. I doubt we can ever be perfect at the first run at it, but we've got to lay the foundation for the eventual patches.
On Fri, Aug 3, 2018 at 11:30 AM Darryl Pogue <[email protected]> wrote: > > One concern with the Oracle plugin is that it's only patching the > obvious cases of XHR and fetch, but doesn't handle things like iframes > being cross origin (so no accessing the parent/child document) or > local image assets being cross origin when drawn to canvas (thus > tainting the canvas and making it impossible to read pixel data from > it). SVG icons aren't allowed to load when using <use > xlink:href="asset/icon.svg#whatever"> because that's considered cross > origin. We ran into _so_ many weird cases caused by cross origin > issues when we upgraded our app to WKWebView. > > I haven't had a chance to dig into the custom scheme stuff, but my > understanding is that everything would use the custom scheme instead > of file:/// and cordova-ios would have a scheme handler that would map > those to filesystem files, read those files with native code, and > return the data as a response. Similar in some ways to NSURLProtocol, > but asynchronous and with limited access to form data. > > On Thu, Aug 2, 2018 at 7:44 PM Shazron <[email protected]> wrote: > > > > Our policy has been we support the currently shipping iOS version, > > plus one back. This is because of device version testing complexities. > > It may work on older iOS versions if we code it with the right > > safeguards, but that is not guaranteed. When iOS 12 ships this fall, > > we would drop iOS 10 support (support as in testing for it, like I > > said it might still work). > > > > We could do the custom scheme -- or just use the Oracle plugin since > > that bridges it to using NSURLConnection, which has no restrictions. > > This will work on any iOS version. I would opt for the easiest > > solution *for now* to get something out. > > > > Using cdvapp://index.html, will all future file:// references in that > > index.html file work, or still have the same restrictions? I'll have > > to do some tests (unless you know already?) > > > > Regarding the fallback, the point of this bridge plugin is that the > > switching is an active decision by the developer (a hard break) and is > > to aid in migrating completely to WKWebView. If we had an automatic > > fallback, it might be a crutch until its too late and UIWebView is > > gone and they are surprised since it was all working "behind the > > scenes". > > > > On Fri, Aug 3, 2018 at 1:22 AM Darryl Pogue <[email protected]> wrote: > > > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron <[email protected]> wrote: > > > > > > > > 4. XmlHttpRequests don't work, because of Cross-Origin Resource > > > > Sharing issue (CORS). There is a workaround plugin created by Oracle > > > > (UPL licensed, which is Apache-2.0 compatible). See > > > > https://issues.apache.org/jira/browse/CB-10143 > > > > > > This happens because we're using file:/// URLs, which are subject to > > > additional security restrictions in WKWebView. Every file is treated > > > as its own origin, so a page can't make an XHR request to something > > > like file:///etc/passwd, but that same feature also means it can't > > > make an XHR request to ./assets/whatever.js > > > > > > The encouraged solution to this is to implement a custom scheme using > > > WKURLSchemeHandler and handle serving the files from the filesystem > > > yourself. This means the entire app would be served from something > > > like cdvapp://index.html rather than a file:/// URL. > > > Unfortunately, that API was only added in iOS 11, and Cordova > > > currently supports as far back as iOS 9, and the next major will > > > probably still want to support iOS 10? > > > > > > If we have the ability to swap the webview at runtime, it might be > > > worth investigating whether it makes sense to add a custom scheme for > > > iOS 11+ and WKWebView, and provide a way to fallback to UIWebView for > > > iOS 10? > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
