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
