Blog post up: https://cordova.apache.org/news/2018/08/01/future-cordova-ios-webview.html
Retweet this: https://twitter.com/apachecordova/status/1027397670430601216 On Thu, Aug 9, 2018 at 9:55 AM Shazron <shaz...@gmail.com> wrote: > > Julio, > Darryl mentioned " iframes being cross origin (so no accessing the > parent/child document)" which means that it is a break from existing > UIWebView behaviour that users expect, that will now break. There are > workarounds: > https://medium.com/@DrawandCode/how-to-communicate-with-iframes-inside-webview-2c9c86436edb > but this is not very cross-platform, nor something we want to > encourage further. Like Jesse said, it happens to work with UIWebView > -- not something we actively support. > > There is a software philosophy (probably some Microsoft camp) that > says you shouldn't break users when you upgrade -- if users rely on a > 'bug' for so long (in this case no CORS), it has now become a feature > -- but that is if you control the platform. We however don't have > control over WKWebView, so its not up to us. That is why I am > reluctant to bake in features that workaround some of these security > controls, and instead rely on external plugins (my personal opinion). > It should be an active decision from the developer to override the > controls of WKWebView if they so choose, and we will help with > information on how to do so as a stopgap, not as the ultimate > solution. > On Wed, Aug 8, 2018 at 10:47 PM julio cesar sanchez > <jcesarmob...@gmail.com> wrote: > > > > What's exactly the iframe problem? > > > > El mié., 8 ago. 2018 a las 10:05, Niklas Merz (<niklas.m...@rhoen.de>) > > escribió: > > > > > +1 > > > > > > I am really happy to hear about the WKwebview future. I tried WKwebview > > > some time ago and it did not work well with our app. I think the changes > > > mentioned in the blog post will make the transition to WKwebview easier. > > > Not supporting some features like iframes may be an issue for some users > > > they should be aware of. > > > > > > Am 8. Aug. 2018, 09:30, um 09:30, Jesse <purplecabb...@gmail.com> schrieb: > > > >+1. Please post it. > > > > > > > >I think it is better to put it out there and get feedback from the > > > >wider > > > >community, than sit and try to perfect a message here with a subset of > > > >subscribers. > > > >We can only do the best we can with what we have. > > > > > > > >Regarding things like iframes, I am not sure they are worth keeping > > > >around, > > > >it seems like a bit of an anti-pattern and a better inappbrowser might > > > >be a > > > >better approach ... really what I mean is, we have focused so much on > > > >making EVERYTHING-WEB work in cordova, but we may be coming to a time > > > >where > > > >we have to focus on just the features we need to build good hybrid > > > >apps. > > > > > > > >We never promised anyone that iframes would work ... they just always > > > >have. > > > > > > > > > > > > > > > > > > > > > > > >@purplecabbage > > > >risingj.com > > > > > > > >On Wed, Aug 8, 2018 at 12:16 AM, Shazron <shaz...@gmail.com> wrote: > > > > > > > >> 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 > > > >> > > > >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
