Re: WKWebView plugin - issues before baking it in to cordova-ios

[Darryl Pogue]

One concern with the Oracle plugin is that it's only patching the
obvious cases of XHR and fetch, but doesn't handle things like iframes
being cross origin (so no accessing the parent/child document) or
local image assets being cross origin when drawn to canvas (thus
tainting the canvas and making it impossible to read pixel data from
it). SVG icons aren't allowed to load when using  because that's considered cross
origin. We ran into _so_ many weird cases caused by cross origin
issues when we upgraded our app to WKWebView.

I haven't had a chance to dig into the custom scheme stuff, but my
understanding is that everything would use the custom scheme instead
of file:/// and cordova-ios would have a scheme handler that would map
those to filesystem files, read those files with native code, and
return the data as a response. Similar in some ways to NSURLProtocol,
but asynchronous and with limited access to form data.

On Thu, Aug 2, 2018 at 7:44 PM Shazron  wrote:
>
> Our policy has been we support the currently shipping iOS version,
> plus one back. This is because of device version testing complexities.
> It may work on older iOS versions if we code it with the right
> safeguards, but that is not guaranteed. When iOS 12 ships this fall,
> we would drop iOS 10 support (support as in testing for it, like I
> said it might still work).
>
> We could do the custom scheme -- or just use the Oracle plugin since
> that bridges it to using NSURLConnection, which has no restrictions.
> This will work on any iOS version. I would opt for the easiest
> solution *for now* to get something out.
>
> Using cdvapp://index.html, will all future file:// references in that
> index.html file work, or still have the same restrictions? I'll have
> to do some tests (unless you know already?)
>
> Regarding the fallback, the point of this bridge plugin is that the
> switching is an active decision by the developer (a hard break) and is
> to aid in migrating completely to WKWebView. If we had an automatic
> fallback, it might be a crutch until its too late and UIWebView is
> gone and they are surprised since it was all working "behind the
> scenes".
>
> On Fri, Aug 3, 2018 at 1:22 AM Darryl Pogue  wrote:
> >
> > On Sun, Jul 15, 2018 at 11:39 PM Shazron  wrote:
> > >
> > > 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> > > Sharing issue (CORS). There is a workaround plugin created by Oracle
> > > (UPL licensed, which is Apache-2.0 compatible). See
> > > https://issues.apache.org/jira/browse/CB-10143
> >
> > This happens because we're using file:/// URLs, which are subject to
> > additional security restrictions in WKWebView. Every file is treated
> > as its own origin, so a page can't make an XHR request to something
> > like file:///etc/passwd, but that same feature also means it can't
> > make an XHR request to ./assets/whatever.js
> >
> > The encouraged solution to this is to implement a custom scheme using
> > WKURLSchemeHandler and handle serving the files from the filesystem
> > yourself. This means the entire app would be served from something
> > like cdvapp://index.html rather than a file:/// URL.
> > Unfortunately, that API was only added in iOS 11, and Cordova
> > currently supports as far back as iOS 9, and the next major will
> > probably still want to support iOS 10?
> >
> > If we have the ability to swap the webview at runtime, it might be
> > worth investigating whether it makes sense to add a custom scheme for
> > iOS 11+ and WKWebView, and provide a way to fallback to UIWebView for
> > iOS 10?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Nightly build #808 for cordova has failed

[Apache Jenkins Server]

Nightly build #808 for cordova has failed.

Please check failure details on build details page at 
https://builds.apache.org/job/cordova-nightly/808/
You can also take a look at build console: 
https://builds.apache.org/job/cordova-nightly/808/consoleFull

-
Jenkins for Apache Cordova

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

Our policy has been we support the currently shipping iOS version,
plus one back. This is because of device version testing complexities.
It may work on older iOS versions if we code it with the right
safeguards, but that is not guaranteed. When iOS 12 ships this fall,
we would drop iOS 10 support (support as in testing for it, like I
said it might still work).

We could do the custom scheme -- or just use the Oracle plugin since
that bridges it to using NSURLConnection, which has no restrictions.
This will work on any iOS version. I would opt for the easiest
solution *for now* to get something out.

Using cdvapp://index.html, will all future file:// references in that
index.html file work, or still have the same restrictions? I'll have
to do some tests (unless you know already?)

Regarding the fallback, the point of this bridge plugin is that the
switching is an active decision by the developer (a hard break) and is
to aid in migrating completely to WKWebView. If we had an automatic
fallback, it might be a crutch until its too late and UIWebView is
gone and they are surprised since it was all working "behind the
scenes".

On Fri, Aug 3, 2018 at 1:22 AM Darryl Pogue  wrote:
>
> On Sun, Jul 15, 2018 at 11:39 PM Shazron  wrote:
> >
> > 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> > Sharing issue (CORS). There is a workaround plugin created by Oracle
> > (UPL licensed, which is Apache-2.0 compatible). See
> > https://issues.apache.org/jira/browse/CB-10143
>
> This happens because we're using file:/// URLs, which are subject to
> additional security restrictions in WKWebView. Every file is treated
> as its own origin, so a page can't make an XHR request to something
> like file:///etc/passwd, but that same feature also means it can't
> make an XHR request to ./assets/whatever.js
>
> The encouraged solution to this is to implement a custom scheme using
> WKURLSchemeHandler and handle serving the files from the filesystem
> yourself. This means the entire app would be served from something
> like cdvapp://index.html rather than a file:/// URL.
> Unfortunately, that API was only added in iOS 11, and Cordova
> currently supports as far back as iOS 9, and the next major will
> probably still want to support iOS 10?
>
> If we have the ability to swap the webview at runtime, it might be
> worth investigating whether it makes sense to add a custom scheme for
> iOS 11+ and WKWebView, and provide a way to fallback to UIWebView for
> iOS 10?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Darryl Pogue]

On Sun, Jul 15, 2018 at 11:39 PM Shazron  wrote:
>
> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> Sharing issue (CORS). There is a workaround plugin created by Oracle
> (UPL licensed, which is Apache-2.0 compatible). See
> https://issues.apache.org/jira/browse/CB-10143

This happens because we're using file:/// URLs, which are subject to
additional security restrictions in WKWebView. Every file is treated
as its own origin, so a page can't make an XHR request to something
like file:///etc/passwd, but that same feature also means it can't
make an XHR request to ./assets/whatever.js

The encouraged solution to this is to implement a custom scheme using
WKURLSchemeHandler and handle serving the files from the filesystem
yourself. This means the entire app would be served from something
like cdvapp://index.html rather than a file:/// URL.
Unfortunately, that API was only added in iOS 11, and Cordova
currently supports as far back as iOS 9, and the next major will
probably still want to support iOS 10?

If we have the ability to swap the webview at runtime, it might be
worth investigating whether it makes sense to add a custom scheme for
iOS 11+ and WKWebView, and provide a way to fallback to UIWebView for
iOS 10?

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Chris Brody]

Is there a place where the most popular alternative webview engines
are documented?

Should we add this?

Should I raise an issue on cordova-docs?
On Thu, Aug 2, 2018 at 11:38 AM Jan Piotrowski  wrote:
>
> That would be really great. Thanks!
>
> 2018-08-02 17:16 GMT+02:00 Shazron :
> > We could -- I can just add a suffix or prefix...
> > On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski  wrote:
> >>
> >> Couldn't the class names be changed when integrating the plugin?
> >> Because the console stuff is still messing with people :/
> >>
> >> 2018-08-02 17:01 GMT+02:00 Shazron :
> >> > yup, the class name conflict is unavoidable -- it's like when we
> >> > integrated the console plugin.
> >> >
> >> > The bridge plugin will be able to load any webview engine plugin that
> >> > has already been installed, not just the main 2. I didn't want to
> >> > confuse people with too much information, since this is not an Ionic
> >> > blog post.
> >> > On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez
> >> >  wrote:
> >> >>
> >> >> As long as we don't break pluggable webviews, I don't think it's needed,
> >> >> there are other wkwebview plugins (from telerik, oracle, etc).
> >> >>
> >> >> But as some (or all) of them started as forks, there will be probably
> >> >> problems with duplicate class names.
> >> >>
> >> >> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski :
> >> >>
> >> >> > Many Cordova users out there are probably using
> >> >> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
> >> >> > play any role in regards to the blog post? Should this maybe be
> >> >> > mentioned as an anticipated question?
> >> >> >
> >> >> > 2018-08-02 16:31 GMT+02:00 Shazron :
> >> >> > > Please review the draft of the blog post about this:
> >> >> > > "The Future of the iOS WebView in Apache Cordova"
> >> >> > > https://github.com/apache/cordova-docs/pull/867
> >> >> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
> >> >> > >>
> >> >> > >> I've done with my review with all the issues that need to resolved
> >> >> > >> with the plugin before it can be baked in to the platform for a 
> >> >> > >> major
> >> >> > >> version release. I'm going to discuss issues with respect to 
> >> >> > >> migration
> >> >> > >> of developers from UIWebView (features that will be lost or are
> >> >> > >> different)
> >> >> > >>
> >> >> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has
> >> >> > >> created a plugin for a workaround. See
> >> >> > >> https://issues.apache.org/jira/browse/CB-12074
> >> >> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to 
> >> >> > >> test
> >> >> > >> for the iOS 11/12. See 
> >> >> > >> https://issues.apache.org/jira/browse/CB-11297
> >> >> > >> 3. Can't execute JavaScript code in the background. There are 
> >> >> > >> several
> >> >> > >> issues related to this. See
> >> >> > >> https://issues.apache.org/jira/browse/CB-12815
> >> >> > >> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> >> >> > >> Sharing issue (CORS). There is a workaround plugin created by 
> >> >> > >> Oracle
> >> >> > >> (UPL licensed, which is Apache-2.0 compatible). See
> >> >> > >> https://issues.apache.org/jira/browse/CB-10143
> >> >> > >> 5. Migration of localStorage from UIWebView. There is a migration
> >> >> > >> plugin available. See 
> >> >> > >> https://issues.apache.org/jira/browse/CB-11974
> >> >> > >>
> >> >> > >> Of course there are several bugs also that need to be resolved. 
> >> >> > >> List
> >> >> > >> here: https://s.apache.org/QfsF
> >> >> > >>
> >> >> > >> Out of the 5 issues, 3 (external) plugins are available for the
> >> >> > >> issues, 2 require minor code changes.
> >> >> > >>
> >> >> > >> For a solution to issue 5, I am proposing a proxy webview engine
> >> >> > >> plugin that will:
> >> >> > >> 1. Read a preference to use a particular webview engine
> >> >> > >> 2. Proxy the selected webview engine's interface from its interface
> >> >> > >>
> >> >> > >> This proxy will possibly help with migration and testing, so users 
> >> >> > >> can
> >> >> > >> "beta test" WKWebView now for existing apps (and switch back if 
> >> >> > >> there
> >> >> > >> are problems). This is like a "feature flag" that I mentioned 
> >> >> > >> before,
> >> >> > >> but at runtime, for users.
> >> >> > >>
> >> >> > >> This proxy webview engine plugin can also possibly help with
> >> >> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a
> >> >> > >> webview's interface).
> >> >> > >
> >> >> > > -
> >> >> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> >> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> >> >> > >
> >> >> >
> >> >> > -
> >> >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> >> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >> >> 

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Jan Piotrowski]

