My impression as a user on this is that, since the very first few prototypes with WKWebView from Shazron and some others, to later the Ionic attempts at solving/masking the usual issues, to the current situation where we have a deprecated UIWebView, is still the same as it was at the start: using WKWebView on Cordova feels like a scary hack.
I understand that we might have gotten the userbase (myself included) used to having an easy life by not having CORS and similar concepts since the start, which now brings those concepts as a burden, instead of a standard. I also understand that the deprecation window alongside our sdk support window with the custom scheme handler on top make for a very tricky spot to decide how to move. I also understand and follow the issues created by the iOS and safari dev teams with so many hiccups along the way. Even though someone who has followed cordova development up-close for a very long time like me can understand all the pressure points and explanations behind the current state of WKWebView, I can't dismiss this feeling that "it's still not ready, still not the right time to pick it up". I personaly already had the unpleasure of going through `raw -> cross-walk -> raw` on the android side of things (which I'm still handling with database migration stuff), and I'd love for users not to have to deal with this kind of decision in the near future. I initially thought about investing on the idea that we should mention the work done by the Ionic team on this topic on the blog post PR, but I guess we don't want to risk even more confusion (at what cost?). I don't have an answer or fix to the issues and confusions I bring here, nor do I blame them on any specific cause, and I think enlightment will come with time and trial only. I just hope I'm the only one that can't scratch this feeling that WKWebView is a hack. 2018-08-03 0:29 GMT-03:00 Darryl Pogue <dvpdin...@gmail.com>: > 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 <shaz...@gmail.com> 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 <dvpdin...@gmail.com> wrote: > > > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron <shaz...@gmail.com> 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: dev-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > > -- *Frederico Galvão* Diretor de Tecnologia PontoGet Inovação Web ( +55(62) 8131-5720 * www.pontoget.com.br <http://www.pontoget.com/>
