If there are no further comments regarding the blog post, I will publish it by EOD (Pacific Time) Wed August 8th, 2018 https://github.com/apache/cordova-docs/pull/867 On Wed, Aug 8, 2018 at 3:14 PM Shazron <shaz...@gmail.com> wrote: > > Apple has other goals with WKWebView (a lot deals with making it more > secure), and I doubt they are aligned with Cordova's goals (although > they did a patch to load file urls for iOS 9 I believe, that helped us > avoid the local webserver route). I think almost all of us know that > WKWebView usage by Cordova is an implementation with a lot of > patchwork, and definitely hacky, so that we can achieve feature parity > with our usage of UIWebView. > > Ionic is always welcome to chime in and contribute to the blog post, > and submit patches. > > Unfortunately Apple has made the choice for us. We have to move on to > WKWebView, and we will try our best to make it seamless. > > > > > On Wed, Aug 8, 2018 at 2:27 PM Frederico Galvão > <frederico.gal...@pontoget.com.br> wrote: > > > > 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/>
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