That would be really great. Thanks!

2018-08-02 17:16 GMT+02:00 Shazron :
> We could -- I can just add a suffix or prefix...
> On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski  wrote:
>>
>> Couldn't the class names be changed when integrating the plugin?
>> Because the console stuff is still messing with people :/
>>
>> 2018-08-02 17:01 GMT+02:00 Shazron :
>> > yup, the class name conflict is unavoidable -- it's like when we
>> > integrated the console plugin.
>> >
>> > The bridge plugin will be able to load any webview engine plugin that
>> > has already been installed, not just the main 2. I didn't want to
>> > confuse people with too much information, since this is not an Ionic
>> > blog post.
>> > On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez
>> >  wrote:
>> >>
>> >> As long as we don't break pluggable webviews, I don't think it's needed,
>> >> there are other wkwebview plugins (from telerik, oracle, etc).
>> >>
>> >> But as some (or all) of them started as forks, there will be probably
>> >> problems with duplicate class names.
>> >>
>> >> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski :
>> >>
>> >> > Many Cordova users out there are probably using
>> >> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
>> >> > play any role in regards to the blog post? Should this maybe be
>> >> > mentioned as an anticipated question?
>> >> >
>> >> > 2018-08-02 16:31 GMT+02:00 Shazron :
>> >> > > Please review the draft of the blog post about this:
>> >> > > "The Future of the iOS WebView in Apache Cordova"
>> >> > > https://github.com/apache/cordova-docs/pull/867
>> >> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
>> >> > >>
>> >> > >> I've done with my review with all the issues that need to resolved
>> >> > >> with the plugin before it can be baked in to the platform for a major
>> >> > >> version release. I'm going to discuss issues with respect to 
>> >> > >> migration
>> >> > >> of developers from UIWebView (features that will be lost or are
>> >> > >> different)
>> >> > >>
>> >> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has
>> >> > >> created a plugin for a workaround. See
>> >> > >> https://issues.apache.org/jira/browse/CB-12074
>> >> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to 
>> >> > >> test
>> >> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
>> >> > >> 3. Can't execute JavaScript code in the background. There are several
>> >> > >> issues related to this. See
>> >> > >> https://issues.apache.org/jira/browse/CB-12815
>> >> > >> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
>> >> > >> Sharing issue (CORS). There is a workaround plugin created by Oracle
>> >> > >> (UPL licensed, which is Apache-2.0 compatible). See
>> >> > >> https://issues.apache.org/jira/browse/CB-10143
>> >> > >> 5. Migration of localStorage from UIWebView. There is a migration
>> >> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974
>> >> > >>
>> >> > >> Of course there are several bugs also that need to be resolved. List
>> >> > >> here: https://s.apache.org/QfsF
>> >> > >>
>> >> > >> Out of the 5 issues, 3 (external) plugins are available for the
>> >> > >> issues, 2 require minor code changes.
>> >> > >>
>> >> > >> For a solution to issue 5, I am proposing a proxy webview engine
>> >> > >> plugin that will:
>> >> > >> 1. Read a preference to use a particular webview engine
>> >> > >> 2. Proxy the selected webview engine's interface from its interface
>> >> > >>
>> >> > >> This proxy will possibly help with migration and testing, so users 
>> >> > >> can
>> >> > >> "beta test" WKWebView now for existing apps (and switch back if there
>> >> > >> are problems). This is like a "feature flag" that I mentioned before,
>> >> > >> but at runtime, for users.
>> >> > >>
>> >> > >> This proxy webview engine plugin can also possibly help with
>> >> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a
>> >> > >> webview's interface).
>> >> > >
>> >> > > -
>> >> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> >> > > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >> > >
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> >> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >> >
>> >> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> 

Re: ios-deploy questions

[Chris Brody]

Thanks Shazron, makes absolute sense. I would personally not favor
viral license in the dependencies, even if not bundled.
On Thu, Aug 2, 2018 at 11:16 AM Shazron  wrote:
>
> 1. Previously we had node_modules bundled. We couldn't bundle
> ios-deploy because of its viral license. The only issue is that it
> tries to build on Windows, but that should be easily fixed:
> https://github.com/ios-control/ios-deploy/issues/355 . There should be
> no problem in using a dependency from the command line, we just have
> to prepend the path from `npm bin` to the PATH variable, then run the
> executable (just have to exclude Windows from this case).
> 2. The risk mismatch is only based off the Xcode version installed
> since it is built natively and relies on Xcode frameworks (Xcode 9.4
> was missing files and ios-deploy had to work around it). We don't
> really have a matrix of dependencies, so the latest is always used for
> ios-deploy.
>
> Technically we don't even have to install anything now, if we prefix
> the npm command with `npx`:
> `npx ios-deploy a b c`
>
> npx has been available since npm@5.2.0
> According to this: https://nodejs.org/en/download/releases/ it would
> mean that we can only rely on npx being installed if the user has node
> 8.2.0, which is a ways off from being our default node version.
>
> On Thu, Aug 2, 2018 at 10:41 PM Jan Piotrowski  wrote:
> >
> > > 1. Why not make ios-deploy a dependency of cordova-ios that would then
> > > be automatically installed?
> >
> > Historically, I think, commands that should be able to be called via
> > the command line had to be installed globally with npm to work. Is
> > this not the case any more?
> >
> > 2018-08-02 15:26 GMT+02:00 Chris Brody :
> > > A couple things that I think are not clear for
> > > :
> > >
> > > 1. Why not make ios-deploy a dependency of cordova-ios that would then
> > > be automatically installed?
> > >
> > > 2. Is there a risk of mismatch between a users installed ios-deploy
> > > version and a users Cordova version? Should this be documented, if so?
> > >
> > > I think the answer to 1 is that ios-deploy sometimes needs to be
> > > installed with more system privs. I am not 100% sure of this, would
> > > love some confirmation from an expert. And I think this is not really
> > > a problem most of the time.
> > >
> > > I think the answer to 2 is "not yet".
> > >
> > > Confirmation would be really helpful.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[raphinesse]

>
> For Cordova tooling I expect no one outside of the developers to
>
really know what happens where - but if I see it correctly we almost
> don't have any tooling JIRA issues as well, right?
>
There's plenty tooling related JIRA issues. And rightly so.

IMHO, joining all tooling packages in a mono-repo might be beneficial for
this and other problems. But that is something for another day.

That is indeed a problem that Github hasn't solved yet (afaik). One
> can of course create individual issues, then mention the parent issue
> there to create an automatic link between the issues.
>
> > (Can we
> > productively use whatever tools GitHub provides here, or will we have to
> > get permission from INFRA for every little thing we do?)
>
> Which tools do you refer to? External Kanban tool or something similar?
> In general we are just Members of the Github repos and don't have any
> power to change settings etc - Admin is only Apache, which means
> INFRA.
>
I was thinking of "Projects". I saw them on the team level. Don't really
know what they do though.
But basically I was speaking hypothetically. Hoping someone with experience
of that kind of GitHub usage would chime in.

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

We could -- I can just add a suffix or prefix...
On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski  wrote:
>
> Couldn't the class names be changed when integrating the plugin?
> Because the console stuff is still messing with people :/
>
> 2018-08-02 17:01 GMT+02:00 Shazron :
> > yup, the class name conflict is unavoidable -- it's like when we
> > integrated the console plugin.
> >
> > The bridge plugin will be able to load any webview engine plugin that
> > has already been installed, not just the main 2. I didn't want to
> > confuse people with too much information, since this is not an Ionic
> > blog post.
> > On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez
> >  wrote:
> >>
> >> As long as we don't break pluggable webviews, I don't think it's needed,
> >> there are other wkwebview plugins (from telerik, oracle, etc).
> >>
> >> But as some (or all) of them started as forks, there will be probably
> >> problems with duplicate class names.
> >>
> >> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski :
> >>
> >> > Many Cordova users out there are probably using
> >> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
> >> > play any role in regards to the blog post? Should this maybe be
> >> > mentioned as an anticipated question?
> >> >
> >> > 2018-08-02 16:31 GMT+02:00 Shazron :
> >> > > Please review the draft of the blog post about this:
> >> > > "The Future of the iOS WebView in Apache Cordova"
> >> > > https://github.com/apache/cordova-docs/pull/867
> >> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
> >> > >>
> >> > >> I've done with my review with all the issues that need to resolved
> >> > >> with the plugin before it can be baked in to the platform for a major
> >> > >> version release. I'm going to discuss issues with respect to migration
> >> > >> of developers from UIWebView (features that will be lost or are
> >> > >> different)
> >> > >>
> >> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has
> >> > >> created a plugin for a workaround. See
> >> > >> https://issues.apache.org/jira/browse/CB-12074
> >> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
> >> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
> >> > >> 3. Can't execute JavaScript code in the background. There are several
> >> > >> issues related to this. See
> >> > >> https://issues.apache.org/jira/browse/CB-12815
> >> > >> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> >> > >> Sharing issue (CORS). There is a workaround plugin created by Oracle
> >> > >> (UPL licensed, which is Apache-2.0 compatible). See
> >> > >> https://issues.apache.org/jira/browse/CB-10143
> >> > >> 5. Migration of localStorage from UIWebView. There is a migration
> >> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974
> >> > >>
> >> > >> Of course there are several bugs also that need to be resolved. List
> >> > >> here: https://s.apache.org/QfsF
> >> > >>
> >> > >> Out of the 5 issues, 3 (external) plugins are available for the
> >> > >> issues, 2 require minor code changes.
> >> > >>
> >> > >> For a solution to issue 5, I am proposing a proxy webview engine
> >> > >> plugin that will:
> >> > >> 1. Read a preference to use a particular webview engine
> >> > >> 2. Proxy the selected webview engine's interface from its interface
> >> > >>
> >> > >> This proxy will possibly help with migration and testing, so users can
> >> > >> "beta test" WKWebView now for existing apps (and switch back if there
> >> > >> are problems). This is like a "feature flag" that I mentioned before,
> >> > >> but at runtime, for users.
> >> > >>
> >> > >> This proxy webview engine plugin can also possibly help with
> >> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a
> >> > >> webview's interface).
> >> > >
> >> > > -
> >> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> >> > >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >> >
> >> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: ios-deploy questions

