Re: WKWebView plugin - issues before baking it in to cordova-ios
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 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 > wrote: > > > > What's exactly the iframe problem? > > > > El mié., 8 ago. 2018 a las 10:05, Niklas Merz () > > 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 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 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 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 > > > >> > 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 > > > >>
Re: WKWebView plugin - issues before baking it in to cordova-ios
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 wrote: > > What's exactly the iframe problem? > > El mié., 8 ago. 2018 a las 10:05, Niklas Merz () > 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 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 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 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 > > >> > 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
What's exactly the iframe problem? El mié., 8 ago. 2018 a las 10:05, Niklas Merz () 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 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 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 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 > >> > 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 : > >> > > > >> > > > 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
+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 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 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 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 >> > 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 : >> > > >> > > > 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 > > > > xlink:href="asset/icon.svg#whatever"> because that's considered >> cross >> > > > origin. We ran into _so_ many
Re: WKWebView plugin - issues before baking it in to cordova-ios
+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 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 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 > > 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 : > > > > > > > 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 > > > 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
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 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 > 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 : > > > > > 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 > > 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 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
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 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 : > > > 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 > 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 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
We definitely have to explore this more. I doubt we can ever be perfect at the first run at it, but we've got to lay the foundation for the eventual patches. On Fri, Aug 3, 2018 at 11:30 AM Darryl Pogue wrote: > > 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 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 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 wrote: > > > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron 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 > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
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 : > 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 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 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 wrote: > > > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
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 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 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 wrote: > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
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 wrote: > > On Sun, Jul 15, 2018 at 11:39 PM Shazron 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
On Sun, Jul 15, 2018 at 11:39 PM Shazron 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
Is there a place where the most popular alternative webview engines are documented? Should we add this? Should I raise an issue on cordova-docs? On Thu, Aug 2, 2018 at 11:38 AM Jan Piotrowski wrote: > > That would be really great. Thanks! > > 2018-08-02 17:16 GMT+02:00 Shazron : > > We could -- I can just add a suffix or prefix... > > On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski wrote: > >> > >> Couldn't the class names be changed when integrating the plugin? > >> Because the console stuff is still messing with people :/ > >> > >> 2018-08-02 17:01 GMT+02:00 Shazron : > >> > yup, the class name conflict is unavoidable -- it's like when we > >> > integrated the console plugin. > >> > > >> > The bridge plugin will be able to load any webview engine plugin that > >> > has already been installed, not just the main 2. I didn't want to > >> > confuse people with too much information, since this is not an Ionic > >> > blog post. > >> > On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez > >> > wrote: > >> >> > >> >> As long as we don't break pluggable webviews, I don't think it's needed, > >> >> there are other wkwebview plugins (from telerik, oracle, etc). > >> >> > >> >> But as some (or all) of them started as forks, there will be probably > >> >> problems with duplicate class names. > >> >> > >> >> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski : > >> >> > >> >> > Many Cordova users out there are probably using > >> >> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this > >> >> > play any role in regards to the blog post? Should this maybe be > >> >> > mentioned as an anticipated question? > >> >> > > >> >> > 2018-08-02 16:31 GMT+02:00 Shazron : > >> >> > > Please review the draft of the blog post about this: > >> >> > > "The Future of the iOS WebView in Apache Cordova" > >> >> > > https://github.com/apache/cordova-docs/pull/867 > >> >> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron wrote: > >> >> > >> > >> >> > >> I've done with my review with all the issues that need to resolved > >> >> > >> with the plugin before it can be baked in to the platform for a > >> >> > >> major > >> >> > >> version release. I'm going to discuss issues with respect to > >> >> > >> migration > >> >> > >> of developers from UIWebView (features that will be lost or are > >> >> > >> different) > >> >> > >> > >> >> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has > >> >> > >> created a plugin for a workaround. See > >> >> > >> https://issues.apache.org/jira/browse/CB-12074 > >> >> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to > >> >> > >> test > >> >> > >> for the iOS 11/12. See > >> >> > >> https://issues.apache.org/jira/browse/CB-11297 > >> >> > >> 3. Can't execute JavaScript code in the background. There are > >> >> > >> several > >> >> > >> issues related to this. See > >> >> > >> https://issues.apache.org/jira/browse/CB-12815 > >> >> > >> 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 > >> >> > >> 5. Migration of localStorage from UIWebView. There is a migration > >> >> > >> plugin available. See > >> >> > >> https://issues.apache.org/jira/browse/CB-11974 > >> >> > >> > >> >> > >> Of course there are several bugs also that need to be resolved. > >> >> > >> List > >> >> > >> here: https://s.apache.org/QfsF > >> >> > >> > >> >> > >> Out of the 5 issues, 3 (external) plugins are available for the > >> >> > >> issues, 2 require minor code changes. > >> >> > >> > >> >> > >> For a solution to issue 5, I am proposing a proxy webview engine > >> >> > >> plugin that will: > >> >> > >> 1. Read a preference to use a particular webview engine > >> >> > >> 2. Proxy the selected webview engine's interface from its interface > >> >> > >> > >> >> > >> This proxy will possibly help with migration and testing, so users > >> >> > >> can > >> >> > >> "beta test" WKWebView now for existing apps (and switch back if > >> >> > >> there > >> >> > >> are problems). This is like a "feature flag" that I mentioned > >> >> > >> before, > >> >> > >> but at runtime, for users. > >> >> > >> > >> >> > >> This proxy webview engine plugin can also possibly help with > >> >> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a > >> >> > >> webview's interface). > >> >> > > > >> >> > > - > >> >> > > 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 > >> >>
Re: WKWebView plugin - issues before baking it in to cordova-ios
That would be really great. Thanks! 2018-08-02 17:16 GMT+02:00 Shazron : > We could -- I can just add a suffix or prefix... > On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski wrote: >> >> Couldn't the class names be changed when integrating the plugin? >> Because the console stuff is still messing with people :/ >> >> 2018-08-02 17:01 GMT+02:00 Shazron : >> > yup, the class name conflict is unavoidable -- it's like when we >> > integrated the console plugin. >> > >> > The bridge plugin will be able to load any webview engine plugin that >> > has already been installed, not just the main 2. I didn't want to >> > confuse people with too much information, since this is not an Ionic >> > blog post. >> > On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez >> > wrote: >> >> >> >> As long as we don't break pluggable webviews, I don't think it's needed, >> >> there are other wkwebview plugins (from telerik, oracle, etc). >> >> >> >> But as some (or all) of them started as forks, there will be probably >> >> problems with duplicate class names. >> >> >> >> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski : >> >> >> >> > Many Cordova users out there are probably using >> >> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this >> >> > play any role in regards to the blog post? Should this maybe be >> >> > mentioned as an anticipated question? >> >> > >> >> > 2018-08-02 16:31 GMT+02:00 Shazron : >> >> > > Please review the draft of the blog post about this: >> >> > > "The Future of the iOS WebView in Apache Cordova" >> >> > > https://github.com/apache/cordova-docs/pull/867 >> >> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron wrote: >> >> > >> >> >> > >> I've done with my review with all the issues that need to resolved >> >> > >> with the plugin before it can be baked in to the platform for a major >> >> > >> version release. I'm going to discuss issues with respect to >> >> > >> migration >> >> > >> of developers from UIWebView (features that will be lost or are >> >> > >> different) >> >> > >> >> >> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has >> >> > >> created a plugin for a workaround. See >> >> > >> https://issues.apache.org/jira/browse/CB-12074 >> >> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to >> >> > >> test >> >> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297 >> >> > >> 3. Can't execute JavaScript code in the background. There are several >> >> > >> issues related to this. See >> >> > >> https://issues.apache.org/jira/browse/CB-12815 >> >> > >> 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 >> >> > >> 5. Migration of localStorage from UIWebView. There is a migration >> >> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974 >> >> > >> >> >> > >> Of course there are several bugs also that need to be resolved. List >> >> > >> here: https://s.apache.org/QfsF >> >> > >> >> >> > >> Out of the 5 issues, 3 (external) plugins are available for the >> >> > >> issues, 2 require minor code changes. >> >> > >> >> >> > >> For a solution to issue 5, I am proposing a proxy webview engine >> >> > >> plugin that will: >> >> > >> 1. Read a preference to use a particular webview engine >> >> > >> 2. Proxy the selected webview engine's interface from its interface >> >> > >> >> >> > >> This proxy will possibly help with migration and testing, so users >> >> > >> can >> >> > >> "beta test" WKWebView now for existing apps (and switch back if there >> >> > >> are problems). This is like a "feature flag" that I mentioned before, >> >> > >> but at runtime, for users. >> >> > >> >> >> > >> This proxy webview engine plugin can also possibly help with >> >> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a >> >> > >> webview's interface). >> >> > > >> >> > > - >> >> > > 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 >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> > >
Re: WKWebView plugin - issues before baking it in to cordova-ios
We could -- I can just add a suffix or prefix... On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski wrote: > > Couldn't the class names be changed when integrating the plugin? > Because the console stuff is still messing with people :/ > > 2018-08-02 17:01 GMT+02:00 Shazron : > > yup, the class name conflict is unavoidable -- it's like when we > > integrated the console plugin. > > > > The bridge plugin will be able to load any webview engine plugin that > > has already been installed, not just the main 2. I didn't want to > > confuse people with too much information, since this is not an Ionic > > blog post. > > On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez > > wrote: > >> > >> As long as we don't break pluggable webviews, I don't think it's needed, > >> there are other wkwebview plugins (from telerik, oracle, etc). > >> > >> But as some (or all) of them started as forks, there will be probably > >> problems with duplicate class names. > >> > >> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski : > >> > >> > Many Cordova users out there are probably using > >> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this > >> > play any role in regards to the blog post? Should this maybe be > >> > mentioned as an anticipated question? > >> > > >> > 2018-08-02 16:31 GMT+02:00 Shazron : > >> > > Please review the draft of the blog post about this: > >> > > "The Future of the iOS WebView in Apache Cordova" > >> > > https://github.com/apache/cordova-docs/pull/867 > >> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron wrote: > >> > >> > >> > >> I've done with my review with all the issues that need to resolved > >> > >> with the plugin before it can be baked in to the platform for a major > >> > >> version release. I'm going to discuss issues with respect to migration > >> > >> of developers from UIWebView (features that will be lost or are > >> > >> different) > >> > >> > >> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has > >> > >> created a plugin for a workaround. See > >> > >> https://issues.apache.org/jira/browse/CB-12074 > >> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test > >> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297 > >> > >> 3. Can't execute JavaScript code in the background. There are several > >> > >> issues related to this. See > >> > >> https://issues.apache.org/jira/browse/CB-12815 > >> > >> 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 > >> > >> 5. Migration of localStorage from UIWebView. There is a migration > >> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974 > >> > >> > >> > >> Of course there are several bugs also that need to be resolved. List > >> > >> here: https://s.apache.org/QfsF > >> > >> > >> > >> Out of the 5 issues, 3 (external) plugins are available for the > >> > >> issues, 2 require minor code changes. > >> > >> > >> > >> For a solution to issue 5, I am proposing a proxy webview engine > >> > >> plugin that will: > >> > >> 1. Read a preference to use a particular webview engine > >> > >> 2. Proxy the selected webview engine's interface from its interface > >> > >> > >> > >> This proxy will possibly help with migration and testing, so users can > >> > >> "beta test" WKWebView now for existing apps (and switch back if there > >> > >> are problems). This is like a "feature flag" that I mentioned before, > >> > >> but at runtime, for users. > >> > >> > >> > >> This proxy webview engine plugin can also possibly help with > >> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a > >> > >> webview's interface). > >> > > > >> > > - > >> > > 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 > > > > - > 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
Couldn't the class names be changed when integrating the plugin? Because the console stuff is still messing with people :/ 2018-08-02 17:01 GMT+02:00 Shazron : > yup, the class name conflict is unavoidable -- it's like when we > integrated the console plugin. > > The bridge plugin will be able to load any webview engine plugin that > has already been installed, not just the main 2. I didn't want to > confuse people with too much information, since this is not an Ionic > blog post. > On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez > wrote: >> >> As long as we don't break pluggable webviews, I don't think it's needed, >> there are other wkwebview plugins (from telerik, oracle, etc). >> >> But as some (or all) of them started as forks, there will be probably >> problems with duplicate class names. >> >> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski : >> >> > Many Cordova users out there are probably using >> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this >> > play any role in regards to the blog post? Should this maybe be >> > mentioned as an anticipated question? >> > >> > 2018-08-02 16:31 GMT+02:00 Shazron : >> > > Please review the draft of the blog post about this: >> > > "The Future of the iOS WebView in Apache Cordova" >> > > https://github.com/apache/cordova-docs/pull/867 >> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron wrote: >> > >> >> > >> I've done with my review with all the issues that need to resolved >> > >> with the plugin before it can be baked in to the platform for a major >> > >> version release. I'm going to discuss issues with respect to migration >> > >> of developers from UIWebView (features that will be lost or are >> > >> different) >> > >> >> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has >> > >> created a plugin for a workaround. See >> > >> https://issues.apache.org/jira/browse/CB-12074 >> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test >> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297 >> > >> 3. Can't execute JavaScript code in the background. There are several >> > >> issues related to this. See >> > >> https://issues.apache.org/jira/browse/CB-12815 >> > >> 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 >> > >> 5. Migration of localStorage from UIWebView. There is a migration >> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974 >> > >> >> > >> Of course there are several bugs also that need to be resolved. List >> > >> here: https://s.apache.org/QfsF >> > >> >> > >> Out of the 5 issues, 3 (external) plugins are available for the >> > >> issues, 2 require minor code changes. >> > >> >> > >> For a solution to issue 5, I am proposing a proxy webview engine >> > >> plugin that will: >> > >> 1. Read a preference to use a particular webview engine >> > >> 2. Proxy the selected webview engine's interface from its interface >> > >> >> > >> This proxy will possibly help with migration and testing, so users can >> > >> "beta test" WKWebView now for existing apps (and switch back if there >> > >> are problems). This is like a "feature flag" that I mentioned before, >> > >> but at runtime, for users. >> > >> >> > >> This proxy webview engine plugin can also possibly help with >> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a >> > >> webview's interface). >> > > >> > > - >> > > 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 > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
yup, the class name conflict is unavoidable -- it's like when we integrated the console plugin. The bridge plugin will be able to load any webview engine plugin that has already been installed, not just the main 2. I didn't want to confuse people with too much information, since this is not an Ionic blog post. On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez wrote: > > As long as we don't break pluggable webviews, I don't think it's needed, > there are other wkwebview plugins (from telerik, oracle, etc). > > But as some (or all) of them started as forks, there will be probably > problems with duplicate class names. > > 2018-08-02 16:42 GMT+02:00 Jan Piotrowski : > > > Many Cordova users out there are probably using > > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this > > play any role in regards to the blog post? Should this maybe be > > mentioned as an anticipated question? > > > > 2018-08-02 16:31 GMT+02:00 Shazron : > > > Please review the draft of the blog post about this: > > > "The Future of the iOS WebView in Apache Cordova" > > > https://github.com/apache/cordova-docs/pull/867 > > > On Mon, Jul 16, 2018 at 2:38 PM Shazron wrote: > > >> > > >> I've done with my review with all the issues that need to resolved > > >> with the plugin before it can be baked in to the platform for a major > > >> version release. I'm going to discuss issues with respect to migration > > >> of developers from UIWebView (features that will be lost or are > > >> different) > > >> > > >> 1. Cookies don't persist. This is a WebKit bug, but someone has > > >> created a plugin for a workaround. See > > >> https://issues.apache.org/jira/browse/CB-12074 > > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test > > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297 > > >> 3. Can't execute JavaScript code in the background. There are several > > >> issues related to this. See > > >> https://issues.apache.org/jira/browse/CB-12815 > > >> 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 > > >> 5. Migration of localStorage from UIWebView. There is a migration > > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974 > > >> > > >> Of course there are several bugs also that need to be resolved. List > > >> here: https://s.apache.org/QfsF > > >> > > >> Out of the 5 issues, 3 (external) plugins are available for the > > >> issues, 2 require minor code changes. > > >> > > >> For a solution to issue 5, I am proposing a proxy webview engine > > >> plugin that will: > > >> 1. Read a preference to use a particular webview engine > > >> 2. Proxy the selected webview engine's interface from its interface > > >> > > >> This proxy will possibly help with migration and testing, so users can > > >> "beta test" WKWebView now for existing apps (and switch back if there > > >> are problems). This is like a "feature flag" that I mentioned before, > > >> but at runtime, for users. > > >> > > >> This proxy webview engine plugin can also possibly help with > > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a > > >> webview's interface). > > > > > > - > > > 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
As long as we don't break pluggable webviews, I don't think it's needed, there are other wkwebview plugins (from telerik, oracle, etc). But as some (or all) of them started as forks, there will be probably problems with duplicate class names. 2018-08-02 16:42 GMT+02:00 Jan Piotrowski : > Many Cordova users out there are probably using > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this > play any role in regards to the blog post? Should this maybe be > mentioned as an anticipated question? > > 2018-08-02 16:31 GMT+02:00 Shazron : > > Please review the draft of the blog post about this: > > "The Future of the iOS WebView in Apache Cordova" > > https://github.com/apache/cordova-docs/pull/867 > > On Mon, Jul 16, 2018 at 2:38 PM Shazron wrote: > >> > >> I've done with my review with all the issues that need to resolved > >> with the plugin before it can be baked in to the platform for a major > >> version release. I'm going to discuss issues with respect to migration > >> of developers from UIWebView (features that will be lost or are > >> different) > >> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has > >> created a plugin for a workaround. See > >> https://issues.apache.org/jira/browse/CB-12074 > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297 > >> 3. Can't execute JavaScript code in the background. There are several > >> issues related to this. See > >> https://issues.apache.org/jira/browse/CB-12815 > >> 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 > >> 5. Migration of localStorage from UIWebView. There is a migration > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974 > >> > >> Of course there are several bugs also that need to be resolved. List > >> here: https://s.apache.org/QfsF > >> > >> Out of the 5 issues, 3 (external) plugins are available for the > >> issues, 2 require minor code changes. > >> > >> For a solution to issue 5, I am proposing a proxy webview engine > >> plugin that will: > >> 1. Read a preference to use a particular webview engine > >> 2. Proxy the selected webview engine's interface from its interface > >> > >> This proxy will possibly help with migration and testing, so users can > >> "beta test" WKWebView now for existing apps (and switch back if there > >> are problems). This is like a "feature flag" that I mentioned before, > >> but at runtime, for users. > >> > >> This proxy webview engine plugin can also possibly help with > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a > >> webview's interface). > > > > - > > 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 > >
Re: WKWebView plugin - issues before baking it in to cordova-ios
Many Cordova users out there are probably using https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this play any role in regards to the blog post? Should this maybe be mentioned as an anticipated question? 2018-08-02 16:31 GMT+02:00 Shazron : > Please review the draft of the blog post about this: > "The Future of the iOS WebView in Apache Cordova" > https://github.com/apache/cordova-docs/pull/867 > On Mon, Jul 16, 2018 at 2:38 PM Shazron wrote: >> >> I've done with my review with all the issues that need to resolved >> with the plugin before it can be baked in to the platform for a major >> version release. I'm going to discuss issues with respect to migration >> of developers from UIWebView (features that will be lost or are >> different) >> >> 1. Cookies don't persist. This is a WebKit bug, but someone has >> created a plugin for a workaround. See >> https://issues.apache.org/jira/browse/CB-12074 >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297 >> 3. Can't execute JavaScript code in the background. There are several >> issues related to this. See >> https://issues.apache.org/jira/browse/CB-12815 >> 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 >> 5. Migration of localStorage from UIWebView. There is a migration >> plugin available. See https://issues.apache.org/jira/browse/CB-11974 >> >> Of course there are several bugs also that need to be resolved. List >> here: https://s.apache.org/QfsF >> >> Out of the 5 issues, 3 (external) plugins are available for the >> issues, 2 require minor code changes. >> >> For a solution to issue 5, I am proposing a proxy webview engine >> plugin that will: >> 1. Read a preference to use a particular webview engine >> 2. Proxy the selected webview engine's interface from its interface >> >> This proxy will possibly help with migration and testing, so users can >> "beta test" WKWebView now for existing apps (and switch back if there >> are problems). This is like a "feature flag" that I mentioned before, >> but at runtime, for users. >> >> This proxy webview engine plugin can also possibly help with >> InAppBrowser, I'm not sure (since that plugin has more hooks into a >> webview's interface). > > - > 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
Re: WKWebView plugin - issues before baking it in to cordova-ios
Please review the draft of the blog post about this: "The Future of the iOS WebView in Apache Cordova" https://github.com/apache/cordova-docs/pull/867 On Mon, Jul 16, 2018 at 2:38 PM Shazron wrote: > > I've done with my review with all the issues that need to resolved > with the plugin before it can be baked in to the platform for a major > version release. I'm going to discuss issues with respect to migration > of developers from UIWebView (features that will be lost or are > different) > > 1. Cookies don't persist. This is a WebKit bug, but someone has > created a plugin for a workaround. See > https://issues.apache.org/jira/browse/CB-12074 > 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test > for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297 > 3. Can't execute JavaScript code in the background. There are several > issues related to this. See > https://issues.apache.org/jira/browse/CB-12815 > 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 > 5. Migration of localStorage from UIWebView. There is a migration > plugin available. See https://issues.apache.org/jira/browse/CB-11974 > > Of course there are several bugs also that need to be resolved. List > here: https://s.apache.org/QfsF > > Out of the 5 issues, 3 (external) plugins are available for the > issues, 2 require minor code changes. > > For a solution to issue 5, I am proposing a proxy webview engine > plugin that will: > 1. Read a preference to use a particular webview engine > 2. Proxy the selected webview engine's interface from its interface > > This proxy will possibly help with migration and testing, so users can > "beta test" WKWebView now for existing apps (and switch back if there > are problems). This is like a "feature flag" that I mentioned before, > but at runtime, for users. > > This proxy webview engine plugin can also possibly help with > InAppBrowser, I'm not sure (since that plugin has more hooks into a > webview's interface). - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
WKWebView plugin - issues before baking it in to cordova-ios
I've done with my review with all the issues that need to resolved with the plugin before it can be baked in to the platform for a major version release. I'm going to discuss issues with respect to migration of developers from UIWebView (features that will be lost or are different) 1. Cookies don't persist. This is a WebKit bug, but someone has created a plugin for a workaround. See https://issues.apache.org/jira/browse/CB-12074 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297 3. Can't execute JavaScript code in the background. There are several issues related to this. See https://issues.apache.org/jira/browse/CB-12815 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 5. Migration of localStorage from UIWebView. There is a migration plugin available. See https://issues.apache.org/jira/browse/CB-11974 Of course there are several bugs also that need to be resolved. List here: https://s.apache.org/QfsF Out of the 5 issues, 3 (external) plugins are available for the issues, 2 require minor code changes. For a solution to issue 5, I am proposing a proxy webview engine plugin that will: 1. Read a preference to use a particular webview engine 2. Proxy the selected webview engine's interface from its interface This proxy will possibly help with migration and testing, so users can "beta test" WKWebView now for existing apps (and switch back if there are problems). This is like a "feature flag" that I mentioned before, but at runtime, for users. This proxy webview engine plugin can also possibly help with InAppBrowser, I'm not sure (since that plugin has more hooks into a webview's interface). - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org