You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2018/07/16 06:38:25 UTC
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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Chris Brody <ch...@gmail.com>.
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 <pi...@gmail.com> wrote:
>
> That would be really great. Thanks!
>
> 2018-08-02 17:16 GMT+02:00 Shazron <sh...@gmail.com>:
> > We could -- I can just add a suffix or prefix...
> > On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski <pi...@gmail.com> 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 <sh...@gmail.com>:
> >> > 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
> >> > <jc...@gmail.com> 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 <pi...@gmail.com>:
> >> >>
> >> >> > 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 <sh...@gmail.com>:
> >> >> > > 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 <sh...@gmail.com> 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-unsubscribe@cordova.apache.org
> >> >> > > For additional commands, e-mail: dev-help@cordova.apache.org
> >> >> > >
> >> >> >
> >> >> > ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >> > For additional commands, e-mail: dev-help@cordova.apache.org
> >> >> >
> >> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> > For additional commands, e-mail: dev-help@cordova.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Jan Piotrowski <pi...@gmail.com>.
That would be really great. Thanks!
2018-08-02 17:16 GMT+02:00 Shazron <sh...@gmail.com>:
> We could -- I can just add a suffix or prefix...
> On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski <pi...@gmail.com> 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 <sh...@gmail.com>:
>> > 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
>> > <jc...@gmail.com> 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 <pi...@gmail.com>:
>> >>
>> >> > 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 <sh...@gmail.com>:
>> >> > > 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 <sh...@gmail.com> 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-unsubscribe@cordova.apache.org
>> >> > > For additional commands, e-mail: dev-help@cordova.apache.org
>> >> > >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >> >
>> >> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Shazron <sh...@gmail.com>.
We could -- I can just add a suffix or prefix...
On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski <pi...@gmail.com> 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 <sh...@gmail.com>:
> > 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
> > <jc...@gmail.com> 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 <pi...@gmail.com>:
> >>
> >> > 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 <sh...@gmail.com>:
> >> > > 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 <sh...@gmail.com> 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-unsubscribe@cordova.apache.org
> >> > > For additional commands, e-mail: dev-help@cordova.apache.org
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> > For additional commands, e-mail: dev-help@cordova.apache.org
> >> >
> >> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Jan Piotrowski <pi...@gmail.com>.
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 <sh...@gmail.com>:
> 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
> <jc...@gmail.com> 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 <pi...@gmail.com>:
>>
>> > 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 <sh...@gmail.com>:
>> > > 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 <sh...@gmail.com> 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-unsubscribe@cordova.apache.org
>> > > For additional commands, e-mail: dev-help@cordova.apache.org
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Shazron <sh...@gmail.com>.
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
<jc...@gmail.com> 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 <pi...@gmail.com>:
>
> > 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 <sh...@gmail.com>:
> > > 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 <sh...@gmail.com> 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-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by julio cesar sanchez <jc...@gmail.com>.
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 <pi...@gmail.com>:
> 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 <sh...@gmail.com>:
> > 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 <sh...@gmail.com> 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-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Jan Piotrowski <pi...@gmail.com>.
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 <sh...@gmail.com>:
> 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 <sh...@gmail.com> 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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Shazron <sh...@gmail.com>.
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 <sh...@gmail.com> 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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Shazron <sh...@gmail.com>.
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 <sh...@gmail.com> wrote:
>
> Julio,
> Darryl mentioned " iframes being cross origin (so no accessing the
> parent/child document)" which means that it is a break from existing
> UIWebView behaviour that users expect, that will now break. There are
> workarounds: https://medium.com/@DrawandCode/how-to-communicate-with-iframes-inside-webview-2c9c86436edb
> but this is not very cross-platform, nor something we want to
> encourage further. Like Jesse said, it happens to work with UIWebView
> -- not something we actively support.
>
> There is a software philosophy (probably some Microsoft camp) that
> says you shouldn't break users when you upgrade -- if users rely on a
> 'bug' for so long (in this case no CORS), it has now become a feature
> -- but that is if you control the platform. We however don't have
> control over WKWebView, so its not up to us. That is why I am
> reluctant to bake in features that workaround some of these security
> controls, and instead rely on external plugins (my personal opinion).
> It should be an active decision from the developer to override the
> controls of WKWebView if they so choose, and we will help with
> information on how to do so as a stopgap, not as the ultimate
> solution.
> On Wed, Aug 8, 2018 at 10:47 PM julio cesar sanchez
> <jc...@gmail.com> wrote:
> >
> > What's exactly the iframe problem?
> >
> > El mié., 8 ago. 2018 a las 10:05, Niklas Merz (<ni...@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 <pu...@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 <sh...@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 <sh...@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
> > > >> > <fr...@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 <dv...@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 <sh...@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
> > > ><dv...@gmail.com>
> > > >> wrote:
> > > >> > > > > >
> > > >> > > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron
> > > ><sh...@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-unsubscribe@cordova.apache.org
> > > >> > > > > > For additional commands, e-mail:
> > > >dev-help@cordova.apache.org
> > > >> > > > > >
> > > >> > > > >
> > > >> > > > > ------------------------------------------------------------
> > > >> ---------
> > > >> > > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > >> > > > >
> > > >> > > >
> > > >> > > > ------------------------------------------------------------
> > > >> ---------
> > > >> > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> > > > For additional commands, e-mail: dev-help@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-unsubscribe@cordova.apache.org
> > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > >>
> > > >>
> > >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Shazron <sh...@gmail.com>.
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
<jc...@gmail.com> wrote:
>
> What's exactly the iframe problem?
>
> El mié., 8 ago. 2018 a las 10:05, Niklas Merz (<ni...@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 <pu...@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 <sh...@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 <sh...@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
> > >> > <fr...@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 <dv...@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 <sh...@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
> > ><dv...@gmail.com>
> > >> wrote:
> > >> > > > > >
> > >> > > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron
> > ><sh...@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-unsubscribe@cordova.apache.org
> > >> > > > > > For additional commands, e-mail:
> > >dev-help@cordova.apache.org
> > >> > > > > >
> > >> > > > >
> > >> > > > > ------------------------------------------------------------
> > >> ---------
> > >> > > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >> > > > >
> > >> > > >
> > >> > > > ------------------------------------------------------------
> > >> ---------
> > >> > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > > > For additional commands, e-mail: dev-help@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-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by julio cesar sanchez <jc...@gmail.com>.
What's exactly the iframe problem?
El mié., 8 ago. 2018 a las 10:05, Niklas Merz (<ni...@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 <pu...@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 <sh...@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 <sh...@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
> >> > <fr...@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 <dv...@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 <sh...@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
> ><dv...@gmail.com>
> >> wrote:
> >> > > > > >
> >> > > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron
> ><sh...@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-unsubscribe@cordova.apache.org
> >> > > > > > For additional commands, e-mail:
> >dev-help@cordova.apache.org
> >> > > > > >
> >> > > > >
> >> > > > > ------------------------------------------------------------
> >> ---------
> >> > > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> >> > > > >
> >> > > >
> >> > > > ------------------------------------------------------------
> >> ---------
> >> > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> > > > For additional commands, e-mail: dev-help@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-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Niklas Merz <ni...@rhoen.de>.
+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 <pu...@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 <sh...@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 <sh...@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
>> > <fr...@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 <dv...@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 <sh...@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
><dv...@gmail.com>
>> wrote:
>> > > > > >
>> > > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron
><sh...@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-unsubscribe@cordova.apache.org
>> > > > > > For additional commands, e-mail:
>dev-help@cordova.apache.org
>> > > > > >
>> > > > >
>> > > > > ------------------------------------------------------------
>> ---------
>> > > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
>> > > > >
>> > > >
>> > > > ------------------------------------------------------------
>> ---------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > > > For additional commands, e-mail: dev-help@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-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Jesse <pu...@gmail.com>.
+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 <sh...@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 <sh...@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
> > <fr...@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 <dv...@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 <sh...@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 <dv...@gmail.com>
> wrote:
> > > > > >
> > > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron <sh...@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-unsubscribe@cordova.apache.org
> > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >
> > > > >
> > > > > ------------------------------------------------------------
> ---------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > For additional commands, e-mail: dev-help@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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Shazron <sh...@gmail.com>.
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 <sh...@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
> <fr...@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 <dv...@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 <sh...@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 <dv...@gmail.com> wrote:
> > > > >
> > > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron <sh...@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-unsubscribe@cordova.apache.org
> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Shazron <sh...@gmail.com>.
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
<fr...@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 <dv...@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 <sh...@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 <dv...@gmail.com> wrote:
> > > >
> > > > On Sun, Jul 15, 2018 at 11:39 PM Shazron <sh...@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-unsubscribe@cordova.apache.org
> > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Frederico Galvão <fr...@pontoget.com.br>.
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 <dv...@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 <sh...@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 <dv...@gmail.com> wrote:
> > >
> > > On Sun, Jul 15, 2018 at 11:39 PM Shazron <sh...@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-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@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/>
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Shazron <sh...@gmail.com>.
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 <dv...@gmail.com> 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 <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 <sh...@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 <dv...@gmail.com> wrote:
> > >
> > > On Sun, Jul 15, 2018 at 11:39 PM Shazron <sh...@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-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Darryl Pogue <dv...@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 <sh...@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 <dv...@gmail.com> wrote:
> >
> > On Sun, Jul 15, 2018 at 11:39 PM Shazron <sh...@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-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Shazron <sh...@gmail.com>.
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 <dv...@gmail.com> wrote:
>
> On Sun, Jul 15, 2018 at 11:39 PM Shazron <sh...@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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: WKWebView plugin - issues before baking it in to cordova-ios
Posted by Darryl Pogue <dv...@gmail.com>.
On Sun, Jul 15, 2018 at 11:39 PM Shazron <sh...@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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org