[Shazron]

1. Previously we had node_modules bundled. We couldn't bundle
ios-deploy because of its viral license. The only issue is that it
tries to build on Windows, but that should be easily fixed:
https://github.com/ios-control/ios-deploy/issues/355 . There should be
no problem in using a dependency from the command line, we just have
to prepend the path from `npm bin` to the PATH variable, then run the
executable (just have to exclude Windows from this case).
2. The risk mismatch is only based off the Xcode version installed
since it is built natively and relies on Xcode frameworks (Xcode 9.4
was missing files and ios-deploy had to work around it). We don't
really have a matrix of dependencies, so the latest is always used for
ios-deploy.

Technically we don't even have to install anything now, if we prefix
the npm command with `npx`:
`npx ios-deploy a b c`

npx has been available since npm@5.2.0
According to this: https://nodejs.org/en/download/releases/ it would
mean that we can only rely on npx being installed if the user has node
8.2.0, which is a ways off from being our default node version.

On Thu, Aug 2, 2018 at 10:41 PM Jan Piotrowski  wrote:
>
> > 1. Why not make ios-deploy a dependency of cordova-ios that would then
> > be automatically installed?
>
> Historically, I think, commands that should be able to be called via
> the command line had to be installed globally with npm to work. Is
> this not the case any more?
>
> 2018-08-02 15:26 GMT+02:00 Chris Brody :
> > A couple things that I think are not clear for
> > :
> >
> > 1. Why not make ios-deploy a dependency of cordova-ios that would then
> > be automatically installed?
> >
> > 2. Is there a risk of mismatch between a users installed ios-deploy
> > version and a users Cordova version? Should this be documented, if so?
> >
> > I think the answer to 1 is that ios-deploy sometimes needs to be
> > installed with more system privs. I am not 100% sure of this, would
> > love some confirmation from an expert. And I think this is not really
> > a problem most of the time.
> >
> > I think the answer to 2 is "not yet".
> >
> > Confirmation would be really helpful.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Jan Piotrowski]

Couldn't the class names be changed when integrating the plugin?
Because the console stuff is still messing with people :/

2018-08-02 17:01 GMT+02:00 Shazron :
> yup, the class name conflict is unavoidable -- it's like when we
> integrated the console plugin.
>
> The bridge plugin will be able to load any webview engine plugin that
> has already been installed, not just the main 2. I didn't want to
> confuse people with too much information, since this is not an Ionic
> blog post.
> On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez
>  wrote:
>>
>> As long as we don't break pluggable webviews, I don't think it's needed,
>> there are other wkwebview plugins (from telerik, oracle, etc).
>>
>> But as some (or all) of them started as forks, there will be probably
>> problems with duplicate class names.
>>
>> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski :
>>
>> > Many Cordova users out there are probably using
>> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
>> > play any role in regards to the blog post? Should this maybe be
>> > mentioned as an anticipated question?
>> >
>> > 2018-08-02 16:31 GMT+02:00 Shazron :
>> > > Please review the draft of the blog post about this:
>> > > "The Future of the iOS WebView in Apache Cordova"
>> > > https://github.com/apache/cordova-docs/pull/867
>> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
>> > >>
>> > >> I've done with my review with all the issues that need to resolved
>> > >> with the plugin before it can be baked in to the platform for a major
>> > >> version release. I'm going to discuss issues with respect to migration
>> > >> of developers from UIWebView (features that will be lost or are
>> > >> different)
>> > >>
>> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has
>> > >> created a plugin for a workaround. See
>> > >> https://issues.apache.org/jira/browse/CB-12074
>> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
>> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
>> > >> 3. Can't execute JavaScript code in the background. There are several
>> > >> issues related to this. See
>> > >> https://issues.apache.org/jira/browse/CB-12815
>> > >> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
>> > >> Sharing issue (CORS). There is a workaround plugin created by Oracle
>> > >> (UPL licensed, which is Apache-2.0 compatible). See
>> > >> https://issues.apache.org/jira/browse/CB-10143
>> > >> 5. Migration of localStorage from UIWebView. There is a migration
>> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974
>> > >>
>> > >> Of course there are several bugs also that need to be resolved. List
>> > >> here: https://s.apache.org/QfsF
>> > >>
>> > >> Out of the 5 issues, 3 (external) plugins are available for the
>> > >> issues, 2 require minor code changes.
>> > >>
>> > >> For a solution to issue 5, I am proposing a proxy webview engine
>> > >> plugin that will:
>> > >> 1. Read a preference to use a particular webview engine
>> > >> 2. Proxy the selected webview engine's interface from its interface
>> > >>
>> > >> This proxy will possibly help with migration and testing, so users can
>> > >> "beta test" WKWebView now for existing apps (and switch back if there
>> > >> are problems). This is like a "feature flag" that I mentioned before,
>> > >> but at runtime, for users.
>> > >>
>> > >> This proxy webview engine plugin can also possibly help with
>> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a
>> > >> webview's interface).
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > > For additional commands, e-mail: dev-h...@cordova.apache.org
>> > >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

> - How do people know in which of the numerous Cordova repos to create
> their issues (especially bad for tooling)

As Julio already indicated this is a communication problem, that we
can solve by having a page at issues.cordova.io. Pages like
https://cordova.apache.org/contribute/ also have links to JIRA now,
this should then be of course adapted as well, complete with an
explanation how to find the correct issue list to create a new one.

The problem of people just _using_ the wrong place can't really be
solved, but we will have to find a way to deal with them. One option
is to use something like https://github-issue-mover.appspot.com/ to
fix what users mess up. Another way is to be very strict with closing
issues and pointing people in the right direction (which users usually
don't like at all though).

For Cordova tooling I expect no one outside of the developers to
really know what happens where - but if I see it correctly we almost
don't have any tooling JIRA issues as well, right?

> - How to manage meta-issues that concern more than one repo

That is indeed a problem that Github hasn't solved yet (afaik). One
can of course create individual issues, then mention the parent issue
there to create an automatic link between the issues.

> (Can we
> productively use whatever tools GitHub provides here, or will we have to
> get permission from INFRA for every little thing we do?)

Which tools do you refer to? External Kanban tool or something similar?
In general we are just Members of the Github repos and don't have any
power to change settings etc - Admin is only Apache, which means
INFRA.

2018-08-02 16:51 GMT+02:00  :
> There is much I don't like about JIRA and in general I prefer GitHub
> issues. However, there's issues that did came up during previous
> discussions of this topic, and that have no proper solution that I know of
>
>- How do people know in which of the numerous Cordova repos to create
>their issues (especially bad for tooling)
>- How to manage meta-issues that concern more than one repo (Can we
>productively use whatever tools GitHub provides here, or will we have to
>get permission from INFRA for every little thing we do?)
>
> I fear that if we blindly rush into this, all we will get is an even more
> fragmented landscape of issues and discussions
>
> Am Do., 2. Aug. 2018 um 16:34 Uhr schrieb Jan Piotrowski <
> piotrow...@gmail.com>:
>
>> Decision making for Apache projects is described here:
>> https://community.apache.org/committers/decisionMaking.html
>>
>> So to make it official:
>> I hereby declare that I will start implementing the stuff from my
>> initial email if nobody objects in the next 72 hours (meaning: before
>> next Monday). After that I will create the INFRA issue.
>>
>> The other, preliminary taks can already be started - I did by creating
>> 2 cordova-docs issues that I already linked. For the rest of b) I will
>> probably start another mailing list thread.
>>
>> 2018-08-02 15:35 GMT+02:00 Chris Brody :
>> > What will it take to take care of a) Enable GitHub issues on all
>> > repositories via INFRA ticket?
>> >
>> > I think this is needed really badly. There are way too many cases of
>> > questions and issues being raised in the wrong place, lost in diverse
>> > discussion forums, or not even asked at all.
>> > On Wed, Aug 1, 2018 at 9:59 AM Bryan Ellis 
>> wrote:
>> >>
>> >> +1
>> >>
>> >> Not sure if (f) was a task, as in to find a way to integrate GH and
>> Slack, but it does exist.
>> >>
>> >> https://slack.github.com/ 
>> >>
>> >> It covers a lot including new commits, pr, new issues, code reviews,
>> and more.
>> >>
>> >>
>> >> > On Aug 1, 2018, at 22:22, Jan Piotrowski 
>> wrote:
>> >> >
>> >> > Another one:
>> >> >
>> >> > f) Find and activate way for Github issue (and PR) updates to be
>> >> > posted so Slack #issues
>> >> >
>> >> > 2018-07-31 18:14 GMT+02:00 Jan Piotrowski :
>> >> >> The npm forum solves a very different problem for npm - they had too
>> >> >> much noise in Github issues because of the project's popularity. Too
>> >> >> much popularity is not one of Cordova's problems ;)
>> >> >>
>> >> >> Many uses of cordova-discuss will be able to move to the individual
>> >> >> project repositories issues, maybe we can even think about getting
>> rid
>> >> >> of it. Good thing to keep in mind after everything is migrated.
>> >> >> The mailing list can be used much more to just point people to a
>> >> >> specific issue (as I also did in my original mail here) where the
>> >> >> actual discussion will happen.
>> >> >>
>> >> >> -J
>> >> >>
>> >> >> 2018-07-31 17:39 GMT+02:00 Chris Brody :
>> >> >>> +1 (+100) for migrating away from JIRA issues
>> >> >>>
>> >> >>> npm took a different approach that I am starting to really like:
>> using
>> >> >>> npm.community (Discourse) with GitHub login for issues and
>> discussions
>> >> >>>
>> >> >>> solves another major problem since I don't like mail list for
>> >> >>> 

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

