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 > >> > >> >