yup, the class name conflict is unavoidable -- it's like when we
integrated the console plugin.

The bridge plugin will be able to load any webview engine plugin that
has already been installed, not just the main 2. I didn't want to
confuse people with too much information, since this is not an Ionic
blog post.
On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez
 wrote:
>
> As long as we don't break pluggable webviews, I don't think it's needed,
> there are other wkwebview plugins (from telerik, oracle, etc).
>
> But as some (or all) of them started as forks, there will be probably
> problems with duplicate class names.
>
> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski :
>
> > Many Cordova users out there are probably using
> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
> > play any role in regards to the blog post? Should this maybe be
> > mentioned as an anticipated question?
> >
> > 2018-08-02 16:31 GMT+02:00 Shazron :
> > > Please review the draft of the blog post about this:
> > > "The Future of the iOS WebView in Apache Cordova"
> > > https://github.com/apache/cordova-docs/pull/867
> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
> > >>
> > >> I've done with my review with all the issues that need to resolved
> > >> with the plugin before it can be baked in to the platform for a major
> > >> version release. I'm going to discuss issues with respect to migration
> > >> of developers from UIWebView (features that will be lost or are
> > >> different)
> > >>
> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has
> > >> created a plugin for a workaround. See
> > >> https://issues.apache.org/jira/browse/CB-12074
> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
> > >> 3. Can't execute JavaScript code in the background. There are several
> > >> issues related to this. See
> > >> https://issues.apache.org/jira/browse/CB-12815
> > >> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> > >> Sharing issue (CORS). There is a workaround plugin created by Oracle
> > >> (UPL licensed, which is Apache-2.0 compatible). See
> > >> https://issues.apache.org/jira/browse/CB-10143
> > >> 5. Migration of localStorage from UIWebView. There is a migration
> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974
> > >>
> > >> Of course there are several bugs also that need to be resolved. List
> > >> here: https://s.apache.org/QfsF
> > >>
> > >> Out of the 5 issues, 3 (external) plugins are available for the
> > >> issues, 2 require minor code changes.
> > >>
> > >> For a solution to issue 5, I am proposing a proxy webview engine
> > >> plugin that will:
> > >> 1. Read a preference to use a particular webview engine
> > >> 2. Proxy the selected webview engine's interface from its interface
> > >>
> > >> This proxy will possibly help with migration and testing, so users can
> > >> "beta test" WKWebView now for existing apps (and switch back if there
> > >> are problems). This is like a "feature flag" that I mentioned before,
> > >> but at runtime, for users.
> > >>
> > >> This proxy webview engine plugin can also possibly help with
> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a
> > >> webview's interface).
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Chris Brody]

> we have issues.cordova.io that right now it just redirects to jira, so
> maybe we should have a web page were we list all the repos instead?

+1

> >- How to manage meta-issues that concern more than one repo (Can we

+1

> >productively use whatever tools GitHub provides here, or will we have to
> >get permission from INFRA for every little thing we do?)

+1

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[julio cesar sanchez]

we have issues.cordova.io that right now it just redirects to jira, so
maybe we should have a web page were we list all the repos instead?

2018-08-02 16:51 GMT+02:00 :

> There is much I don't like about JIRA and in general I prefer GitHub
> issues. However, there's issues that did came up during previous
> discussions of this topic, and that have no proper solution that I know of
>
>- How do people know in which of the numerous Cordova repos to create
>their issues (especially bad for tooling)
>- How to manage meta-issues that concern more than one repo (Can we
>productively use whatever tools GitHub provides here, or will we have to
>get permission from INFRA for every little thing we do?)
>
> I fear that if we blindly rush into this, all we will get is an even more
> fragmented landscape of issues and discussions
>
> Am Do., 2. Aug. 2018 um 16:34 Uhr schrieb Jan Piotrowski <
> piotrow...@gmail.com>:
>
> > Decision making for Apache projects is described here:
> > https://community.apache.org/committers/decisionMaking.html
> >
> > So to make it official:
> > I hereby declare that I will start implementing the stuff from my
> > initial email if nobody objects in the next 72 hours (meaning: before
> > next Monday). After that I will create the INFRA issue.
> >
> > The other, preliminary taks can already be started - I did by creating
> > 2 cordova-docs issues that I already linked. For the rest of b) I will
> > probably start another mailing list thread.
> >
> > 2018-08-02 15:35 GMT+02:00 Chris Brody :
> > > What will it take to take care of a) Enable GitHub issues on all
> > > repositories via INFRA ticket?
> > >
> > > I think this is needed really badly. There are way too many cases of
> > > questions and issues being raised in the wrong place, lost in diverse
> > > discussion forums, or not even asked at all.
> > > On Wed, Aug 1, 2018 at 9:59 AM Bryan Ellis 
> > wrote:
> > >>
> > >> +1
> > >>
> > >> Not sure if (f) was a task, as in to find a way to integrate GH and
> > Slack, but it does exist.
> > >>
> > >> https://slack.github.com/ 
> > >>
> > >> It covers a lot including new commits, pr, new issues, code reviews,
> > and more.
> > >>
> > >>
> > >> > On Aug 1, 2018, at 22:22, Jan Piotrowski 
> > wrote:
> > >> >
> > >> > Another one:
> > >> >
> > >> > f) Find and activate way for Github issue (and PR) updates to be
> > >> > posted so Slack #issues
> > >> >
> > >> > 2018-07-31 18:14 GMT+02:00 Jan Piotrowski :
> > >> >> The npm forum solves a very different problem for npm - they had
> too
> > >> >> much noise in Github issues because of the project's popularity.
> Too
> > >> >> much popularity is not one of Cordova's problems ;)
> > >> >>
> > >> >> Many uses of cordova-discuss will be able to move to the individual
> > >> >> project repositories issues, maybe we can even think about getting
> > rid
> > >> >> of it. Good thing to keep in mind after everything is migrated.
> > >> >> The mailing list can be used much more to just point people to a
> > >> >> specific issue (as I also did in my original mail here) where the
> > >> >> actual discussion will happen.
> > >> >>
> > >> >> -J
> > >> >>
> > >> >> 2018-07-31 17:39 GMT+02:00 Chris Brody :
> > >> >>> +1 (+100) for migrating away from JIRA issues
> > >> >>>
> > >> >>> npm took a different approach that I am starting to really like:
> > using
> > >> >>> npm.community (Discourse) with GitHub login for issues and
> > discussions
> > >> >>>
> > >> >>> solves another major problem since I don't like mail list for
> > >> >>> discussing issues and cordova-discuss has proven to be such an
> > >> >>> unpopular repo
> > >> >>> On Tue, Jul 31, 2018 at 10:54 AM Jan Piotrowski <
> > piotrow...@gmail.com> wrote:
> > >> 
> > >>  While our repositories are already fully on GitHub [1], our
> issues
> > >>  mainly still live in JIRA. We previously decided this should be
> > >>  changed [2] so issues live with code.
> > >> 
> > >>  We also did some first switches that were pretty successful:
> > >> 
> > >>  https://github.com/apache/cordova-docs/issues
> > >>  https://github.com/apache/cordova-windows/issues
> > >> 
> > >>  So I suggest we move forward with the rest. Here is a list of
> > stuff to do:
> > >> 
> > >> 
> > >>  a) Enable GitHub issues on all repositories via INFRA ticket
> > >> 
> > >>  b) Define and update Contributor documentation:
> > >>   * Contributor guidelines
> > >> -
> > https://cordova.apache.org/contribute/contribute_guidelines.html
> > >> - https://cordova.apache.org/contribute/
> > >> - https://cordova.apache.org/contribute/issues.html
> > >> -
> > https://github.com/apache/cordova-coho/search?l=Markdown=JIRA
> > >> => https://github.com/apache/cordova-docs/issues/861
> > >>   * Issue template(s)
> > >>   * Pull Request template(s)
> > >>   * Github labels / issue triaging 

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[raphinesse]

There is much I don't like about JIRA and in general I prefer GitHub
issues. However, there's issues that did came up during previous
discussions of this topic, and that have no proper solution that I know of

   - How do people know in which of the numerous Cordova repos to create
   their issues (especially bad for tooling)
   - How to manage meta-issues that concern more than one repo (Can we
   productively use whatever tools GitHub provides here, or will we have to
   get permission from INFRA for every little thing we do?)

I fear that if we blindly rush into this, all we will get is an even more
fragmented landscape of issues and discussions

Am Do., 2. Aug. 2018 um 16:34 Uhr schrieb Jan Piotrowski <
piotrow...@gmail.com>:

> Decision making for Apache projects is described here:
> https://community.apache.org/committers/decisionMaking.html
>
> So to make it official:
> I hereby declare that I will start implementing the stuff from my
> initial email if nobody objects in the next 72 hours (meaning: before
> next Monday). After that I will create the INFRA issue.
>
> The other, preliminary taks can already be started - I did by creating
> 2 cordova-docs issues that I already linked. For the rest of b) I will
> probably start another mailing list thread.
>
> 2018-08-02 15:35 GMT+02:00 Chris Brody :
> > What will it take to take care of a) Enable GitHub issues on all
> > repositories via INFRA ticket?
> >
> > I think this is needed really badly. There are way too many cases of
> > questions and issues being raised in the wrong place, lost in diverse
> > discussion forums, or not even asked at all.
> > On Wed, Aug 1, 2018 at 9:59 AM Bryan Ellis 
> wrote:
> >>
> >> +1
> >>
> >> Not sure if (f) was a task, as in to find a way to integrate GH and
> Slack, but it does exist.
> >>
> >> https://slack.github.com/ 
> >>
> >> It covers a lot including new commits, pr, new issues, code reviews,
> and more.
> >>
> >>
> >> > On Aug 1, 2018, at 22:22, Jan Piotrowski 
> wrote:
> >> >
> >> > Another one:
> >> >
> >> > f) Find and activate way for Github issue (and PR) updates to be
> >> > posted so Slack #issues
> >> >
> >> > 2018-07-31 18:14 GMT+02:00 Jan Piotrowski :
> >> >> The npm forum solves a very different problem for npm - they had too
> >> >> much noise in Github issues because of the project's popularity. Too
> >> >> much popularity is not one of Cordova's problems ;)
> >> >>
> >> >> Many uses of cordova-discuss will be able to move to the individual
> >> >> project repositories issues, maybe we can even think about getting
> rid
> >> >> of it. Good thing to keep in mind after everything is migrated.
> >> >> The mailing list can be used much more to just point people to a
> >> >> specific issue (as I also did in my original mail here) where the
> >> >> actual discussion will happen.
> >> >>
> >> >> -J
> >> >>
> >> >> 2018-07-31 17:39 GMT+02:00 Chris Brody :
> >> >>> +1 (+100) for migrating away from JIRA issues
> >> >>>
> >> >>> npm took a different approach that I am starting to really like:
> using
> >> >>> npm.community (Discourse) with GitHub login for issues and
> discussions
> >> >>>
> >> >>> solves another major problem since I don't like mail list for
> >> >>> discussing issues and cordova-discuss has proven to be such an
> >> >>> unpopular repo
> >> >>> On Tue, Jul 31, 2018 at 10:54 AM Jan Piotrowski <
> piotrow...@gmail.com> wrote:
> >> 
> >>  While our repositories are already fully on GitHub [1], our issues
> >>  mainly still live in JIRA. We previously decided this should be
> >>  changed [2] so issues live with code.
> >> 
> >>  We also did some first switches that were pretty successful:
> >> 
> >>  https://github.com/apache/cordova-docs/issues
> >>  https://github.com/apache/cordova-windows/issues
> >> 
> >>  So I suggest we move forward with the rest. Here is a list of
> stuff to do:
> >> 
> >> 
> >>  a) Enable GitHub issues on all repositories via INFRA ticket
> >> 
> >>  b) Define and update Contributor documentation:
> >>   * Contributor guidelines
> >> -
> https://cordova.apache.org/contribute/contribute_guidelines.html
> >> - https://cordova.apache.org/contribute/
> >> - https://cordova.apache.org/contribute/issues.html
> >> -
> https://github.com/apache/cordova-coho/search?l=Markdown=JIRA
> >> => https://github.com/apache/cordova-docs/issues/861
> >>   * Issue template(s)
> >>   * Pull Request template(s)
> >>   * Github labels / issue triaging documentation
> >>   * Usage of GitHub merge functionality
> >>   * READMEs of all repositories
> >>   * Prepare all these changes as PRs that can merged when a) is
> taken care of.
> >> 
> >>  c) Define and document handling of security issues
> >> => https://github.com/apache/cordova-docs/issues/860
> >> 
> >>  d) Define and execute issue migration from JIRA to 

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Chris Brody]

+1
On Thu, Aug 2, 2018 at 10:34 AM Jan Piotrowski  wrote:
>
> Decision making for Apache projects is described here:
> https://community.apache.org/committers/decisionMaking.html
>
> So to make it official:
> I hereby declare that I will start implementing the stuff from my
> initial email if nobody objects in the next 72 hours (meaning: before
> next Monday). After that I will create the INFRA issue.
>
> The other, preliminary taks can already be started - I did by creating
> 2 cordova-docs issues that I already linked. For the rest of b) I will
> probably start another mailing list thread.
>
> 2018-08-02 15:35 GMT+02:00 Chris Brody :
> > What will it take to take care of a) Enable GitHub issues on all
> > repositories via INFRA ticket?
> >
> > I think this is needed really badly. There are way too many cases of
> > questions and issues being raised in the wrong place, lost in diverse
> > discussion forums, or not even asked at all.
> > On Wed, Aug 1, 2018 at 9:59 AM Bryan Ellis  wrote:
> >>
> >> +1
> >>
> >> Not sure if (f) was a task, as in to find a way to integrate GH and Slack, 
> >> but it does exist.
> >>
> >> https://slack.github.com/ 
> >>
> >> It covers a lot including new commits, pr, new issues, code reviews, and 
> >> more.
> >>
> >>
> >> > On Aug 1, 2018, at 22:22, Jan Piotrowski  wrote:
> >> >
> >> > Another one:
> >> >
> >> > f) Find and activate way for Github issue (and PR) updates to be
> >> > posted so Slack #issues
> >> >
> >> > 2018-07-31 18:14 GMT+02:00 Jan Piotrowski :
> >> >> The npm forum solves a very different problem for npm - they had too
> >> >> much noise in Github issues because of the project's popularity. Too
> >> >> much popularity is not one of Cordova's problems ;)
> >> >>
> >> >> Many uses of cordova-discuss will be able to move to the individual
> >> >> project repositories issues, maybe we can even think about getting rid
> >> >> of it. Good thing to keep in mind after everything is migrated.
> >> >> The mailing list can be used much more to just point people to a
> >> >> specific issue (as I also did in my original mail here) where the
> >> >> actual discussion will happen.
> >> >>
> >> >> -J
> >> >>
> >> >> 2018-07-31 17:39 GMT+02:00 Chris Brody :
> >> >>> +1 (+100) for migrating away from JIRA issues
> >> >>>
> >> >>> npm took a different approach that I am starting to really like: using
> >> >>> npm.community (Discourse) with GitHub login for issues and discussions
> >> >>>
> >> >>> solves another major problem since I don't like mail list for
> >> >>> discussing issues and cordova-discuss has proven to be such an
> >> >>> unpopular repo
> >> >>> On Tue, Jul 31, 2018 at 10:54 AM Jan Piotrowski  
> >> >>> wrote:
> >> 
> >>  While our repositories are already fully on GitHub [1], our issues
> >>  mainly still live in JIRA. We previously decided this should be
> >>  changed [2] so issues live with code.
> >> 
> >>  We also did some first switches that were pretty successful:
> >> 
> >>  https://github.com/apache/cordova-docs/issues
> >>  https://github.com/apache/cordova-windows/issues
> >> 
> >>  So I suggest we move forward with the rest. Here is a list of stuff 
> >>  to do:
> >> 
> >> 
> >>  a) Enable GitHub issues on all repositories via INFRA ticket
> >> 
> >>  b) Define and update Contributor documentation:
> >>   * Contributor guidelines
> >> - https://cordova.apache.org/contribute/contribute_guidelines.html
> >> - https://cordova.apache.org/contribute/
> >> - https://cordova.apache.org/contribute/issues.html
> >> - https://github.com/apache/cordova-coho/search?l=Markdown=JIRA
> >> => https://github.com/apache/cordova-docs/issues/861
> >>   * Issue template(s)
> >>   * Pull Request template(s)
> >>   * Github labels / issue triaging documentation
> >>   * Usage of GitHub merge functionality
> >>   * READMEs of all repositories
> >>   * Prepare all these changes as PRs that can merged when a) is taken 
> >>  care of.
> >> 
> >>  c) Define and document handling of security issues
> >> => https://github.com/apache/cordova-docs/issues/860
> >> 
> >>  d) Define and execute issue migration from JIRA to GitHub
> >>  e) Define and execute "disabling" of JIRA (if applies)
> >> 
> >>  Related:
> >>  - Check if ICLA documentation is correct and fix if necessary
> >> 
> >> 
> >>  Any input or objections?
> >> 
> >>  I expect d) and e) to require some more discussion and planning, but
> >>  think it is ok to just leave this to be done later after everything
> >>  else was taken care of. Agree?
> >> 
> >>  Did I miss any documents for b) that will have to be updated?
> >> 
> >> 
> >>  Best regards,
> >>  Jan
> >> 
> >> 
> >>  PS:
> >> 
> >>  For future reference, the links I collected while 

Re: WKWebView plugin - issues before baking it in to cordova-ios

[julio cesar sanchez]

As long as we don't break pluggable webviews, I don't think it's needed,
there are other wkwebview plugins (from telerik, oracle, etc).

But as some (or all) of them started as forks, there will be probably
problems with duplicate class names.

2018-08-02 16:42 GMT+02:00 Jan Piotrowski :

> Many Cordova users out there are probably using
> https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
> play any role in regards to the blog post? Should this maybe be
> mentioned as an anticipated question?
>
> 2018-08-02 16:31 GMT+02:00 Shazron :
> > Please review the draft of the blog post about this:
> > "The Future of the iOS WebView in Apache Cordova"
> > https://github.com/apache/cordova-docs/pull/867
> > On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
> >>
> >> I've done with my review with all the issues that need to resolved
> >> with the plugin before it can be baked in to the platform for a major
> >> version release. I'm going to discuss issues with respect to migration
> >> of developers from UIWebView (features that will be lost or are
> >> different)
> >>
> >> 1. Cookies don't persist. This is a WebKit bug, but someone has
> >> created a plugin for a workaround. See
> >> https://issues.apache.org/jira/browse/CB-12074
> >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
> >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
> >> 3. Can't execute JavaScript code in the background. There are several
> >> issues related to this. See
> >> https://issues.apache.org/jira/browse/CB-12815
> >> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> >> Sharing issue (CORS). There is a workaround plugin created by Oracle
> >> (UPL licensed, which is Apache-2.0 compatible). See
> >> https://issues.apache.org/jira/browse/CB-10143
> >> 5. Migration of localStorage from UIWebView. There is a migration
> >> plugin available. See https://issues.apache.org/jira/browse/CB-11974
> >>
> >> Of course there are several bugs also that need to be resolved. List
> >> here: https://s.apache.org/QfsF
> >>
> >> Out of the 5 issues, 3 (external) plugins are available for the
> >> issues, 2 require minor code changes.
> >>
> >> For a solution to issue 5, I am proposing a proxy webview engine
> >> plugin that will:
> >> 1. Read a preference to use a particular webview engine
> >> 2. Proxy the selected webview engine's interface from its interface
> >>
> >> This proxy will possibly help with migration and testing, so users can
> >> "beta test" WKWebView now for existing apps (and switch back if there
> >> are problems). This is like a "feature flag" that I mentioned before,
> >> but at runtime, for users.
> >>
> >> This proxy webview engine plugin can also possibly help with
> >> InAppBrowser, I'm not sure (since that plugin has more hooks into a
> >> webview's interface).
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Do another cordova-android patch release?

[julio cesar sanchez]

It bumps gradle and gradle plugin versions, which might break old things

2018-08-02 16:28 GMT+02:00 Jan Piotrowski :

> > Also considered adding this one about Android Studio compatibility, but
> was
> > not sure if the change might be considered breaking or at least minor, so
> > didn't do it.
>
> What would be an argument for this to be considered breaking?
>
> 2018-08-02 13:26 GMT+02:00 julio cesar sanchez :
> > I've sent the PR with the cherry pick
> >
> > https://github.com/apache/cordova-android/pull/469
> >
> > It include 4 commits, 3 related to the plugins and another one about
> > simulator failing to launch.
> >
> > Also considered adding this one about Android Studio compatibility, but
> was
> > not sure if the change might be considered breaking or at least minor, so
> > didn't do it.
> >
> > https://github.com/apache/cordova-android/commit/
> > 5c4f8ca24629486847d363921d1aaa0a69f5
> >
> >
> >
> > 2018-07-31 0:47 GMT+02:00 Chris Brody :
> >
> >> I would favor raising a JIRA issue to port those changes and port by
> >> cherry-pick. I would also favor not including any non-essential
> >> changes in such a patch release.
> >> On Mon, Jul 30, 2018 at 6:39 PM julio cesar sanchez
> >>  wrote:
> >> >
> >> > So starting in August, using at least SDK 26 as target will be
> mandatory
> >> > for submitting to google play.
> >> > The first cordova-android that targeted SDK 26 was 7.0.0, but a lot of
> >> > people is not updating because of breaking changes and plugins
> failing to
> >> > install because of them.
> >> > We have fixed the plugin compatibility in master, so I think it would
> be
> >> > good to do a new patch release with those fixes included.
> >> >
> >> > So, what should we do to add those fixes to a new release? just
> >> cherry-pick
> >> > the commits to the 7.1.x branch? With a PR or we have to use some tool
> >> > (like coho)?
> >> >
> >> > Those are the two PRs I'm talking about
> >> >
> >> > https://github.com/apache/cordova-android/pull/449
> >> > https://github.com/apache/cordova-android/pull/437
> >> >
> >> > Any other PR/commit that could be included if it's not breaking?
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Jan Piotrowski]

Many Cordova users out there are probably using
https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
play any role in regards to the blog post? Should this maybe be
mentioned as an anticipated question?

2018-08-02 16:31 GMT+02:00 Shazron :
> Please review the draft of the blog post about this:
> "The Future of the iOS WebView in Apache Cordova"
> https://github.com/apache/cordova-docs/pull/867
> On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
>>
>> I've done with my review with all the issues that need to resolved
>> with the plugin before it can be baked in to the platform for a major
>> version release. I'm going to discuss issues with respect to migration
>> of developers from UIWebView (features that will be lost or are
>> different)
>>
>> 1. Cookies don't persist. This is a WebKit bug, but someone has
>> created a plugin for a workaround. See
>> https://issues.apache.org/jira/browse/CB-12074
>> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
>> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
>> 3. Can't execute JavaScript code in the background. There are several
>> issues related to this. See
>> https://issues.apache.org/jira/browse/CB-12815
>> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
>> Sharing issue (CORS). There is a workaround plugin created by Oracle
>> (UPL licensed, which is Apache-2.0 compatible). See
>> https://issues.apache.org/jira/browse/CB-10143
>> 5. Migration of localStorage from UIWebView. There is a migration
>> plugin available. See https://issues.apache.org/jira/browse/CB-11974
>>
>> Of course there are several bugs also that need to be resolved. List
>> here: https://s.apache.org/QfsF
>>
>> Out of the 5 issues, 3 (external) plugins are available for the
>> issues, 2 require minor code changes.
>>
>> For a solution to issue 5, I am proposing a proxy webview engine
>> plugin that will:
>> 1. Read a preference to use a particular webview engine
>> 2. Proxy the selected webview engine's interface from its interface
>>
>> This proxy will possibly help with migration and testing, so users can
>> "beta test" WKWebView now for existing apps (and switch back if there
>> are problems). This is like a "feature flag" that I mentioned before,
>> but at runtime, for users.
>>
>> This proxy webview engine plugin can also possibly help with
>> InAppBrowser, I'm not sure (since that plugin has more hooks into a
>> webview's interface).
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: ios-deploy questions

[Jan Piotrowski]

> 1. Why not make ios-deploy a dependency of cordova-ios that would then
> be automatically installed?

Historically, I think, commands that should be able to be called via
the command line had to be installed globally with npm to work. Is
this not the case any more?

2018-08-02 15:26 GMT+02:00 Chris Brody :
> A couple things that I think are not clear for
> :
>
> 1. Why not make ios-deploy a dependency of cordova-ios that would then
> be automatically installed?
>
> 2. Is there a risk of mismatch between a users installed ios-deploy
> version and a users Cordova version? Should this be documented, if so?
>
> I think the answer to 1 is that ios-deploy sometimes needs to be
> installed with more system privs. I am not 100% sure of this, would
> love some confirmation from an expert. And I think this is not really
> a problem most of the time.
>
> I think the answer to 2 is "not yet".
>
> Confirmation would be really helpful.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

Decision making for Apache projects is described here:
https://community.apache.org/committers/decisionMaking.html

So to make it official:
I hereby declare that I will start implementing the stuff from my
initial email if nobody objects in the next 72 hours (meaning: before
next Monday). After that I will create the INFRA issue.

The other, preliminary taks can already be started - I did by creating
2 cordova-docs issues that I already linked. For the rest of b) I will
probably start another mailing list thread.

2018-08-02 15:35 GMT+02:00 Chris Brody :
> What will it take to take care of a) Enable GitHub issues on all
> repositories via INFRA ticket?
>
> I think this is needed really badly. There are way too many cases of
> questions and issues being raised in the wrong place, lost in diverse
> discussion forums, or not even asked at all.
> On Wed, Aug 1, 2018 at 9:59 AM Bryan Ellis  wrote:
>>
>> +1
>>
>> Not sure if (f) was a task, as in to find a way to integrate GH and Slack, 
>> but it does exist.
>>
>> https://slack.github.com/ 
>>
>> It covers a lot including new commits, pr, new issues, code reviews, and 
>> more.
>>
>>
>> > On Aug 1, 2018, at 22:22, Jan Piotrowski  wrote:
>> >
>> > Another one:
>> >
>> > f) Find and activate way for Github issue (and PR) updates to be
>> > posted so Slack #issues
>> >
>> > 2018-07-31 18:14 GMT+02:00 Jan Piotrowski :
>> >> The npm forum solves a very different problem for npm - they had too
>> >> much noise in Github issues because of the project's popularity. Too
>> >> much popularity is not one of Cordova's problems ;)
>> >>
>> >> Many uses of cordova-discuss will be able to move to the individual
>> >> project repositories issues, maybe we can even think about getting rid
>> >> of it. Good thing to keep in mind after everything is migrated.
>> >> The mailing list can be used much more to just point people to a
>> >> specific issue (as I also did in my original mail here) where the
>> >> actual discussion will happen.
>> >>
>> >> -J
>> >>
>> >> 2018-07-31 17:39 GMT+02:00 Chris Brody :
>> >>> +1 (+100) for migrating away from JIRA issues
>> >>>
>> >>> npm took a different approach that I am starting to really like: using
>> >>> npm.community (Discourse) with GitHub login for issues and discussions
>> >>>
>> >>> solves another major problem since I don't like mail list for
>> >>> discussing issues and cordova-discuss has proven to be such an
>> >>> unpopular repo
>> >>> On Tue, Jul 31, 2018 at 10:54 AM Jan Piotrowski  
>> >>> wrote:
>> 
>>  While our repositories are already fully on GitHub [1], our issues
>>  mainly still live in JIRA. We previously decided this should be
>>  changed [2] so issues live with code.
>> 
>>  We also did some first switches that were pretty successful:
>> 
>>  https://github.com/apache/cordova-docs/issues
>>  https://github.com/apache/cordova-windows/issues
>> 
>>  So I suggest we move forward with the rest. Here is a list of stuff to 
>>  do:
>> 
>> 
>>  a) Enable GitHub issues on all repositories via INFRA ticket
>> 
>>  b) Define and update Contributor documentation:
>>   * Contributor guidelines
>> - https://cordova.apache.org/contribute/contribute_guidelines.html
>> - https://cordova.apache.org/contribute/
>> - https://cordova.apache.org/contribute/issues.html
>> - https://github.com/apache/cordova-coho/search?l=Markdown=JIRA
>> => https://github.com/apache/cordova-docs/issues/861
>>   * Issue template(s)
>>   * Pull Request template(s)
>>   * Github labels / issue triaging documentation
>>   * Usage of GitHub merge functionality
>>   * READMEs of all repositories
>>   * Prepare all these changes as PRs that can merged when a) is taken 
>>  care of.
>> 
>>  c) Define and document handling of security issues
>> => https://github.com/apache/cordova-docs/issues/860
>> 
>>  d) Define and execute issue migration from JIRA to GitHub
>>  e) Define and execute "disabling" of JIRA (if applies)
>> 
>>  Related:
>>  - Check if ICLA documentation is correct and fix if necessary
>> 
>> 
>>  Any input or objections?
>> 
>>  I expect d) and e) to require some more discussion and planning, but
>>  think it is ok to just leave this to be done later after everything
>>  else was taken care of. Agree?
>> 
>>  Did I miss any documents for b) that will have to be updated?
>> 
>> 
>>  Best regards,
>>  Jan
>> 
>> 
>>  PS:
>> 
>>  For future reference, the links I collected while researching the
>>  previous work done and current state:
>> 
>>  [1] Move repositories to Github / Gitbox for Apache Cordova:
>>  https://lists.apache.org/thread.html/af0ec86818674bd1a8c4a9372685a9ae8e6200c478ad8e859606f3a3@%3Cdev.cordova.apache.org%3E
>>  

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Shazron]

Please review the draft of the blog post about this:
"The Future of the iOS WebView in Apache Cordova"
https://github.com/apache/cordova-docs/pull/867
On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
>
> I've done with my review with all the issues that need to resolved
> with the plugin before it can be baked in to the platform for a major
> version release. I'm going to discuss issues with respect to migration
> of developers from UIWebView (features that will be lost or are
> different)
>
> 1. Cookies don't persist. This is a WebKit bug, but someone has
> created a plugin for a workaround. See
> https://issues.apache.org/jira/browse/CB-12074
> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
> 3. Can't execute JavaScript code in the background. There are several
> issues related to this. See
> https://issues.apache.org/jira/browse/CB-12815
> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
> Sharing issue (CORS). There is a workaround plugin created by Oracle
> (UPL licensed, which is Apache-2.0 compatible). See
> https://issues.apache.org/jira/browse/CB-10143
> 5. Migration of localStorage from UIWebView. There is a migration
> plugin available. See https://issues.apache.org/jira/browse/CB-11974
>
> Of course there are several bugs also that need to be resolved. List
> here: https://s.apache.org/QfsF
>
> Out of the 5 issues, 3 (external) plugins are available for the
> issues, 2 require minor code changes.
>
> For a solution to issue 5, I am proposing a proxy webview engine
> plugin that will:
> 1. Read a preference to use a particular webview engine
> 2. Proxy the selected webview engine's interface from its interface
>
> This proxy will possibly help with migration and testing, so users can
> "beta test" WKWebView now for existing apps (and switch back if there
> are problems). This is like a "feature flag" that I mentioned before,
> but at runtime, for users.
>
> This proxy webview engine plugin can also possibly help with
> InAppBrowser, I'm not sure (since that plugin has more hooks into a
> webview's interface).

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Do another cordova-android patch release?

[Jan Piotrowski]

> Also considered adding this one about Android Studio compatibility, but was
> not sure if the change might be considered breaking or at least minor, so
> didn't do it.

What would be an argument for this to be considered breaking?

2018-08-02 13:26 GMT+02:00 julio cesar sanchez :
> I've sent the PR with the cherry pick
>
> https://github.com/apache/cordova-android/pull/469
>
> It include 4 commits, 3 related to the plugins and another one about
> simulator failing to launch.
>
> Also considered adding this one about Android Studio compatibility, but was
> not sure if the change might be considered breaking or at least minor, so
> didn't do it.
>
> https://github.com/apache/cordova-android/commit/
> 5c4f8ca24629486847d363921d1aaa0a69f5
>
>
>
> 2018-07-31 0:47 GMT+02:00 Chris Brody :
>
>> I would favor raising a JIRA issue to port those changes and port by
>> cherry-pick. I would also favor not including any non-essential
>> changes in such a patch release.
>> On Mon, Jul 30, 2018 at 6:39 PM julio cesar sanchez
>>  wrote:
>> >
>> > So starting in August, using at least SDK 26 as target will be mandatory
>> > for submitting to google play.
>> > The first cordova-android that targeted SDK 26 was 7.0.0, but a lot of
>> > people is not updating because of breaking changes and plugins failing to
>> > install because of them.
>> > We have fixed the plugin compatibility in master, so I think it would be
>> > good to do a new patch release with those fixes included.
>> >
>> > So, what should we do to add those fixes to a new release? just
>> cherry-pick
>> > the commits to the 7.1.x branch? With a PR or we have to use some tool
>> > (like coho)?
>> >
>> > Those are the two PRs I'm talking about
>> >
>> > https://github.com/apache/cordova-android/pull/449
>> > https://github.com/apache/cordova-android/pull/437
>> >
>> > Any other PR/commit that could be included if it's not breaking?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: ios-deploy questions

[Chris Brody]

To add some context: this question is moved from
https://github.com/apache/cordova-docs/issues/866

I think we should clarify both of the following:
* "Should this be documented in another way?"
* "Should this be different?"

Confirmation would be really appreciated.
On Thu, Aug 2, 2018 at 9:26 AM Chris Brody  wrote:
>
> A couple things that I think are not clear for
> :
>
> 1. Why not make ios-deploy a dependency of cordova-ios that would then
> be automatically installed?
>
> 2. Is there a risk of mismatch between a users installed ios-deploy
> version and a users Cordova version? Should this be documented, if so?
>
> I think the answer to 1 is that ios-deploy sometimes needs to be
> installed with more system privs. I am not 100% sure of this, would
> love some confirmation from an expert. And I think this is not really
> a problem most of the time.
>
> I think the answer to 2 is "not yet".
>
> Confirmation would be really helpful.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Chris Brody]

What will it take to take care of a) Enable GitHub issues on all
repositories via INFRA ticket?

I think this is needed really badly. There are way too many cases of
questions and issues being raised in the wrong place, lost in diverse
discussion forums, or not even asked at all.
On Wed, Aug 1, 2018 at 9:59 AM Bryan Ellis  wrote:
>
> +1
>
> Not sure if (f) was a task, as in to find a way to integrate GH and Slack, 
> but it does exist.
>
> https://slack.github.com/ 
>
> It covers a lot including new commits, pr, new issues, code reviews, and more.
>
>
> > On Aug 1, 2018, at 22:22, Jan Piotrowski  wrote:
> >
> > Another one:
> >
> > f) Find and activate way for Github issue (and PR) updates to be
> > posted so Slack #issues
> >
> > 2018-07-31 18:14 GMT+02:00 Jan Piotrowski :
> >> The npm forum solves a very different problem for npm - they had too
> >> much noise in Github issues because of the project's popularity. Too
> >> much popularity is not one of Cordova's problems ;)
> >>
> >> Many uses of cordova-discuss will be able to move to the individual
> >> project repositories issues, maybe we can even think about getting rid
> >> of it. Good thing to keep in mind after everything is migrated.
> >> The mailing list can be used much more to just point people to a
> >> specific issue (as I also did in my original mail here) where the
> >> actual discussion will happen.
> >>
> >> -J
> >>
> >> 2018-07-31 17:39 GMT+02:00 Chris Brody :
> >>> +1 (+100) for migrating away from JIRA issues
> >>>
> >>> npm took a different approach that I am starting to really like: using
> >>> npm.community (Discourse) with GitHub login for issues and discussions
> >>>
> >>> solves another major problem since I don't like mail list for
> >>> discussing issues and cordova-discuss has proven to be such an
> >>> unpopular repo
> >>> On Tue, Jul 31, 2018 at 10:54 AM Jan Piotrowski  
> >>> wrote:
> 
>  While our repositories are already fully on GitHub [1], our issues
>  mainly still live in JIRA. We previously decided this should be
>  changed [2] so issues live with code.
> 
>  We also did some first switches that were pretty successful:
> 
>  https://github.com/apache/cordova-docs/issues
>  https://github.com/apache/cordova-windows/issues
> 
>  So I suggest we move forward with the rest. Here is a list of stuff to 
>  do:
> 
> 
>  a) Enable GitHub issues on all repositories via INFRA ticket
> 
>  b) Define and update Contributor documentation:
>   * Contributor guidelines
> - https://cordova.apache.org/contribute/contribute_guidelines.html
> - https://cordova.apache.org/contribute/
> - https://cordova.apache.org/contribute/issues.html
> - https://github.com/apache/cordova-coho/search?l=Markdown=JIRA
> => https://github.com/apache/cordova-docs/issues/861
>   * Issue template(s)
>   * Pull Request template(s)
>   * Github labels / issue triaging documentation
>   * Usage of GitHub merge functionality
>   * READMEs of all repositories
>   * Prepare all these changes as PRs that can merged when a) is taken 
>  care of.
> 
>  c) Define and document handling of security issues
> => https://github.com/apache/cordova-docs/issues/860
> 
>  d) Define and execute issue migration from JIRA to GitHub
>  e) Define and execute "disabling" of JIRA (if applies)
> 
>  Related:
>  - Check if ICLA documentation is correct and fix if necessary
> 
> 
>  Any input or objections?
> 
>  I expect d) and e) to require some more discussion and planning, but
>  think it is ok to just leave this to be done later after everything
>  else was taken care of. Agree?
> 
>  Did I miss any documents for b) that will have to be updated?
> 
> 
>  Best regards,
>  Jan
> 
> 
>  PS:
> 
>  For future reference, the links I collected while researching the
>  previous work done and current state:
> 
>  [1] Move repositories to Github / Gitbox for Apache Cordova:
>  https://lists.apache.org/thread.html/af0ec86818674bd1a8c4a9372685a9ae8e6200c478ad8e859606f3a3@%3Cdev.cordova.apache.org%3E
>  https://issues.apache.org/jira/browse/INFRA-14347
>  https://issues.apache.org/jira/browse/INFRA-14398
>  https://issues.apache.org/jira/browse/INFRA-14399
>  https://lists.apache.org/thread.html/23e927ad58441685a3fb3bbfe8e4d9f52369afa24e6e57f74b247d17@%3Cdev.cordova.apache.org%3E
>  https://issues.apache.org/jira/browse/INFRA-14994
>  https://issues.apache.org/jira/browse/INFRA-14815
>  https://lists.apache.org/thread.html/649d83cd05ae7029327cd4734ca42282426c5564b291257da1b8b75e@%3Cdev.cordova.apache.org%3E
> 
>  [2] Migrate Jira issues over to Github:
>  https://issues.apache.org/jira/browse/CB-13157
>  

ios-deploy questions

[Chris Brody]

A couple things that I think are not clear for
:

1. Why not make ios-deploy a dependency of cordova-ios that would then
be automatically installed?

2. Is there a risk of mismatch between a users installed ios-deploy
version and a users Cordova version? Should this be documented, if so?

I think the answer to 1 is that ios-deploy sometimes needs to be
installed with more system privs. I am not 100% sure of this, would
love some confirmation from an expert. And I think this is not really
a problem most of the time.

I think the answer to 2 is "not yet".

Confirmation would be really helpful.

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Do another cordova-android patch release?

[julio cesar sanchez]

I've sent the PR with the cherry pick

https://github.com/apache/cordova-android/pull/469

It include 4 commits, 3 related to the plugins and another one about
simulator failing to launch.

Also considered adding this one about Android Studio compatibility, but was
not sure if the change might be considered breaking or at least minor, so
didn't do it.

https://github.com/apache/cordova-android/commit/
5c4f8ca24629486847d363921d1aaa0a69f5



2018-07-31 0:47 GMT+02:00 Chris Brody :

> I would favor raising a JIRA issue to port those changes and port by
> cherry-pick. I would also favor not including any non-essential
> changes in such a patch release.
> On Mon, Jul 30, 2018 at 6:39 PM julio cesar sanchez
>  wrote:
> >
> > So starting in August, using at least SDK 26 as target will be mandatory
> > for submitting to google play.
> > The first cordova-android that targeted SDK 26 was 7.0.0, but a lot of
> > people is not updating because of breaking changes and plugins failing to
> > install because of them.
> > We have fixed the plugin compatibility in master, so I think it would be
> > good to do a new patch release with those fixes included.
> >
> > So, what should we do to add those fixes to a new release? just
> cherry-pick
> > the commits to the 7.1.x branch? With a PR or we have to use some tool
> > (like coho)?
> >
> > Those are the two PRs I'm talking about
> >
> > https://github.com/apache/cordova-android/pull/449
> > https://github.com/apache/cordova-android/pull/437
> >
> > Any other PR/commit that could be included if it's not breaking?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [cordova-android] Fwd: Important reminder about Android targetSdkVersion requirement

[julio cesar sanchez]

cordova-android 7.0.0 targets SDK 26, 7.1.x targets SDK 27, so we are good
to go.

But this is why I wanted to cherry pick the plugin compatibility fixes on
7.1.x branch, so people update to those versions.

And also a new CLI release with 7.1.x pinned will help (but Chris said he
planning on doing it)

So we are good and can be even better by doing the 2 things mentioned
(cherry pick and new CLI release)

BTW, that's for app updates, for new apps it already started the 1st of
August.



2018-08-02 12:41 GMT+02:00 Jan Piotrowski :

> Anything we should do about that for Cordova Android or the default Cordova
> project?
> What should other projects using Cordova Android do? (e.g. Ionic)
>
> -J
>
>
> -- Forwarded message --
> From: Google Play 
> Date: 2018-08-02 4:51 GMT+02:00
> Subject: Important reminder about Android targetSdkVersion requirement
> To: piotrow...@gmail.com
>
>
> View as webpage  »
>  ObRL2ao0bxMJ8esPAk7-wS5Iq_3qhl1F8JHnrrvfSk3tpmw4b16lTASxrUc3WvxSh-7H-
> 5GVDPxOVuWj4CdBpWXCOpgw1l_LwRRgFL-br3e324tQUe_
> 2pz6ztZ5IcG8cFppMfhtvDxvzauAAr03mDLIYxoDN5gImpfU1VpT4SF6Prwj
> 3k48c0tOyBh4qLcmr2E67rzyWun5G3jUNGeMNWTMe8QqpFZ1VH2qQ>
> [image: Google Play] <#m_-8941348242845729157_> Developer update
>
> Hello Google Play Developer,
>
> This is a reminder
>  3CzHcamBSlxPhEqn2OJq_MUpEtt-5iRlmEHy3Idt3BIfHWLAwKIM570LwT
> nCBH6gdgiT7mmI0Fl7g9WBMHLQOcOLKufdKd-ck6eCCZK3GKAQcCTJgCVgrLK3ZQaBKcWGY_
> uiyPfpc8MV9jxdpj0B5qYHVSWEzu3TmTJIE>
> that starting *November 1, 2018*, updates to apps and games on Google Play
> will be required to target Android Oreo (API level 26) or higher. After
> this date, the Play Console will prevent you from submitting new APKs with
> a targetSdkVersion less than 26.
>
> Configuring your app to target a recent API level ensures that users
> benefit from significant security and performance improvements, while still
> allowing your app to run on older Android versions (down to the
> minSdkVersion).
>
> *Action required*
>
> Please ensure that your apps are configured to target at least Android 8.0
> (API level 26) by *November 1, 2018*. For technical advice on how to change
> your app's target API level to meet these requirements, refer to the
> migration
> guide
>  hmyrr7mmZTnUFAZhID6fZI8MqMVrUywaovrmmV1JoOpB735ltxgLgGDa
> NrP7Z4bTS0j5Pv3_bpWQ_JaeLUZdJT08i37LpzZ9qJKP5dtNzpZ
> 3j0FrZRcBL1y2wt2BgGojsSiIhAQ>.
>
>
> *Affected apps*
>
> The apps included below have one or more APKs—in production or testing
> tracks—that aren't currently targeting API level 26 or higher. Apps are
> listed with the maximum version code and corresponding targetSdkVersion. If
> you have more than 20 apps that could be affected in your account, please
> check the Play Console
>  UOYlPbPnpXsqMcCBXDKylalegCOrc5hkiDUBRFI-Nh4bNONsrhCal3RGGIUNsRfLWob8P8AA>
> for a full list.
> de.janpiotrowski.zaehlerstand   3   25
> The Google Play Team [image: Conversation]
>  YMSD4uuDKadY5ipQ-NrGEvjxI9muIowEPos736I2zDveAIr
> 9FdPNr9bsXVd5B2KcpxhtY4RvASD6hQCNSmKWE-fFabEVarEVFl4DPXxoCgxshzrM6yTp_
> QZ0gWjDf5VQoF8m2hLOAtZaKXlCQuzC-fsimpnZGe-K-Aa52h4gkzI>
> [image:
> Globe]
>  QA59Fmljz9lvvQR1eQC89G6lJZmB_J8HMo0P5IhtcCQkMKzAjGZyh2jgTPh
> iFUsbf_-DUX1YU_pol3YFHc_AdSCTPQoALXSkurRF7WnpYY2194-6ddMml2kCwUb>
> © 2018 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA.
> <#m_-8941348242845729157_>
> Email preferences: You have received this mandatory email service
> announcement to update you about important changes to your Google Play
> Developer account.
>

[cordova-android] Fwd: Important reminder about Android targetSdkVersion requirement

[Jan Piotrowski]

Anything we should do about that for Cordova Android or the default Cordova
project?
What should other projects using Cordova Android do? (e.g. Ionic)

-J


-- Forwarded message --
From: Google Play 
Date: 2018-08-02 4:51 GMT+02:00
Subject: Important reminder about Android targetSdkVersion requirement
To: piotrow...@gmail.com


View as webpage  »

[image: Google Play] <#m_-8941348242845729157_> Developer update

Hello Google Play Developer,

This is a reminder

that starting *November 1, 2018*, updates to apps and games on Google Play
will be required to target Android Oreo (API level 26) or higher. After
this date, the Play Console will prevent you from submitting new APKs with
a targetSdkVersion less than 26.

Configuring your app to target a recent API level ensures that users
benefit from significant security and performance improvements, while still
allowing your app to run on older Android versions (down to the
minSdkVersion).

*Action required*

Please ensure that your apps are configured to target at least Android 8.0
(API level 26) by *November 1, 2018*. For technical advice on how to change
your app's target API level to meet these requirements, refer to the migration
guide
.


*Affected apps*

The apps included below have one or more APKs—in production or testing
tracks—that aren't currently targeting API level 26 or higher. Apps are
listed with the maximum version code and corresponding targetSdkVersion. If
you have more than 20 apps that could be affected in your account, please
check the Play Console

for a full list.
de.janpiotrowski.zaehlerstand   3   25
The Google Play Team [image: Conversation]

[image:
Globe]

© 2018 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA.
<#m_-8941348242845729157_>
Email preferences: You have received this mandatory email service
announcement to update you about important changes to your Google Play
Developer account.

Re: Commit package-lock.json in next major Cordova release or not?

[Jan Piotrowski]

+1 - everything that modernizes the tooling that can be used and
actually uses its added functionality is a win.

2018-08-02 7:43 GMT+02:00 Chris Brody :
> Just raised https://issues.apache.org/jira/browse/CB-14248
>
> Thanks for the helpful responses
> On Thu, Aug 2, 2018 at 12:12 AM Shazron  wrote:
>>
>> yes +1
>> On Thu, Aug 2, 2018 at 4:28 AM Chris Brody  wrote:
>> >
>> > I think we should start to commit package-lock.json in the next major
>> > release but am not 100% sure. My understanding is that
>> > package-lock.json mostly serves a couple major purposes:
>> > * preserve the structure of node_modules cross-platform
>> > * use SHA numbers to verify correct packages
>> >
>> > There seem to have been changes between npm@4 (??), npm@5, and npm@6,
>> > as described in the following:
>> > * https://github.com/npm/npm/issues/20434 (npm@5 vs npm@6)
>> > * https://jpospisil.com/2017/06/02/understanding-lock-files-in-npm-5.html
>> >
>> > From what I read I think npm@5 & npm@6 would continue to follow the
>> > semver rules for packages specified in package.json.
>> >
>> > Major advantages I can think of:
>> > * better consistency for cross-platform development
>> > * no need to regenerate package-lock.json for npm audit check
>> >
>> > But I can think of the following possible disadvantages to consider:
>> > * not as easy to update dependencies, probably not possible to just
>> > update dependencies by hand
>> > * some additional "noise" in the git history, shouldn't be too bad though
>> > * possibly major: in case people work on different dependency changes
>> > in parallel and want to merge by git merge, rebase, or cherry-pick
>> > dealing with the package-lock.json changes may not be so clean
>> >
>> > and a counter-point:
>> > * 
>> > https://www.codementor.io/johnkennedy/get-rid-of-that-npm-package-lock-json-e0bj7ai42
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Any reason to support Xcode pre-9 on cordova-ios@4 or cordova-osx?

[julio cesar sanchez]

The only reason I can think is enterprise apps that are not distributed in
App Store or hobbyist that build the apps for themselves. In this cases
they might be using an older computer that can’t execute Xcode 9. But not
sure is worth the effort and we can remove some code not supporting it.
In barcode scanner plugin I made some changes to support iOS 11 that
weren’t compatible with Xcode 8 and 4-5 people complained about it even
though I told them Xcode 9 was going to be mandatory soon.

Also on macOS apps, a great percentage doesn’t distribute through the
store, but I don’t think cordova-osx has that many users.


El El jue, 2 ago 2018 a las 6:12, Shazron  escribió:

> No to all.
> On Thu, Aug 2, 2018 at 11:54 AM Chris Brody  wrote:
> >
> > From https://github.com/apache/cordova-docs/issues/863 it is clear
> > that we are not allowed to use Xcode pre-9.0 with Apple's App Store. I
> > suspect there are also not too many volunteers testing on Xcode
> > pre-9.0. I just raised CB-14245 to drop support for Xcode pre-9.0.
> >
> > Open questions on my side:
> > * Any reason not to drop Xcode pre-9.0 from cordova-ios@latest (4.5.x)
> > & Cordova 8.x iOS docs?
> > * Any reason not to drop Xcode pre-9.0 from next major release of
> cordova-osx?
> > * Any reason not to drop Xcode pre-9.0 from cordova-osx@latest (4.0.x)
> > & Cordova 8.x OSX docs?
> >
> > Thanks to PMC members for the answers of my other questions so far.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>