Re: Doing some late night work, and I found this

[Ian Clelland]

It definitely is interesting -- I haven't tried it out anywhere, but there
are tests for it that at least show how to use it:

https://android.googlesource.com/platform/cts/+/764c7c7/tests/tests/webkit/src/android/webkit/cts/PostMessageTest.java

It looks like it just works with strings on the Java side (WebMessage only
has a String constructor), so de/serialization would be an issue in Cordova
code, but it should be fast on the WebView side. I've no idea what kind of
latency could be expected.

On Wed, Jan 27, 2016 at 9:23 AM, Homer, Tony  wrote:

> Pretty exciting! Definitely seems like it would be cleaner.
> Do you think this would be a new bridge mode?
>
> I spent a couple minutes trying to find an example of how to use this, but
> didn't come up with anything outside of the docs.
>
> Looks like the relevant classes are WebMessage, WebMessagePort and WebView.
> The relevant methods on WebView are createWebMessageChannel[1] and
> postWebMessage[2].
> createWebMessageChannel returns an array of 2 WebMessagePorts.
> I don't quite get how it works - how does the JS side know what port to
> use?
> The WebMessagePort overview [3] talks about transferring a port to JS -
> what does that mean?
>
> I'll come back to this later and re-read the docs.
> Thanks for bringing this up, Joe!
>
>
> [1]
> http://developer.android.com/reference/android/webkit/WebView.html#createWebMessageChannel()
> [2]
> http://developer.android.com/reference/android/webkit/WebView.html#postWebMessage(android.webkit.WebMessage,
> android.net.Uri)
> [3]
> http://developer.android.com/reference/android/webkit/WebMessagePort.html
>
>
> On 1/27/16, 1:10 AM, "Joe Bowser"  wrote:
>
> >http://developer.android.com/reference/android/webkit/WebMessage.html
> >
> >I'm curious as to how this works in comparison to our current method of
> >passing something back from native to the browser and whether this would
> be
> >faster/cleaner.  This would be Android WebView specific, and only would
> >work on API Level 23, but it's interesting.
> >
> >Thoughts?
>

Re: file transfer test failures on Android

[Ian Clelland]

... and it's already committed. Never mind :)

On Thu, Aug 27, 2015 at 2:28 PM, Ian Clelland iclell...@chromium.org
wrote:

 I think Alexander is correct; it should be coalescing any combination of
 whitespace characters into a single space; otherwise we risk changing the
 semantics of the header value.

 On Wed, Aug 26, 2015 at 5:43 PM, Joe Bowser bows...@gmail.com wrote:

 Actually, I'm OK with either.  We should be replacing all control
 characters though.

 On Wed, Aug 26, 2015 at 2:40 PM Joe Bowser bows...@gmail.com wrote:

  It should be an empty string.
 
  On Wed, Aug 26, 2015 at 2:13 PM Alexander Sorokin (Akvelon) 
  v-als...@microsoft.com wrote:
 
  Hi guys,
 
  I think there is a regression in file transfer plugin (two tests are
  failing on Android):
 
 
 https://ci.apache.org/builders/cordova-android-win/builds/261/steps/getting-test-results/logs/stdio
  This is caused by latest commit:
 
 
 https://github.com/apache/cordova-plugin-file-transfer/commit/ad6647120db12f0e67ee4a952a71ea494a39a475#diff-4480f457f31b87b365a8ed3f1b7e9c36R222
 
  The code is replacing all whitespace characters in headers with an
 empty
  string. Should it be a space character?
 
  If so, here is my proposed fix for that:
  https://github.com/apache/cordova-plugin-file-transfer/pull/99
 
  Thanks,
  Alexander Sorokin
 
 

Re: file transfer test failures on Android

[Ian Clelland]

I think Alexander is correct; it should be coalescing any combination of
whitespace characters into a single space; otherwise we risk changing the
semantics of the header value.

On Wed, Aug 26, 2015 at 5:43 PM, Joe Bowser bows...@gmail.com wrote:

 Actually, I'm OK with either.  We should be replacing all control
 characters though.

 On Wed, Aug 26, 2015 at 2:40 PM Joe Bowser bows...@gmail.com wrote:

  It should be an empty string.
 
  On Wed, Aug 26, 2015 at 2:13 PM Alexander Sorokin (Akvelon) 
  v-als...@microsoft.com wrote:
 
  Hi guys,
 
  I think there is a regression in file transfer plugin (two tests are
  failing on Android):
 
 
 https://ci.apache.org/builders/cordova-android-win/builds/261/steps/getting-test-results/logs/stdio
  This is caused by latest commit:
 
 
 https://github.com/apache/cordova-plugin-file-transfer/commit/ad6647120db12f0e67ee4a952a71ea494a39a475#diff-4480f457f31b87b365a8ed3f1b7e9c36R222
 
  The code is replacing all whitespace characters in headers with an empty
  string. Should it be a space character?
 
  If so, here is my proposed fix for that:
  https://github.com/apache/cordova-plugin-file-transfer/pull/99
 
  Thanks,
  Alexander Sorokin
 
 

Re: File.spec.144 purpose

[Ian Clelland]

Yes and no -- it looks like a deliberate change, but it wasn't the original
intention of the test -- the test was put in place as part of
https://issues.apache.org/jira/browse/CB-6428, and it originally tested
that it could copy just the file plugin's assets into local storage.

CB-6428 is about being able to read from android_assets, and so any
directory within the app assets would do. I suspect that the file plugin's
dir was chosen because it should exist if we're testing it.

The source directory was changed, though, about two weeks ago, with this
commit:
https://github.com/apache/cordova-plugin-file/commit/19c8a79a6f4667c8643f84192fd617ce1028be0c
(no JIRA issue, but the comments is that it fixes an issue when browserify
is used -- I presume that the JS-concatenation means that the plugin JS
files aren't present anymore.)

So, any directory under /android_assets/ will do, but you should make sure
that your patch doesn't fail in the same way as the original if browserify
is being used.


On Fri, Aug 21, 2015 at 8:33 AM, Alexander Sorokin (Akvelon) 
v-als...@microsoft.com wrote:

 Hi guys.

 It looks like file.spec.144 copyTo: asset directory tries to copy whole
 www directory. Was it done intentionally?
 On slow environments, especially emulators this can take huge amount of
 time (up to 5 minutes).

 In case it is not substantial and any folder will do, I've prepared a fix
 for this test to stop timing out on Android emulators:
 https://github.com/apache/cordova-plugin-file/pull/129

 Thanks,
 Alexander Sorokin

Re: Unable to use .IN domain

[Ian Clelland]

in is not a reserved keyword Java, but it is in C# -- are you building a
Windows Phone or Windows application?

It looks like Jesse's https://www.npmjs.com/package/valid-identifier
package is catching this.

On Sat, Aug 15, 2015 at 12:57 AM, heman...@leegan.in wrote:

 Dear Sir,



 I would like to use .IN domain in the APP ID while building the Cordova
 application.

 Whenever I try to use



 cordova create hello in.leegan.helloworld HelloWorld

 it says:

 App id contains a reserved word, or is not a valid
 identifier



 It seems to be that in.leegan.helloworld is not valid.



 How can I overcome this limitation ?



 Regards,

 Hemant Ganpule

 LEEGAN SOFTWARES

 Thane, India

Re: Unable to use .IN domain

[Ian Clelland]

On Mon, Aug 17, 2015 at 4:24 PM, Jesse purplecabb...@gmail.com wrote:

 Yes, we go with the lowest common identifier, assuming that the other
 platforms may be added later.


Ahh, now that I read the source more carefully, I see that some
Java-specific items are added at the end (at first glance, it looked like
it just contained the list of C# identifiers)


 Unfortunately you cannot use `in` as part of the id.
 I would suggest `inleegan.helloworld` or drop the `in` completely.


It may also be possible to use in_.leegan.helloworld, which would be the
traditional Java workaround, if 'in' was reserved there.



 My team is hiring!
 @purplecabbage
 risingj.com

 On Mon, Aug 17, 2015 at 5:32 AM, Ian Clelland iclell...@chromium.org
 wrote:

  in is not a reserved keyword Java, but it is in C# -- are you building
 a
  Windows Phone or Windows application?
 
  It looks like Jesse's https://www.npmjs.com/package/valid-identifier
  package is catching this.
 
  On Sat, Aug 15, 2015 at 12:57 AM, heman...@leegan.in wrote:
 
   Dear Sir,
  
  
  
   I would like to use .IN domain in the APP ID while building the
 Cordova
   application.
  
   Whenever I try to use
  
  
  
   cordova create hello in.leegan.helloworld HelloWorld
  
   it says:
  
   App id contains a reserved word, or is not a valid
   identifier
  
  
  
   It seems to be that in.leegan.helloworld is not valid.
  
  
  
   How can I overcome this limitation ?
  
  
  
   Regards,
  
   Hemant Ganpule
  
   LEEGAN SOFTWARES
  
   Thane, India
  
  
  
  
  
  
 

Re: [iOS] proposed major whitelist change

[Ian Clelland]

+1 to CSP as the right way to do it.

This all sounds very similar to what we ended up doing with the Android
whitelist plugins: Default is (ugh) *, and the strong recommendation is to
use CSP to actually filter requests from the WebView.

On Mon, Jul 20, 2015 at 7:24 PM, Shazron shaz...@gmail.com wrote:

 Ah I forgot about the legacy whitelist plugin -- we can't remove the
 whitelist totally then, but as you said default
 the new whitelist plugin to a 'wildcard' network request list until the
 user adds any entries.

 That will preserve backwards compat.

 On Mon, Jul 20, 2015 at 4:18 PM, Treggiari, Leo leo.treggi...@intel.com
 wrote:

  I assume this is for the new whitelist plugin as opposed to the legacy
  whitelist plugin which will continue to use the current access tags.
 
  Another alternative, but not necessarily better, would be to default
  the new whitelist plugin to a 'wildcard' network request list until the
  user adds any entries.  When they add an entry the default wildcard
  entry is replaced.
 
  Leo
 
  -Original Message-
  From: Shazron [mailto:shaz...@gmail.com]
  Sent: Monday, July 20, 2015 3:45 PM
  To: dev@cordova.apache.org
  Subject: Re: [iOS] proposed major whitelist change
 
  1. If a user is using CSP can we tell them to specify a single '*' entry
  for the network request whitelist (a.k.a. access tags)?
  We could. But comes back to my point, why recommend *two* ways, it's just
  confusing -- especially if we recommend CSP and require an access
  wildcard. What I'm proposing is a permanent, unchangeable access wildcard
  effectively.
 
  2. If they are not using CSP,  in spite of our recommendation, do the
  access tags provide an alternative, though inferior solution?
  Yes, access is definitely inferior.
 
 
  On Mon, Jul 20, 2015 at 3:36 PM, Treggiari, Leo leo.treggi...@intel.com
 
  wrote:
 
   I'm not certain that this makes sense, but anyway...
  
   If a user is using CSP can we tell them to specify a single '*' entry
 for
   the network request whitelist (a.k.a. access tags)?
   If they are not using CSP,  in spite of our recommendation, do the
   access tags provide an alternative, though inferior solution?
  
   And, is this different for the Android platform which already supports
  the
   new whitelist plugin?
  
   Thanks,
   Leo
  
   -Original Message-
   From: Shazron [mailto:shaz...@gmail.com]
   Sent: Monday, July 20, 2015 3:24 PM
   To: dev@cordova.apache.org
   Subject: [iOS] proposed major whitelist change
  
   https://github.com/apache/cordova-plugin-whitelist
  
   Previously, the initial implementation for the plugin for iOS didn't
   support the access tag, but that proved problematic since not
  supporting
   it meant all *native* code network connections were effectively
   blacklisted.
  
   I added the support back in, but this will end up confusing the user
 even
   more. Right now we are recommending that the user support CSP, but that
   only works in the context of the WebView (whether UIWebView or
  WKWebView) -
   ie xhr, images, etc.
  
   If the user specified a CSP src for access to a domain in their .html,
  but
   did not specify an access tag for that domain, the connection will
 fail
   (since the native code whitelist filters all network connections). So
  this
   in effect doubles the number of declarations needed -- a CSP policy
 needs
   to have its mirror in the access tag. You can see where this can get
   confusing.
  
   We could have a dynamic CSP parser in native code to dynamically
  generate
   access tags but that will add on more complexity (but this would be
 best
   workaround).
  
   I propose that we get rid of the native code whitelist (effectively
   allowing all connections)  and rely on CSP only. I'm not sure that
  having a
   native code whitelist can really be truly secure, with the dynamic
 nature
   of Objective-C this is just a façade anyway.
  
   In any case, native code whitelisting will only work on UIWebView,
 there
  is
   no way our current whitelisting system will work on WKWebView at all --
   more fodder for us to abandon our whitelisting system.
  
   The whitelisting should really be handled lower level by the system,
 and
   indeed this is coming in iOS 9 with Application Transport Security
 (ATS):
  
  
 
 https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/index.html#//apple_ref/doc/uid/TP40016240
  
   The ATS whitelisting is through new tags in Info.plist, and we will
 have
  to
   map our existing whitelist tags to ATS when the time comes.
  
 

Re: Sticky Channels

[Ian Clelland]

On Tue, Jun 9, 2015 at 7:10 PM, Brian LeRoux b...@brian.io wrote:

 big -1 on promises from me; they've only been a pain for us thus far (ask
 steve about the plugman debugging


I certainly wasn't actually proposing that we revive that debate :) Just
pointing out that I feel like the promises/futures/deferreds model is
closer to what we're trying to accomplish with sticky channels than the DOM
event model is.



 maybe when they're native. mybe.


And even then, we'd probably want to wait for dev tools catch up. I
understand how much of a pain they can be to debug.


 On Tue, Jun 9, 2015 at 7:27 AM, Ian Clelland iclell...@chromium.org
 wrote:

  On Tue, Jun 9, 2015 at 10:19 AM, Andrew Grieve agri...@chromium.org
  wrote:
 
   I think the only place sticky channels are used is for startup events
   (deviceready, nativeready, pluginsready, etc). I think you could
 probably
   change them to fire multiple times without breaking too much, but the
   semantics of that seem really strange to me (fire the most recent
 event,
  or
   all events? upon registering, but only to the newly added listener(s))
  
   They are not based on any standard, so it might be nice not to use
 them,
   and instead use standard events (e.g. cordova.fireWindowEvent). As long
  as
   we promise not to fire them until after deviceready, apps should be
 able
  to
   register listeners reliably.
  
 
  This was an area that I was hoping to leverage to use promises instead,
  back when we were discussing baking those into cordova.js -- it would be
 a
  major change from the existing way of doing things, but sticky channels
 are
  closer in spirit to promises than they are to events, I think.
 
  It's very similar to the service worker `ready` attribute -- before the
  worker is active, it returns a promise that asynchronously waits for
  everything to be ready, and then fires. After the worker is already
 active,
  the promise resolves immediately, just like deviceready does if you
 attach
  a listener after Cordova has initialized.
 
 
  
   One other data point for this is that I dealt with the as-a-service vs.
   as-a-launch in
   https://github.com/MobileChromeApps/cordova-plugin-background-app. In
  this
   model, I set a property before each resume / deviceready that can be
   queried to find out the app's state. Could possibly do similar for
  intents
   (but would need an event as well since they can come at any time, not
  just
   on start-up)
  
   On Fri, Jun 5, 2015 at 7:18 PM, Jesse purplecabb...@gmail.com wrote:
  
I have been looking into unifying launchParameters across devices so
  that
all cordova apps can get some context of how they were
   launched/activated.
This includes everything from a url/protocol launch in another app,
 to
  a
touch on a notification (toast,local,push,... )
   
My intent was to add a channel for this, however I have had some
 issues
with channels + stickiness.
   
I wanted a channel that would call new subscribers immediately if it
  had
already fired.  In our channel implementation this is what we call a
   sticky
channel.  However, this particular channel may fire more than once,
 ie.
   we
could be activated multiple times while running, or receive multiple
notifications.
The current implementation for sticky will only ever call subscribers
   once,
and if I call fire() more than once, it actually removes it's
   subscribers.
[1] So I cannot use this as is for my needs.
   
So my questions are :
1. Why is like this? Is there some standard or expectation that this
 is
based on?
2. Can I change it? What would be the impact of changing the behavior
  to
have a sticky channel fire more than once, and keep its list of
subscribers?
3. Are there historical reasons that things are the way they are? The
   code
has been through several major moves since it was written, so it is
difficult to pin the original commit (Fil, Andrew? some merged pr?)
 If
there are historical reasons, are they still relevant?
   
Please keep in mind too that I am not asking for the solution to my
specific task, I can work around anything ... I am asking solely
 about
   the
current channel-sticky implementation and it we should change it.
   
Cheers,
  Jesse
   
   
The current implementation
[1]
   
  
 
 https://github.com/apache/cordova-js/blob/master/src/common/channel.js#L216
   
   
@purplecabbage
risingj.com
   
  
 

Re: Sticky Channels

[Ian Clelland]

On Tue, Jun 9, 2015 at 10:19 AM, Andrew Grieve agri...@chromium.org wrote:

 I think the only place sticky channels are used is for startup events
 (deviceready, nativeready, pluginsready, etc). I think you could probably
 change them to fire multiple times without breaking too much, but the
 semantics of that seem really strange to me (fire the most recent event, or
 all events? upon registering, but only to the newly added listener(s))

 They are not based on any standard, so it might be nice not to use them,
 and instead use standard events (e.g. cordova.fireWindowEvent). As long as
 we promise not to fire them until after deviceready, apps should be able to
 register listeners reliably.


This was an area that I was hoping to leverage to use promises instead,
back when we were discussing baking those into cordova.js -- it would be a
major change from the existing way of doing things, but sticky channels are
closer in spirit to promises than they are to events, I think.

It's very similar to the service worker `ready` attribute -- before the
worker is active, it returns a promise that asynchronously waits for
everything to be ready, and then fires. After the worker is already active,
the promise resolves immediately, just like deviceready does if you attach
a listener after Cordova has initialized.



 One other data point for this is that I dealt with the as-a-service vs.
 as-a-launch in
 https://github.com/MobileChromeApps/cordova-plugin-background-app. In this
 model, I set a property before each resume / deviceready that can be
 queried to find out the app's state. Could possibly do similar for intents
 (but would need an event as well since they can come at any time, not just
 on start-up)

 On Fri, Jun 5, 2015 at 7:18 PM, Jesse purplecabb...@gmail.com wrote:

  I have been looking into unifying launchParameters across devices so that
  all cordova apps can get some context of how they were
 launched/activated.
  This includes everything from a url/protocol launch in another app, to a
  touch on a notification (toast,local,push,... )
 
  My intent was to add a channel for this, however I have had some issues
  with channels + stickiness.
 
  I wanted a channel that would call new subscribers immediately if it had
  already fired.  In our channel implementation this is what we call a
 sticky
  channel.  However, this particular channel may fire more than once, ie.
 we
  could be activated multiple times while running, or receive multiple
  notifications.
  The current implementation for sticky will only ever call subscribers
 once,
  and if I call fire() more than once, it actually removes it's
 subscribers.
  [1] So I cannot use this as is for my needs.
 
  So my questions are :
  1. Why is like this? Is there some standard or expectation that this is
  based on?
  2. Can I change it? What would be the impact of changing the behavior to
  have a sticky channel fire more than once, and keep its list of
  subscribers?
  3. Are there historical reasons that things are the way they are? The
 code
  has been through several major moves since it was written, so it is
  difficult to pin the original commit (Fil, Andrew? some merged pr?)  If
  there are historical reasons, are they still relevant?
 
  Please keep in mind too that I am not asking for the solution to my
  specific task, I can work around anything ... I am asking solely about
 the
  current channel-sticky implementation and it we should change it.
 
  Cheers,
Jesse
 
 
  The current implementation
  [1]
 
 https://github.com/apache/cordova-js/blob/master/src/common/channel.js#L216
 
 
  @purplecabbage
  risingj.com
 

Cordova Service Worker plugin

[Ian Clelland]

It's a bit late for an announcement, since we actually published this a
couple of weeks ago, but Google's Cordova team has built a Service Worker
plugin for iOS Cordova apps.

It's npm-published exclusively, so you can finally install this without
cloning the repo, so maybe that makes this a good time to publicize it ;)

This means that you can use all of the Service Worker APIs (Cache, Fetch,
etc) that you would use to make an offline web app -- including updating
your app assets from the network -- and build a Cordova app the same way.

The plugin is an extendable platform, as well, so we hope to publish some
other APIs on top of it (geofencing, push, background sync) fairly soon.

https://www.npmjs.com/package/cordova-plugin-service-worker

Re: Cordova Service Worker plugin

[Ian Clelland]

For the most part, this allows developers who are already using Service
Worker to create offline-enabled web apps to use the same code, and the
same coding style, with Cordova apps.

Service Worker is currently available only in Chrome (and Opera, by its
Blink heritage), but as a W3C effort, I'm hoping that it will gain momentum
on the web as a far better method of handling the offline state than, say,
AppCache. I'd love to see developers start to think of this as the right
way to handle offline apps, and it's only a short step from there to using
the same techniques for hybrid apps.

(And hopefully, as support grows within the various platform webviews, a
plugin like this can shrink until eventually Cordova apps can just *use*
the native implementation)


On Mon, Apr 27, 2015 at 10:17 AM, Raymond Camden raymondcam...@gmail.com
wrote:

 Can you comment as to why you would use this as opposed to the network API?

 On Mon, Apr 27, 2015 at 7:20 AM, Ian Clelland iclell...@chromium.org
 wrote:
  It's a bit late for an announcement, since we actually published this a
  couple of weeks ago, but Google's Cordova team has built a Service Worker
  plugin for iOS Cordova apps.
 
  It's npm-published exclusively, so you can finally install this without
  cloning the repo, so maybe that makes this a good time to publicize it ;)
 
  This means that you can use all of the Service Worker APIs (Cache, Fetch,
  etc) that you would use to make an offline web app -- including updating
  your app assets from the network -- and build a Cordova app the same way.
 
  The plugin is an extendable platform, as well, so we hope to publish some
  other APIs on top of it (geofencing, push, background sync) fairly soon.
 
  https://www.npmjs.com/package/cordova-plugin-service-worker



 --
 ===
 Raymond Camden, Developer Advocate for MobileFirst at IBM

 Email : raymondcam...@gmail.com
 Blog : www.raymondcamden.com
 Twitter: raymondcamden

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

Re: [Vote] Tools Release

[Ian Clelland]

+1

Verified signatures and hashes
Verified tarball contents against public repository
Created and ran iOS (3.8.0) and Android (4.0.0) applications.

On Fri, Apr 17, 2015 at 11:43 AM, Parashuram N (MS OPEN TECH) 
panar...@microsoft.com wrote:

 Voting +1


 * Verified signatures and hashes
 * Verified tags
 * Ability to install/uninstall Cordova
 * Ability to update Cordova
 * Ability to create blank app for Windows, WP8, Android
 * Ability to run apps
 * Reviewed release notes




 On 4/16/15, 1:24 PM, Steven Gill stevengil...@gmail.com wrote:

 Please review and vote on this Tools Release
 by replying to this email (and keep discussion on the DISCUSS thread)
 
 Release issue: https://issues.apache.org/jira/browse/CB-8859
 
 Tools have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8859/
 
 I have also uploaded these packages to npm under the rc tag for
 testing purposes.
 Test with npm install -g cordova@rc
 
 The packages were published from their corresponding git tags:
 
 cordova-js: 3.9.0 (17a3450e15)
 cordova-lib: 5.0.0 (cbd2a1e98d)
 cordova-plugman: 0.23.1 (8b9a73f6d4)
 cordova-cli: 5.0.0 (6c21fa85d0)
 
 Upon a successful vote I will upload the archives to dist/, publish
 them to NPM, and post the corresponding blog post.
 
 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
 Voting will go on for a minimum of 48 hours.
 
 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and
 subdependencies have Apache-compatible licenses
 * Ran tests and built a hello world project, added a plugin. Ran mobile
 spec


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

Re: [Vote] 4.0.0 Android Release

[Ian Clelland]

+1

Verified package integrity against signatures, checksums and public repo at
the same commit.
Successfully built and ran mobilespec.

Re: Android 4.0 Blog Post

[Ian Clelland]

On Wed, Apr 15, 2015 at 1:47 PM, Treggiari, Leo leo.treggi...@intel.com
wrote:

 If anyone has the time to educate me, then please pardon my ignorance.

 Then you're suggesting that if I'm writing a cross-platform app, I stick
 with
 the legacy whitelist plugin until all of the platforms I care about support
 new whitelisting?  Or they already do support the new whitelisting?


Most platforms *do not* support the new whitelisting. As of right now, it's
Android 4.0.0, and iOS (4.0.x development branch).

If you're building a cross-platform app, there are a couple of options, but
they all come down to the fact that you need to use the old syntax for any
platforms other than Android.


1. Install the legacy plugin, and use the same syntax for everything
(easiest)

2. Install the new whitelist plugin, and have separate config.xml files for
each platform. This may or may not be feasible, depending on your build
system. You'll probably have to swap the config file out between builds of
different platforms (I can't remember off-hand if there's any syntax in
config.xml to have platform-dependent sections, but that would make this
easier.)

3. Install the new whitelist plugin, and use *both* syntaxes in config.xml.
The new plugin uses access tags for network requests, but not for
navigation, so you'd have to include allow-navigation tags as well, if
you have more than a single-page-app. You can include both kinds of tags,
though, and the platforms will happily just pick out the ones they
understand.


 Thanks,
 Leo

 -Original Message-
 From: Joe Bowser [mailto:bows...@gmail.com]
 Sent: Wednesday, April 15, 2015 10:42 AM
 To: dev@cordova.apache.org
 Subject: Re: Android 4.0 Blog Post

 Isn't this why the Legacy Whitelist plugin exists?

 On Wed, Apr 15, 2015 at 10:40 AM Treggiari, Leo leo.treggi...@intel.com
 wrote:

  I have a question.  With the new whitelist support in Android, does that
  mean if I'm writing a cross-platform app, do I need to deal with
  whitelisting differently in Android and other platforms (at least until
 the
  other platforms 'catch up')?  If not, thanks.  If so, what would be the
  best way to handle the differences - perhaps using the merges
 functionality?
 
  Thanks,
  Leo
 
  -Original Message-
  From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
  Grieve
  Sent: Wednesday, April 15, 2015 10:18 AM
  To: dev
  Subject: Android 4.0 Blog Post
 
  The 4.0 release is posted to npm, and I've updated the blog post to work
  without the need for a tools release:
 
  I'd like to publish the blog post without waiting for a CLI release:
  - I've updated the post to use plugins-from-git so it works without new
 CLI
  - I've mentioned those can just wait for tools if they like
  - This should give us some early adopter feedback in case there's a need
  for a 4.0.1
 
 
 
 https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md
 
  Any objections?
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 

Re: proposal for cordova cli

[Ian Clelland]

This is a general issue with command line tools, but can be solved in a
consistent way. I'll usually do something like this:

cordova build android  date

As output, I see:

...
BUILD SUCCESSFUL

Total time: 31.314 secs
Built the following apk(s):

/Users/iclelland/test/platforms/android/build/outputs/apk/android-debug.apk
Wed Apr 15 16:33:30 EDT 2015

Does that work for you?


On Wed, Apr 15, 2015 at 4:21 PM, Willy Aguirre marti1...@gmail.com wrote:

 I have:
 cordova -version
 4.2.0

 I am working with android platform but I need to know when it built
 {12:39:44 - }

 2015-04-15 15:12 GMT-05:00 Michal Mocny mmo...@chromium.org:

  ..we already have this?
 
   cordova build android
  ...
  BUILD SUCCESSFUL
  Total time: 6 seconds
  Built the following apk(s):
 
 
  Perhaps some platforms don't?  Perhaps older build scripts don't?
 
  -Michal
 
  On Wed, Apr 15, 2015 at 3:53 PM, Willy Aguirre marti1...@gmail.com
  wrote:
 
   Hi, I would like to add time after build
  
   BUILD SUCCESSFUL
   12:39:44 - Total time: 17 seconds
  
   Built the following apk(s):
  
   Regards!
  
   --
   Willy Aguirre | @willrre
   Blog: http://osgux.tumblr.com/
   Mozilla Rep: https://reps.mozilla.org/u/Willy/
   Mozilla Hispano - Willyaguirre
   https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre
  
 



 --
 Willy Aguirre | @willrre
 Blog: http://osgux.tumblr.com/
 Mozilla Rep: https://reps.mozilla.org/u/Willy/
 Mozilla Hispano - Willyaguirre
 https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre

Re: [Vote] 4.0.0 Android Release

[Ian Clelland]

On Thu, Apr 9, 2015 at 1:26 PM, Treggiari, Leo leo.treggi...@intel.com
wrote:

 Do the whitelist changes mean that current access origin entries in a
 config.xml file will be ignored the next time that a developer builds
 their project?  If so, that will certainly surprise some developers.


Yes, but it only surprises developers who:
  - Blindly update just their cordova-android platform to a new major
release, and
  - Don't read any of the docs or release notes.

The solution for them is simple, and loudly spelled out in the docs (or it
should be) -- install the legacy whitelist plugin. It treats the config
tags exactly as previous versions of Cordova did.


 Or does this just impact newly created projects?


Newly-created projects actually shouldn't see this -- by default, the
hello-world starter template includes the new whitelist plugin.

 Ian


 Thanks,
 Leo

 -Original Message-
 From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
 Mocny
 Sent: Thursday, April 09, 2015 9:54 AM
 To: dev
 Subject: Re: [Vote] 4.0.0 Android Release

 PR for Blogpost changes, hopefully making it a bit more obvious what the
 whitelist changes are:
 https://github.com/cordova/apache-blog-posts/pull/35

 Possibly we want to link to a more in-depth guide and remove some of my
 notes (i.e. specifically what needs adding, which config.xml should look
 like).

 Question: some of the plugin links are to github, some to npm.  Should we
 document how to add these plugins using the new npm plugin name format?

 On Thu, Apr 9, 2015 at 12:15 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Please review and vote on this 4.0.0 Android Release.
 
  Release issue: https://issues.apache.org/jira/browse/CB-8833
 
  Repos ready to be released have been published to dist/dev:
  https://dist.apache.org/repos/dist/dev/cordova/CB-8833
 
  The package was published from its corresponding git tag:
  cordova-android: 4.0.0 (f224b1f2d4)
 
  Note that you can test it out via:
 
  cordova platform add https://github.com/apache/cordova-android#4.0.0
 
  Blog post to review is here:
 
 
 
 
 https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md
 
  Upon a successful vote I will upload the archive to dist/, publish it to
  NPM, and post the corresponding blog post.
 
  Voting guidelines:
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 48 hours.
 
  I vote +1:
  * Ran coho audit-license-headers over the relevant repos
  * Ran coho check-license to ensure all dependencies and subdependencies
  have Apache-compatible licenses
  * Ran mobilespec and only expected failures were happening
  * Verified contents of archive
 

Re: Camera: When was Crop added and why?

[Ian Clelland]

   On Tue, Mar 31, 2015 at 10:38 AM, Joe Bowser bows...@gmail.com
 wrote:
Hey
   
I'm working on Camera plugin issues in JIRA, and I noticed that
we
  added
Crop to the Camera plugin.  I'm wondering when this was done, and
  where
   the
JIRA issue or discussion of adding this feature took place.  I'm
  pretty
sure this feature wasn't added properly to Android, since it
 seems to
interrupt how the camera works pretty substantially.
   
Can anyone direct me to where any of this took place so that I
can
  read
   the
justification as to why we added it?  If it doesn't exist, I'm
  probably
going to create a JIRA issue for putting it in properly, since
I'm
  sure
some users are expecting it.
   
Joe

A little bit of git-blame work brings up this JIRA issue:
https://issues.apache.org/jira/browse/CB-6546

Which is tied to this GitHub pull request from an outside contributor:
https://github.com/apache/cordova-plugin-camera/pull/12

from just over a year ago.

It looks like it was merged in on April 29 last year, and first released
with 0.3.0 (June 2014).

On Tue, Mar 31, 2015 at 6:58 PM, Joe Bowser bows...@gmail.com wrote:

 OK, so here's the problem with allowEdit/Crop on Android as it's currently
 implemented:

 1. The results aren't handled correctly when using handleCrop and
 saveImageToGallery
 2. The cropped image isn't saved to the gallery when we're saving the image
 3. I have no idea where the resizing should happen when we're allowing the
 edit, currently it happens BEFORE Crop, which I don't think is right.
 4. Saving the image to the gallery happens BEFORE the Crop, which seems
 like the incorrect behaviour

 Since this code is really old, I'm thinking that we're stuck with it since
 it'll probably be as much work to rip the damn thing out as it would be to
 fix it, but I'm not sure what fixed even means in this context since I
 didn't even really know this feature existed until today when I decided to
 adopt a bunch of Camera bugs and try to reproduce and fix them.  I was
 hoping that we had these conversations before cramming this feature into
 Cordova, but apparently we haven't.

 There's also the fact that Crop makes this plugin handle three different
 types of intents, which I'm not super happy about, especially since I have
 no idea what happens to the Exif when it goes into the Crop Intent and when
 it comes out.

 Then there's the fact that this feature was an API change that broke
 semver.  Does anyone know how semver works for plugins? Does each plugin's
 version need to be updated if we muck about with the API? Would our users
 notice if we did that? I'm hoping they would, but I'm not sure.

 On Tue, Mar 31, 2015 at 2:24 PM Raymond Camden raymondcam...@gmail.com
 wrote:

  Oh sorry - your last paragraph makes it clear that it is a doc issue
  w/ Android then. (Possibly anyway.)
 
  On Tue, Mar 31, 2015 at 4:22 PM, Raymond Camden raymondcam...@gmail.com
 
  wrote:
   I'm confused. The docs say allowEdit is ignored for Android (and every
   other platform but iOS I believe). Are you saying allowEdit does
   something for Android?
  
   On Tue, Mar 31, 2015 at 4:15 PM, Jesse purplecabb...@gmail.com
 wrote:
   To be correct, it is not disabled anywhere, it was previously
  implemented
   for iOS only.
   The iOS native camera/capture view has an additional boolean property
 to
   allow the user to crop+pan a photo in place before returning to the
 app.
   This was exposed in the cordova camera api on iOS only. In like 2011.
  
   More recently ( last year [1] ) the same feature landed in Android,
   however, it is not exactly the same thing.
   On Android, there is no guarantee that the Crop-Intent exists, in
 which
   case it doesn't matter if the cordova-camera getPicture method was
  called
   with allowEdit or not.  Also, on some devices, there are multiple apps
   providing a Crop-Intent, so the user will have to choose one.
  
   There are tests for it, but of course, they are manual ...
   Should we update the docs and claim Android support for it, or does it
  have
   usability/implementation issues that make us not want it?
  
  
   [1] https://github.com/apache/cordova-plugin-camera/pull/12
  
  
  
  
  
   @purplecabbage
   risingj.com
  
   On Tue, Mar 31, 2015 at 1:56 PM, Raymond Camden 
  raymondcam...@gmail.com
   wrote:
  
   From what I could see, every platform - but iOS - has it disabled.
   (imo, when a feature is ONE platform only, it should really be called
   out earlier in the docs.) Going to make a demo now cuz I want to see
   too.
  
   On Tue, Mar 31, 2015 at 3:06 PM, Joe Bowser bows...@gmail.com
 wrote:
What does allowEdit do? Does it crop across devices? The problem is
  that
this is super vague and doesn't make any sense. Edit can mean
  anything
   from
a file permission to Open Photoshop Mobile.  If there's a thread
  where
   we
decided on it, that'd be cool, but right now it smells like an
   

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Ian Clelland]

+1

* Verified package contents against public repo at the correct tags
* Verified checksums and signatures
* Built and verified functionality on android (4.0.0-dev/0669edd) and ios
(no functionality, no issues either)

On Tue, Mar 31, 2015 at 1:10 AM, Steven Gill stevengil...@gmail.com wrote:

 I like the sound of both ideas.

 Marks idea to make the default hello world app not install whitelist until
 android 4.0 (use 3.8.0 for app hello world)

 Ian, that looks like a good proposal. We are definitely overdo for
 something to properly track versions. Users should get a warning when a
 plugin doesn't get installed due to version issues.

 -Steve
 On Mar 30, 2015 6:18 PM, Andrew Grieve agri...@chromium.org wrote:

  Mark - I like that idea as well.
 
  On Mon, Mar 30, 2015 at 6:33 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   On 30 Mar 2015 4:52 pm, Mark Koudritsky kam...@google.com wrote:
   
Another quick option for now: we can pin hello-world version in
cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
plugin.  Later, when we release the tools pinned to cordova-android
 4.0
   we
will have to change the hello-world dep to ^3.9.0.
  
   That's a good idea.
  
   I'll validate the plug-ins and vote later tonight.
  
   Ian
This way it's a minimal change to cordova-lib and we can go ahead
 with
   this
vote.
   
On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland 
 iclell...@chromium.org
wrote:
   
 So this isn't a -1, unless we can't fix the problem in cordova-lib.
  And
 it's okay, I think, to fix it in cordova-lib/master and release
 that
  as
 well. Nothing is actually broken by publishing either
 app-hello-world
   or
 plugin-whitelist until we release a version of tools that is pinned
  to
   the
 new hello-world.


 On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky 
 kam...@google.com
 wrote:

  Looks like this breaks on cordova-android 3.7.1 (currently latest
 released)
 
  cordova-app-hello-world requires the whitelist plugin
  whitelist plugin depends on cordova-android 4.0 via the engine
 tag
  engine name=cordova-android version==4.0.0-dev /
  The resulting error message is
  Plugin doesn't support this project's cordova-android version.
  cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
 
  Simply removing the engine tag results in compile errors.
 (change
  in CustomConfigXmlParser.parse() signature).
 
  Any ideas on how to solve this would be appreciated. Ideas we
 came
  up
 with
  in a quick discussion:
 
  1. Add ignore attribute to the engine tag that would result
 in
   plugin
  being silently ignored for incompatible engines rather than going
   down in
  flames.
  2. Add either version child or version attribute to the
   platform
 tag
  in plugin.xml
 

 This is my favorite idea so far -- I think we could do something
 like
   this:
 plugin ... 
   platform name=android
 version match==4.0.0
   !-- tags --
 /version
   /platform
 /plugin

 I think this is overdue, and we'll find it useful as we move from
 3.x
   to
 4.x on other platforms as well. We would allow multiple version
  tags
 inside of each platform, and any tags outside of the version
 tags
   are
 the default if nothing matches.

 In this case, there won't be any tags outside of the version tag,
  so
   the
 fallback for 3.x is to install nothing, but succeed.

 Ian


 
  On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve 
  agri...@chromium.org
   
  wrote:
 
   +1
  
   * Tested that both plugins compile on Android
   * Tested that the non-legacy plugin does what its supposed to
 on
 Android
  
   On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill 
   stevengil...@gmail.com
   
   wrote:
  
Please review and vote on the releases of
   cordova-plugin-whitelist
 and
cordova-plugin-legacy-whitelist plugins.
   
Release issue: https://issues.apache.org/jira/browse/CB-8739
   
The plugins have been published to
dist/dev:
  https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
   
The packages were published from their corresponding git
 tags:
cordova-plugin-whitelist: 1.0.0
(38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0
 (1ce26eba64)
   
Upon a successful vote I will upload the archives to dist/
 and
   upload
them to npm.
   
Voting guidelines:
   
  
 

  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
   
Voting will go on for a minimum of 48 hours.
   
I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Ian Clelland]

My thinking was that some plugins are going to need to have two very
different designs, say for cordova-android 3.7.0 vs 4.0.0, or cordova-ios
3.8.0 vs 4.0.0. In that case, you could do something like this;

platform name=ios
  version match==4.0.0
!-- tags for the new version --
  /version
  version match=4.0.0
!-- tags for the backwards-compatiblity version --
  /version
/platform

which i don't think you could do with the engine tags -- with engine
either all of the platform files are installed, or none of them are.

Another way to do this would be to allow multiple versions to be available
on the CPR or on npm, and have logic to decide the best version of the
plugin to install. (with the ability to successfully install nothing if
that's the right choice)

On Tue, Mar 31, 2015 at 1:17 PM, Steven Gill stevengil...@gmail.com wrote:

 Ian, instead of adding a version tag in plugin.xml, why don't we use the
 engine tag in plugins package.json?

 Something like:

 {
   engines : {
 cordova-android : 4.0.0,
 cordova-ios : =3.0.0 4.0
   }
 }


 If the user doesn't have the specified platform versions installed, user
 gets a warning and plugin doesn't install. If no engine is specified,
 install away.

 Thoughts?

 On Mon, Mar 30, 2015 at 12:49 PM, Ian Clelland iclell...@chromium.org
 wrote:

  So this isn't a -1, unless we can't fix the problem in cordova-lib. And
  it's okay, I think, to fix it in cordova-lib/master and release that as
  well. Nothing is actually broken by publishing either app-hello-world or
  plugin-whitelist until we release a version of tools that is pinned to
 the
  new hello-world.
 
 
  On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com
  wrote:
 
   Looks like this breaks on cordova-android 3.7.1 (currently latest
  released)
  
   cordova-app-hello-world requires the whitelist plugin
   whitelist plugin depends on cordova-android 4.0 via the engine tag
   engine name=cordova-android version==4.0.0-dev /
   The resulting error message is
   Plugin doesn't support this project's cordova-android version.
   cordova-android: 3.7.1, failed version requirement: =4.0.0-dev
  
   Simply removing the engine tag results in compile errors. (change
   in CustomConfigXmlParser.parse() signature).
  
   Any ideas on how to solve this would be appreciated. Ideas we came up
  with
   in a quick discussion:
  
   1. Add ignore attribute to the engine tag that would result in
 plugin
   being silently ignored for incompatible engines rather than going down
 in
   flames.
   2. Add either version child or version attribute to the platform
  tag
   in plugin.xml
  
 
  This is my favorite idea so far -- I think we could do something like
 this:
  plugin ... 
platform name=android
  version match==4.0.0
!-- tags --
  /version
/platform
  /plugin
 
  I think this is overdue, and we'll find it useful as we move from 3.x to
  4.x on other platforms as well. We would allow multiple version tags
  inside of each platform, and any tags outside of the version tags are
  the default if nothing matches.
 
  In this case, there won't be any tags outside of the version tag, so
 the
  fallback for 3.x is to install nothing, but succeed.
 
  Ian
 
 
  
   On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve agri...@chromium.org
   wrote:
  
+1
   
* Tested that both plugins compile on Android
* Tested that the non-legacy plugin does what its supposed to on
  Android
   
On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill stevengil...@gmail.com
 
wrote:
   
 Please review and vote on the releases of cordova-plugin-whitelist
  and
 cordova-plugin-legacy-whitelist plugins.

 Release issue: https://issues.apache.org/jira/browse/CB-8739

 The plugins have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/

 The packages were published from their corresponding git tags:
 cordova-plugin-whitelist: 1.0.0
 (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)

 Upon a successful vote I will upload the archives to dist/ and
 upload
 them to npm.

 Voting guidelines:

   
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and
 subdependencies have Apache-compatible licenses

   
  
 

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[Ian Clelland]

So this isn't a -1, unless we can't fix the problem in cordova-lib. And
it's okay, I think, to fix it in cordova-lib/master and release that as
well. Nothing is actually broken by publishing either app-hello-world or
plugin-whitelist until we release a version of tools that is pinned to the
new hello-world.


On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky kam...@google.com wrote:

 Looks like this breaks on cordova-android 3.7.1 (currently latest released)

 cordova-app-hello-world requires the whitelist plugin
 whitelist plugin depends on cordova-android 4.0 via the engine tag
 engine name=cordova-android version==4.0.0-dev /
 The resulting error message is
 Plugin doesn't support this project's cordova-android version.
 cordova-android: 3.7.1, failed version requirement: =4.0.0-dev

 Simply removing the engine tag results in compile errors. (change
 in CustomConfigXmlParser.parse() signature).

 Any ideas on how to solve this would be appreciated. Ideas we came up with
 in a quick discussion:

 1. Add ignore attribute to the engine tag that would result in plugin
 being silently ignored for incompatible engines rather than going down in
 flames.
 2. Add either version child or version attribute to the platform tag
 in plugin.xml


This is my favorite idea so far -- I think we could do something like this:
plugin ... 
  platform name=android
version match==4.0.0
  !-- tags --
/version
  /platform
/plugin

I think this is overdue, and we'll find it useful as we move from 3.x to
4.x on other platforms as well. We would allow multiple version tags
inside of each platform, and any tags outside of the version tags are
the default if nothing matches.

In this case, there won't be any tags outside of the version tag, so the
fallback for 3.x is to install nothing, but succeed.

Ian



 On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve agri...@chromium.org
 wrote:

  +1
 
  * Tested that both plugins compile on Android
  * Tested that the non-legacy plugin does what its supposed to on Android
 
  On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
   Please review and vote on the releases of cordova-plugin-whitelist and
   cordova-plugin-legacy-whitelist plugins.
  
   Release issue: https://issues.apache.org/jira/browse/CB-8739
  
   The plugins have been published to
   dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
  
   The packages were published from their corresponding git tags:
   cordova-plugin-whitelist: 1.0.0
   (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64)
  
   Upon a successful vote I will upload the archives to dist/ and upload
   them to npm.
  
   Voting guidelines:
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
  
   Voting will go on for a minimum of 48 hours.
  
   I vote +1:
   * Ran coho audit-license-headers over the relevant repos
   * Ran coho check-license to ensure all dependencies and
   subdependencies have Apache-compatible licenses
  
 

Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release

[Ian Clelland]

Yeah :(

Hash changes, code changes, checksums and pgp signatures change... all
necessitates a new vote.
At least we get to abort early.

On Thu, Mar 26, 2015 at 1:28 PM, Parashuram N (MS OPEN TECH) 
panar...@microsoft.com wrote:

 Should we have to restart the vote thread, now that the tag will change ?

 -Original Message-
 From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
 Grieve
 Sent: Thursday, March 26, 2015 7:41 AM
 To: dev
 Subject: Re: [VOTE] Cordova-Plugin-Whitelist and
 Cordova-Plugin-Legacy-Whitelist Plugins Release

 That'd be pretty sad if it were expected :P.

 Totally my bad on this one. I've committed a fix.

 On Thu, Mar 26, 2015 at 9:40 AM, Alexander Sorokin (Akvelon) 
 v-als...@microsoft.com wrote:

  Hi guys,
 
  I am getting the following error when trying to build a project with
  legacy-whitelist plugin installed for android@4.0.0-dev:
 
 
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:44:
  error: cannot find symbol
  public void handleStartTag(XmlPullParser xml) {
 ^
symbol: class XmlPullParser
 
 C:\Projects\Cordova\mobspec-android\platforms\android\src\org\apache\cordova\whitelist\LegacyWhitelistPlugin.java:68:
  error: cannot find symbol
  public void handleEndTag(XmlPullParser xml) {
   ^
symbol: class XmlPullParser
 
 
  Is this expected?
 
  Thanks,
  Alexander Sorokin
 
  -Original Message-
  From: Steven Gill [mailto:stevengil...@gmail.com]
  Sent: Wednesday, March 25, 2015 23:23
  To: dev@cordova.apache.org
  Subject: [VOTE] Cordova-Plugin-Whitelist and
  Cordova-Plugin-Legacy-Whitelist Plugins Release
 
  Please review and vote on the releases of cordova-plugin-whitelist and
  cordova-plugin-legacy-whitelist plugins.
 
  Release issue: https://issues.apache.org/jira/browse/CB-8739
 
  The plugins have been published to
  dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/
 
  The packages were published from their corresponding git tags:
  cordova-plugin-whitelist: 1.0.0 (38f5a9fa2c)
  cordova-plugin-legacy-whitelist: 1.0.0 (b4e1b3726a)
 
  Upon a successful vote I will upload the archives to dist/ and upload
  them to npm.
 
  Voting guidelines:
  https://github.com/apache/cordova-coho/blob/master/docs/release-voting
  .md
 
  Voting will go on for a minimum of 48 hours.
 
  I vote +1:
  * Ran coho audit-license-headers over the relevant repos
  * Ran coho check-license to ensure all dependencies and
  subdependencies have Apache-compatible licenses
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

Re: crosswalk engine plugin for Cordova Android 4.0.0 release

[Ian Clelland]

Once we publish this to npm (or the Cordova plugin registry) it will be
much smaller; just containing the code that is absolutely required for the
current version.

I think that the only reasonable way to make the git repo itself smaller
would be to move it to a new location (new name or new organization).

We (Google's team) have used cordova-crosswalk-engine as a git submodule
dependency for some time, in our mobile-chrome-apps repo, and I don't think
we can just rewrite all of the old commits without also breaking all of our
historical dependencies as well. (Filtering the repo like this will rewrite
a large number of commits, which will certainly change their hashes,
unfortunately).

I'll do a bit more investigation today, but I think that the best solution,
for almost all users, is to publish just the current source as a real
cordova plugin, and not worry too much about the size of the git repo, as
it only affects people who are actively developing on it. (And the size is
no longer growing at that rate, so it is really only a one-time checkout
cost)

Ian

On Wed, Mar 25, 2015 at 1:09 AM, Hu, Ningxin ningxin...@intel.com wrote:

 
  Could this be fixed on plugman's side with git clone --depth 1?

 It still downloads 63MB.

 In my experiment, I delete all unused branches, tags, and remove related
 git objects. It can shrink the repo to 340KB with full history of master
 branch.

 There is a good reference for git repo shrinking:
 https://www.rallydev.com/community/engineering/shrinking-git-repository-move-githubcom

 Thanks,
 -ningxin

 
  On Tue, Mar 24, 2015 at 9:02 AM, Ian Clelland iclell...@chromium.org
  wrote:
 
   On Tue, Mar 24, 2015 at 6:15 AM, Hu, Ningxin ningxin...@intel.com
  wrote:
  
Crosswalk engine plugin is expected to work with upcoming Cordova
Android
4.0.0 release.
   
As I investigate, there are some issues need to be fixed:
1.  Update the README.md of cordova-crosswalk-engine. E.g no
   fetch_libs.sh
anymore. I managed to create a PR for this:
https://github.com/MobileChromeApps/cordova-crosswalk-
  engine/pull/20
   
  
Thanks, Ningxin -- that's great! I'll merge it in.
  
   2. Shrink the repo size: e.g remove unnecessary  libxwalkcore.so etc.,
   It
impacts the plugin installation performance from github.com. Please
   refer
to https://github.com/huningxin/cordova-crosswalk-engine-1. It
shrinks from 118MB to 340KB.
   
  
   I'll have to filter-repo on this; I'm not sure if there will be any
   disruption to the GitHub repository because of it, but I'll do my best
   to minimize that. I agree that it has become unnecessarily large
   because of the included (and often updated) binary packages.
  
  
   
Any other issues?
   
Thanks,
-ningxin
   
   

- 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: Cordova WP8: switching to Newtonsoft.Json

[Ian Clelland]

I'm not sure about whether Cordova has any specific policies -- there's no
hard rule that says we can't use third-party code, and even include it in
our distributions (see Cordova-Android and okhttp, for instance), but we
should probably discuss it on-list first.

There are definitely rules, policies, and guidelines at the Apache level --
no distribution of binaries, for instance, and there are probably questions
of license interaction as well between Apache and MIT licenses, if we're
combining the code at all.



On Tue, Mar 24, 2015 at 5:04 AM, Sergey Grebnov (Akvelon) 
v-seg...@microsoft.com wrote:

 This[1] PR is being opened for a while so let's make a final decision if
 we switch to Newtonsoft.Json  or reject it.

 The idea of adding Newtonsoft.Json (MIT license) [1] looks good to me and
 I can quickly add necessary improvements to make sure everything looks good
 and works - as per mobile spec tests there are no new issues found.

 But I'm not sure about our policies regarding adding new third party
 dependencies. Should it be discussed/voted here before merge? Does it
 documented somewhere?

 PS. If we go w/ Newtonsoft.Json   I propose to just add reference to
 compiled dll and not to keep source code due to size(200kb vs 19mb) and
 compile time reasons.


Distributing the .dll without the source will *definitely* be a problem.
Distributing the .dll with the source *might* be a problem. The only way
we've been able to do this in the past (see Gradle and Crosswalk for two
recent examples) is to have a script that the user runs (even as part of
the platform scripts) that downloads the library from somewhere trusted and
installs it. We can't ship binaries as part of an Apache project.



 [1] https://github.com/apache/cordova-wp8/pull/62

 Thx!
 Sergey


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

Re: [DISCUSS] Whitelist Legacy Whitelist Plugins Release @1.0.0

[Ian Clelland]

We should definitely do that -- and I think we should release them
simultaneously with cordova-app-hello-world, since it now references
cordova-plugin-whitelist by that name (I had to install it from local git
repo, but it still wasn't a perfectly smooth experience).

On Mon, Mar 23, 2015 at 7:18 PM, Steven Gill stevengil...@gmail.com wrote:

 I'd like to start a vote thread for both plugins. I'm thinking they will
 only be published to npm and dist (no CPR).

 Thoughts?

Re: [DISCUSS] Whitelist Legacy Whitelist Plugins Release @1.0.0

[Ian Clelland]

Agreed - everything looks good there.

On Tue, Mar 24, 2015 at 8:43 PM, Andrew Grieve agri...@chromium.org wrote:

 that grep looks fine to me.

 On Tue, Mar 24, 2015 at 5:13 PM, Steven Gill stevengil...@gmail.com
 wrote:

  Leo, the whitelist plugin will only start being used after the next tools
  release. So timing should be fine.
 
  Andrew, I did a quick grep search for org.apache.cordova for both
 whitelist
  plugins. Do any of these values need to be updated before releasing?
 
  cordova-plugin-whitelist
  grep -R org.apache.cordova *
  plugin.xml:param name=android-package
  value=org.apache.cordova.whitelist.WhitelistPlugin/
  plugin.xml:source-file src=src/android/WhitelistPlugin.java
  target-dir=src/org/apache/cordova/whitelist /
  src/android/WhitelistPlugin.java:package org.apache.cordova.whitelist;
  src/android/WhitelistPlugin.java:import org.apache.cordova.CordovaPlugin;
  src/android/WhitelistPlugin.java:import
 org.apache.cordova.ConfigXmlParser;
  src/android/WhitelistPlugin.java:import org.apache.cordova.Whitelist;
 
  cordova-plugin-legacy-whitelist
  grep -R org.apache.cordova *
  plugin.xml:param name=android-package
  value=org.apache.cordova.whitelist.LegacyWhitelistPlugin/
  plugin.xml:source-file
  src=src/android/LegacyWhitelistPlugin.java
  target-dir=src/org/apache/cordova/whitelist /
  src/android/LegacyWhitelistPlugin.java:package
  org.apache.cordova.whitelist;
  src/android/LegacyWhitelistPlugin.java:import
  org.apache.cordova.CordovaInterface;
  src/android/LegacyWhitelistPlugin.java:import
  org.apache.cordova.CordovaPlugin;
  src/android/LegacyWhitelistPlugin.java:import
  org.apache.cordova.CordovaWebView;
  src/android/LegacyWhitelistPlugin.java:import
  org.apache.cordova.ConfigXmlParser;
  src/android/LegacyWhitelistPlugin.java:import
 org.apache.cordova.Whitelist;
 
  On Tue, Mar 24, 2015 at 12:14 PM, Treggiari, Leo 
 leo.treggi...@intel.com
  wrote:
 
   Is there a timing issue here?  How can a plugin be published to npm
 when
   there is no tools release that will fetch from npm?
  
   Leo
  
   -Original Message-
   From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of
  Ian
   Clelland
   Sent: Tuesday, March 24, 2015 6:42 AM
   To: dev@cordova.apache.org
   Subject: Re: [DISCUSS] Whitelist  Legacy Whitelist Plugins Release
  @1.0.0
  
   We should definitely do that -- and I think we should release them
   simultaneously with cordova-app-hello-world, since it now references
   cordova-plugin-whitelist by that name (I had to install it from local
 git
   repo, but it still wasn't a perfectly smooth experience).
  
   On Mon, Mar 23, 2015 at 7:18 PM, Steven Gill stevengil...@gmail.com
   wrote:
  
I'd like to start a vote thread for both plugins. I'm thinking they
  will
only be published to npm and dist (no CPR).
   
Thoughts?
   
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
 

Re: [DISCUSS] Cordova App Hello World Release 3.9.0

[Ian Clelland]

This includes
https://github.com/apache/cordova-app-hello-world/commit/2e856b845a0134e7056bdc74f89cafcf483a379f,
right?

If so, +1 for releasing!

On Mon, Mar 23, 2015 at 1:54 PM, Steven Gill stevengil...@gmail.com wrote:

 Does anyone have any reason to delay a cordova-app-hello-world release?
 Any outstanding patches to land?

 If not, I will start the release this afternoon.

Whitelist-unplug: iOS Edition

[Ian Clelland]

I've rebased the unplug-whitelist branch against cordova-ios master, and
it's passing almost all of the mobile-spec tests, using the new whitelist
plugin. (I'll be addressing the last few very shortly)

If anyone wants to take a look and comment, either here or on CB-7747, I'd
appreciate the feedback.

Ian

Re: [DISCUSS] Cordova-Android 4.0.0 Release

[Ian Clelland]

+1 -- Let's get this out the door :)
I'll see what I can get done to move it in that direction.

On Mon, Mar 16, 2015 at 7:51 PM, Andrew Grieve agri...@chromium.org wrote:

 Everything's ready afaik (minus upgrade guide, publishing whitelist
 plugins, and making it so that the default project template includes
 plugin name=cordova-plugin-whitelist /). Maybe let's do a RC while we
 wait on these things being finished up?

 If anyone wants to take on any of these tasks, that would be awesome.

 On Mon, Mar 16, 2015 at 4:57 PM, Shazron shaz...@gmail.com wrote:

  +1 for vote thread, let's get this thing out so people (that are not
  us) can test...
 
 
  On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser bows...@gmail.com wrote:
   OK, this is a three month old thread, and we're waiting on a discussion
   before we release something? I really think we should go to a vote
 thread
   now that we have a legacy whitelist plugin and a new style whitelist
   plugin.  We shouldn't keep constantly delaying this release because of
   what's happening on other platforms, especially since we already
  pluginized
   the whitelist.
  
   Can we please release soon?
  
   On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal 
  nikhi...@microsoft.com
   wrote:
  
   I know we discussed a couple of approaches implementing the default
   whitelist policy for Android/iOS - either every app would be required
 to
   include the whitelist plugin or have it have smart defaults in the
  platform
   implementation and the plugin being able to override them.
  
   I don’t think that thread closed with any conclusions.
  
   Thanks,
   Nikhil
  
  
   -Original Message-
   From: Joe Bowser [mailto:bows...@gmail.com]
   Sent: Thursday, March 12, 2015 11:23 AM
   To: dev
   Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
  
   OK, so right now it's just docs? How soon can we get a VOTE thread
  started
   for 4.0.0?
  
   On Wed, Mar 4, 2015 at 10:47 AM Andrew Grieve agri...@chromium.org
   wrote:
  
mobilespec is now working again... Took longer than I would have
liked, but did you know that on Android FileReader triggers
shouldInterceptRequest() with Blob URLs!?
   
Separate thread is already happening re: whitelists, so once that's
figured out, it's just docs afaict.
   
On Mon, Mar 2, 2015 at 10:52 PM, Ian Clelland 
 iclell...@chromium.org
  
wrote:
   
 On Mon, Mar 2, 2015 at 6:00 PM, Jesse purplecabb...@gmail.com
  wrote:

  We should start a new whitelist plugin related thread.
 
  Why is a plugin blocking a release?  Default (aka no-plugin)
  behavior should be to allow all network requests shouldn't it?


 Well, that just might be a blacklist then :)


This thread is a
  month long, and not the first discussion of 4.0.0 for Android.
 

 Seriously, though -- the whitelist discussion is much longer than
 that,
and
 this isn't the first time that the default no-network-access
 policy
 has been brought up:

 (Here's the first question, from *July*:
 http://markmail.org/message/t4vj4saisem2mcgw
 Here's where I mentioned what the implemented policy was:
 http://markmail.org/message/s4necfnh4hnblpjm
 And in another discussion:
 http://markmail.org/message/ap7syhqysizmsvrz)

 If we want to reconsider that decision, then we should certainly
 do
 so before we cut a release. I think it would be a real problem to
 change it afterwards, so let's get it right.

 Also, it's not the plugin itself that's blocking the release, it's
 us making sure that we've implemented the core hooks correctly so
 that the plugin can actually do its job, and that people who don't
 want that particular plugin can make a better one.

 (It is also an issue that a plugin, required for cordova-android
 4.0.0, breaks apps which are also building for cordova-ios 3.8.0.
 I'll take a
look
 at that, and either remove the ios-native portions of the
 whitelist
plugin,
 or neuter it so that it doesn't interfere with an ios app if it's
 not on the unplug-whitelist branch of that repo.)

 Ian


  @purplecabbage
  risingj.com
 
  On Mon, Mar 2, 2015 at 2:02 PM, Shazron shaz...@gmail.com
  wrote:
 
   legacy-whitelist-plugin should be fixed so that it compiles on
   cordova-ios@3.8.0. It shouldn't be a problem to fix this at
   compile
or
   run-time (whichever is applicable here related to the compile
   error)
  
   On Mon, Mar 2, 2015 at 1:47 PM, Darryl Pogue
   dvpdin...@gmail.com
  wrote:
On 2 March 2015 at 13:37, Joe Bowser bows...@gmail.com
  wrote:
So, right now the whitelist changes are what's holding up
 the
4.0.0
   release
now?  Is this really the only thing that's holding up this
release?
   
On Wed Feb 25 2015 at 1:18:26 PM Andrew

Re: [DISCUSS] Cordova-Android 4.0.0 Release

[Ian Clelland]

We'll probably need at least an RC for the whitelist plugin, if not a vote,
to be able to vote on this.

Or can we just include instructions like Use
cordova-plugin-whitelist@f70b1bc for testing while we start the official
release process for the plugins?

On Mon, Mar 16, 2015 at 11:17 PM, Ian Clelland iclell...@chromium.org
wrote:

 +1 -- Let's get this out the door :)
 I'll see what I can get done to move it in that direction.

 On Mon, Mar 16, 2015 at 7:51 PM, Andrew Grieve agri...@chromium.org
 wrote:

 Everything's ready afaik (minus upgrade guide, publishing whitelist
 plugins, and making it so that the default project template includes
 plugin name=cordova-plugin-whitelist /). Maybe let's do a RC while we
 wait on these things being finished up?

 If anyone wants to take on any of these tasks, that would be awesome.

 On Mon, Mar 16, 2015 at 4:57 PM, Shazron shaz...@gmail.com wrote:

  +1 for vote thread, let's get this thing out so people (that are not
  us) can test...
 
 
  On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser bows...@gmail.com wrote:
   OK, this is a three month old thread, and we're waiting on a
 discussion
   before we release something? I really think we should go to a vote
 thread
   now that we have a legacy whitelist plugin and a new style whitelist
   plugin.  We shouldn't keep constantly delaying this release because of
   what's happening on other platforms, especially since we already
  pluginized
   the whitelist.
  
   Can we please release soon?
  
   On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal 
  nikhi...@microsoft.com
   wrote:
  
   I know we discussed a couple of approaches implementing the default
   whitelist policy for Android/iOS - either every app would be
 required to
   include the whitelist plugin or have it have smart defaults in the
  platform
   implementation and the plugin being able to override them.
  
   I don’t think that thread closed with any conclusions.
  
   Thanks,
   Nikhil
  
  
   -Original Message-
   From: Joe Bowser [mailto:bows...@gmail.com]
   Sent: Thursday, March 12, 2015 11:23 AM
   To: dev
   Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
  
   OK, so right now it's just docs? How soon can we get a VOTE thread
  started
   for 4.0.0?
  
   On Wed, Mar 4, 2015 at 10:47 AM Andrew Grieve agri...@chromium.org
   wrote:
  
mobilespec is now working again... Took longer than I would have
liked, but did you know that on Android FileReader triggers
shouldInterceptRequest() with Blob URLs!?
   
Separate thread is already happening re: whitelists, so once that's
figured out, it's just docs afaict.
   
On Mon, Mar 2, 2015 at 10:52 PM, Ian Clelland 
 iclell...@chromium.org
  
wrote:
   
 On Mon, Mar 2, 2015 at 6:00 PM, Jesse purplecabb...@gmail.com
  wrote:

  We should start a new whitelist plugin related thread.
 
  Why is a plugin blocking a release?  Default (aka no-plugin)
  behavior should be to allow all network requests shouldn't it?


 Well, that just might be a blacklist then :)


This thread is a
  month long, and not the first discussion of 4.0.0 for Android.
 

 Seriously, though -- the whitelist discussion is much longer than
 that,
and
 this isn't the first time that the default no-network-access
 policy
 has been brought up:

 (Here's the first question, from *July*:
 http://markmail.org/message/t4vj4saisem2mcgw
 Here's where I mentioned what the implemented policy was:
 http://markmail.org/message/s4necfnh4hnblpjm
 And in another discussion:
 http://markmail.org/message/ap7syhqysizmsvrz)

 If we want to reconsider that decision, then we should certainly
 do
 so before we cut a release. I think it would be a real problem to
 change it afterwards, so let's get it right.

 Also, it's not the plugin itself that's blocking the release,
 it's
 us making sure that we've implemented the core hooks correctly so
 that the plugin can actually do its job, and that people who
 don't
 want that particular plugin can make a better one.

 (It is also an issue that a plugin, required for cordova-android
 4.0.0, breaks apps which are also building for cordova-ios 3.8.0.
 I'll take a
look
 at that, and either remove the ios-native portions of the
 whitelist
plugin,
 or neuter it so that it doesn't interfere with an ios app if it's
 not on the unplug-whitelist branch of that repo.)

 Ian


  @purplecabbage
  risingj.com
 
  On Mon, Mar 2, 2015 at 2:02 PM, Shazron shaz...@gmail.com
  wrote:
 
   legacy-whitelist-plugin should be fixed so that it compiles
 on
   cordova-ios@3.8.0. It shouldn't be a problem to fix this at
   compile
or
   run-time (whichever is applicable here related to the compile
   error)
  
   On Mon, Mar 2, 2015 at 1:47 PM, Darryl Pogue

Re: Android's new Whitelist Plugins

[Ian Clelland]

On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com
wrote:

 Here are my thoughts on the default behavior:
 - navigation should be disabled.
 - XHR  network request should be enabled.


And application launch through intent URLs should also be disabled. (IMO)

That's not a bad default -- it enables CSP usage by default, which I think
is good. It also (I think) means we're giving up on suggesting that network
requests can be completely blocked by default, because that's definitely
not the case on Android.

We can implement this within the new framework: there is the idea of a
'default policy' that only comes into effect when no plugins take
responsibility for the whitelist. As soon as any plugin, though, handles
the shouldAllowRequest() call, for instance, the default policy is no
longer in effect, and it is a true whitelist (block-by-default)

My biggest concern with this is that developers are going to blindly update
to Cordova 4.0.0, and when their app *just works*, they are not going to
realize that they are actually less secure than before. (Without a plugin,
we've opened up all network access)

Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on
upgrade -- and if we see any access tag other than access origin=* we
can display a loud message, suggesting strongly that they install an
appropriate plugin.

Ian



 The plugin name is fine.

 I'm not convinced about a user having to add this plugin to enable network
 requests for Android/iOS. This default behavior should work with the
 platform and should not require a plugin. This inhibits users from getting
 the ground running on a Cordova app. It breaks existing templates in IDEs
 and other downstream CLIs as well - as all of them need to include this
 plugin to have any network access work.

 Thanks,
 Nikhil


 -Original Message-
 From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
 Mocny
 Sent: Tuesday, March 3, 2015 11:22 AM
 To: dev
 Subject: Re: Android's new Whitelist Plugins

 I've filed a JIRA issue with my thoughts on how to approach this:
 https://issues.apache.org/jira/browse/CB-8597

 On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Like your ideas a lot. Updating the project template makes a lot of
 sense.
 
  Tried to make it clear in the README, so if any part was not clear
  please fix it. But, the CSP tag is the more important bit, since
  access can't actually block all requests. The only reason to even
  leave access in there is to support pre-kitkat webviews, where no
  CSP support exists. CSP is also used to set a navigation whitelist for
  subframes, which the native side is not able to do.
 
  On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org
 wrote:
 
   My thoughts:
  
   - The split between allow-navigation, allow-intent, and access:
  Like
   it a lot.
   - I think the defaults *for the plugin* are very reasonable.
   However, we may want to provide a default set of tags for the hello
   world app.  A
  year
   or so ago we added a default access * whitelist and I think maybe we
  should
   continue that.  (on the other hand, I've gotten used to explicitly
   whitelisting every url as part of chrome packaged app development
   and its not so bad).
 - Additionally, that means this plugin should be installed by
 default.
   As we discussed this morning, with the new plugin --save
   functionality we could just add this to the helloworld config.xml, I
 think!
   - Do you really need a CSP meta tag *and* access declarations?
  Thats
   what the README.md implies, but I would assume CSP trumps?
  
   -Michal
  
   On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org
   wrote:
  
I've tried to explain it in the plugin's readme:
   
https://github.com/apache/cordova-plugins/tree/master/url-policy
   
Some points for discussion:
- What should the default behaviour be for the three whitelists
(what should happen if not whitelist plugin is installed).
  - right now it can't open external URLs
  - and can't do XHRs to http(s)
- Is the plugin name decent (url-policy). We should make a
dedicated
   git
repo for it (as well as for legacy-whitelist plugin)
   
  
 

Re: [DISCUSS] Cordova-Android 4.0.0 Release

[Ian Clelland]

On Mon, Mar 2, 2015 at 6:00 PM, Jesse purplecabb...@gmail.com wrote:

 We should start a new whitelist plugin related thread.

 Why is a plugin blocking a release?  Default (aka no-plugin) behavior
 should be to allow all network requests shouldn't it?


Well, that just might be a blacklist then :)


   This thread is a
 month long, and not the first discussion of 4.0.0 for Android.


Seriously, though -- the whitelist discussion is much longer than that, and
this isn't the first time that the default no-network-access policy has
been brought up:

(Here's the first question, from *July*:
http://markmail.org/message/t4vj4saisem2mcgw
Here's where I mentioned what the implemented policy was:
http://markmail.org/message/s4necfnh4hnblpjm
And in another discussion: http://markmail.org/message/ap7syhqysizmsvrz)

If we want to reconsider that decision, then we should certainly do so
before we cut a release. I think it would be a real problem to change it
afterwards, so let's get it right.

Also, it's not the plugin itself that's blocking the release, it's us
making sure that we've implemented the core hooks correctly so that the
plugin can actually do its job, and that people who don't want that
particular plugin can make a better one.

(It is also an issue that a plugin, required for cordova-android 4.0.0,
breaks apps which are also building for cordova-ios 3.8.0. I'll take a look
at that, and either remove the ios-native portions of the whitelist plugin,
or neuter it so that it doesn't interfere with an ios app if it's not on
the unplug-whitelist branch of that repo.)

Ian


 @purplecabbage
 risingj.com

 On Mon, Mar 2, 2015 at 2:02 PM, Shazron shaz...@gmail.com wrote:

  legacy-whitelist-plugin should be fixed so that it compiles on
  cordova-ios@3.8.0. It shouldn't be a problem to fix this at compile or
  run-time (whichever is applicable here related to the compile error)
 
  On Mon, Mar 2, 2015 at 1:47 PM, Darryl Pogue dvpdin...@gmail.com
 wrote:
   On 2 March 2015 at 13:37, Joe Bowser bows...@gmail.com wrote:
   So, right now the whitelist changes are what's holding up the 4.0.0
  release
   now?  Is this really the only thing that's holding up this release?
  
   On Wed Feb 25 2015 at 1:18:26 PM Andrew Grieve agri...@chromium.org
  wrote:
  
   I think we'll also need to finish with the whitelist changes  have
  both
   the legacy and new-way whitelist plugins released before we can do a
  4.0.0
   release (otherwise you wouldn't be able to write an app that hits the
   network)
  
  
   Just FYI, the whitelist stuff is proving to be a bit of a pain point.
   I'm using cordova-android@master, and need to install the
   legacy-whitelist plugin in order to make network requests. Once the
   plugin is installed, everything seems to work.
  
   The problem is that the legacy-whitelist plugin generates compile
   errors with cordova-ios@3.8.0, so now I can't just run `cordova
   build`, I need to split the platforms up and install/uninstall the
   plugin in between. If someone makes a dev build for Android and
   forgets the plugin, it will appear to build successfully but not
   actually function properly due to the whitelist.
  
   I know, this is all pre-release, so pain is somewhat expected right
   now. I'm worried about the case where cordova-android@4.0.0 is
   released and cordova-ios@3.8.0 is still current, and how people can
   avoid whitelist breakage there.
  
   -
   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: Android - Merging unplug-whitelist branch

[Ian Clelland]

Tests are definitely critical before we call for a vote :) I don't mind a
short time between landing the code and landing the tests.


On Thu, Feb 12, 2015 at 2:48 PM, Andrew Grieve agri...@chromium.org wrote:

 Code LGTM! I think it's a good idea to land on master and pursue tests
 after-the-fact. More time on master means more real-world testing before it
 being released.

 On Wed, Feb 11, 2015 at 10:23 PM, Ian Clelland iclell...@chromium.org
 wrote:

  Not specifically, yet -- I have done manual testing on it so far, and was
  going to work with Andrew to put proper unit tests in before we cut
 4.0.0.
 
  On Wed, Feb 11, 2015 at 4:39 PM, Joe Bowser bows...@gmail.com wrote:
 
   Are their JUnit tests to test the new unplugged whitelist?
  
   On Wed Feb 11 2015 at 1:29:51 PM Ian Clelland iclell...@chromium.org
   wrote:
  
I've been keeping the whitelist breakout on a branch for some time
 now,
   but
since this is something that we want to get into Cordova 4.0.0, it
 will
have to be merged in soon.
   
I've rebased it against master as of this afternoon, and pushed it
  into a
branch - unplug-whitelist-4.0.0 -- It passes all of my tests, but
  please,
if you're involved in the 4.0.x branch, try it out and let me know if
  it
breaks things. I'll merge this in the next little while if I hear
 only
silent approval ;)
   
This should work with the org.apache.cordova.legacy-whitelist to
  provide
functionality identical to previous versions of Cordova.
   
  
 

Re: [VOTE] Plugins Release

[Ian Clelland]

That's odd -- in the Apache repo, the tags appear to be correct (and they
are on my local repos as well) -- GitHub is the only place I see that bad
tag.

GitHub also does have the correct commits (4330db8 and 1882bfb) as well,
but the r0.3.0 tag isn't applied to the commit in -device.

What I really don't get is that, for file-transfer, *both* commits appear
to have the r0.5.0 tag!
https://github.com/apache/cordova-plugin-file-transfer/commit/1882bfb
https://github.com/apache/cordova-plugin-file-transfer/commit/1559888

In any case, GitHub isn't authoritative for Apache projects; the apache
repo is, but this is something that we should fix if we can.

On Thu, Feb 12, 2015 at 3:51 AM, Alexander Sorokin (Akvelon) 
v-als...@microsoft.com wrote:

 Hi all,

 I can confirm that the file transfer bug is fixed in this one, though I
 see another issue here: the tags for `device` and `file transfer` plugins
 are not matching the actual GitHub tags. The file transfer one is just not
 updated from previous release attempt, but the device one did not match in
 previous attempt either.

 I don't think that's critical, just wanted to let you know.

 cordova-plugin-device: 0.3.0 (4330db87b9)
 actual tag on github for 0.3.0 is: 3a490a3

 cordova-plugin-file-transfer: 0.5.0 (1882bfbd2d)
 actual tag on github for 0.5.0 is: 1559888

 Thanks,
 Alexander Sorokin

 -Original Message-
 From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
 Grieve
 Sent: Wednesday, February 11, 2015 17:42
 To: Andrew Grieve
 Cc: dev
 Subject: Re: [VOTE] Plugins Release

 Just checked - link is working again. Please cast some votes :)

 On Mon, Feb 9, 2015 at 1:55 PM, Andrew Grieve agri...@chromium.org
 wrote:

  I can't even svn up on it right now. Think it's just having an outage.
 
  On Mon, Feb 9, 2015 at 11:19 AM, Alexander Sorokin (Akvelon) 
  v-als...@microsoft.com wrote:
 
  Hi guys,
 
  It looks like there is something wrong with access rules or something.
  I cannot access
  https://dist.apache.org/repos/dist/dev/cordova/CB-8429/
  It says: 403 Forbidden
  Can someone open access to it?
 
  Thanks,
  Alexander Sorokin
 
  -Original Message-
  From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
  Andrew Grieve
  Sent: Monday, February 9, 2015 18:05
  To: dev
  Subject: [VOTE] Plugins Release
 
  Please review and vote on the release of this plugins release.
 
  Release issue: https://issues.apache.org/jira/browse/CB-8429
  (contains release notes for all plugins)
 
  The plugins have been published to dist/dev:
  https://dist.apache.org/repos/dist/dev/cordova/CB-8429/
 
  They are the same as last week except for file-transfer.
 
  The packages were published from their corresponding git tags:
 
  cordova-plugin-battery-status: 0.2.12 (ec59ef11a5)
  cordova-plugin-camera: 0.3.5 (799ed580d3)
  cordova-plugin-console: 0.2.13 (7507b29527)
  cordova-plugin-contacts: 0.2.16 (95d4d176f3)
  cordova-plugin-device-motion: 0.2.11 (110b27671f)
  cordova-plugin-device-orientation: 0.3.11 (d8fd79b2ae)
  cordova-plugin-device: 0.3.0 (4330db87b9)
  cordova-plugin-dialogs: 0.3.0 (d12008f9cd)
  cordova-plugin-file-transfer: 0.5.0 (1882bfbd2d)
  cordova-plugin-file: 1.3.3 (b05bcff378)
  cordova-plugin-geolocation: 0.3.12 (ccab812a49)
  cordova-plugin-globalization: 0.3.4 (6b1e88d534)
  cordova-plugin-inappbrowser: 0.6.0 (90d41e87ce)
  cordova-plugin-media: 0.2.16 (10df21dea8)
  cordova-plugin-media-capture: 0.3.6 (cc779375e3)
  cordova-plugin-network-information: 0.2.15 (81037e29cf)
  cordova-plugin-splashscreen: 1.0.0 (a9f0faa499)
  cordova-plugin-vibration: 0.3.13 (25217db403)
  cordova-plugin-statusbar: 0.1.10 (5feffc9314)
  cordova-plugins: file-system-roots-0.1.0 (be0a4c6cfb)
  cordova-plugin-test-framework: 0.0.1 (6aad294699)
 
 
  Upon a successful vote I will upload the archives to dist/, upload
  them to the Plugins Registry, and post the corresponding blog post.
 
  Voting guidelines:
  https://github.com/apache/cordova-coho/blob/master/docs/release-votin
  g.md
 
  Voting will go on for a minimum of 24 hours.
 
  I vote +1:
 
  * Ran coho audit-license-headers over the relevant repos
  * Ran coho check-license to ensure all dependencies and
  subdependencies have Apache-compatible licenses
  * Ran mobile-spec on android, and made sure it compiled for iOS.
  There were only 2 failures in media, and I verified that the same 2
  errors happen with the previous plugin version
 
 
 

Re: ArrayBuffers in WP8 Plugins

[Ian Clelland]

The File plugin should have that -- spec test 104 tests calling
FileWriter.write() with an ArrayBuffer as an argument.

The write() method in File.cs looks like it uses
JSON.JsonHelper.Deserialize to deserialize it, though -- you might have to
dig into the bridge to see exactly how and where it gets encoded in the
first place.


On Tue, Feb 10, 2015 at 8:28 PM, Don Coleman don.cole...@gmail.com wrote:

 Are there any examples of deserializing arraybuffers in WP8 plugins?

 I'm looking for the WP8 equivalent of Android's byte[] data = args.
 getArrayBuffer(3);

Android - Merging unplug-whitelist branch

[Ian Clelland]

I've been keeping the whitelist breakout on a branch for some time now, but
since this is something that we want to get into Cordova 4.0.0, it will
have to be merged in soon.

I've rebased it against master as of this afternoon, and pushed it into a
branch - unplug-whitelist-4.0.0 -- It passes all of my tests, but please,
if you're involved in the 4.0.x branch, try it out and let me know if it
breaks things. I'll merge this in the next little while if I hear only
silent approval ;)

This should work with the org.apache.cordova.legacy-whitelist to provide
functionality identical to previous versions of Cordova.

Re: Android - Merging unplug-whitelist branch

[Ian Clelland]

Not specifically, yet -- I have done manual testing on it so far, and was
going to work with Andrew to put proper unit tests in before we cut 4.0.0.

On Wed, Feb 11, 2015 at 4:39 PM, Joe Bowser bows...@gmail.com wrote:

 Are their JUnit tests to test the new unplugged whitelist?

 On Wed Feb 11 2015 at 1:29:51 PM Ian Clelland iclell...@chromium.org
 wrote:

  I've been keeping the whitelist breakout on a branch for some time now,
 but
  since this is something that we want to get into Cordova 4.0.0, it will
  have to be merged in soon.
 
  I've rebased it against master as of this afternoon, and pushed it into a
  branch - unplug-whitelist-4.0.0 -- It passes all of my tests, but please,
  if you're involved in the 4.0.x branch, try it out and let me know if it
  breaks things. I'll merge this in the next little while if I hear only
  silent approval ;)
 
  This should work with the org.apache.cordova.legacy-whitelist to provide
  functionality identical to previous versions of Cordova.
 

Re: [DISCUSS] Cordova-Android 4.0.0 Release

[Ian Clelland]

On Wed, Feb 4, 2015 at 7:58 PM, Fu, Junwei junwei...@intel.com wrote:

 What are the test cases don't work for Crosswalk? I'd like to do whatever
 I can to help.


So, Crosswalk 10 (and, I believe, 11) work great for Cordova. There is a
failing test in File Transfer, though, that appears to be a threading issue
causing a NPE deep inside of OkHTTP.

It's very similar to a bug we solved almost a year ago:
https://issues.apache.org/jira/browse/CB-6378, except that it's happening
in a different method, and while the last time, the cause was obvious
(connections opened on one thread, and closed on another), this time
everything *should* be happening on the same thread.

I've just created https://issues.apache.org/jira/browse/CB-8431 if you want
to take a look. I haven't had the chance to really dig into where the error
is coming from yet, but I'll take a closer look tomorrow.

Ian




 -Original Message-
 From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
 Grieve
 Sent: Thursday, February 05, 2015 3:43 AM
 To: dev
 Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release

 On Wed, Feb 4, 2015 at 2:25 PM, Joe Bowser bows...@gmail.com wrote:

  OK, so since we're using e-mail to do a sprint, here's where I think
  we're at so far.
 
 
  - Ian's been working on getting crosswalk 10 working and is hitting
  some FileTransfer crash issues.
  (Apparently Crosswalk-11 works? Ian, what's happening with this?)
  - Mobilespec really should be passing, let's investigate and fix
  plugins / tests if they are the issues.
 
  Has anyone done this yet?
 
 Don't think so.

 
  - Android's update script is not preserving artifacts of framework
  type=gradleReference/ (hoping to work on this today)
 
  Did you get around to doing this?
 
 Done!

 
  - *LinearLayoutSoftKeyboardDetect - delete it!*
 
  It's apparently already gone on Master.
 
 Done!

 
  - Ensure that our gradle support is to the point where plugins can
  target android-sdk-provided libs (play services  -compat libs)
 
  What needs to be done here? Is there a JIRA issue for this?
 
 Done! Needs a tools release.
 Haven't tested how bad the error messages are if you don't have them
 installed though. That seems like a can-be-done-after thing (e.g. If the
 error message sucks, we could: before build, pre-scan for existence of them
 in the SDK directly.)

 
  - Make CordovaActivity not implement CordovaInterface, but instead
  provide CordovaInterface via an inner class (to solidify that you
  can't cast the activity to CordovaInterface and expect that to work -
  some used to do this but I think we've cleaned it all up now)
 
 done!


 
  I know there's a vote pending for 3.7.1, and we still need people to
  vote on that (I'll get around to it before the voting period ends),
  but I'm wondering how close we are to getting a 4.0.0 vote happening?
 

 I'd like to do a bit more work with playing with third party plugins in
 mobilespec before we vote to release. Right now many of them don't compile,
 and I think the main reason is that CordovaWebView is not a view. Planning
 on writing up a report of how many popular plugins break, and how bad it is
 to fix them.

 Also need to update embedder's guide in docs (maybe create an android-4.0.0
 branch?)
 Also need to do a plugins release for splashscreen (will start shortly).


 
 
 
  On Tue Feb 03 2015 at 7:20:29 PM Fu, Junwei junwei...@intel.com wrote:
 
   Crosswalk engine have been tested in mobile-spec and owned
   functionality tests with Crosswalk-11, and it was our plan to be
   released.  I request a PR in here
   https://github.com/MobileChromeApps/cordova-
   crosswalk-engine/pull/17.
  
   Thanks,
   Junwei.
  
   -Original Message-
   From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
   Andrew Grieve
   Sent: Wednesday, February 04, 2015 3:53 AM
   To: dev
   Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
  
   And, of course, for your FileTransfer change :P
  
   I just last night finished up the fixing of framework custom=false
   for gradle-based builds, so we're certainly nearing the finish line
   for 4.0.0 known issues.
  
   Of the list from before, only remaining are:
  
   - Ian's been working on getting crosswalk 10 working and is hitting
   some FileTransfer crash issues.
   - Mobilespec really should be passing, let's investigate and fix
   plugins
  /
   tests if they are the issues.
  
  
  
  
   On Tue, Feb 3, 2015 at 2:46 PM, Darryl Pogue dvpdin...@gmail.com
  wrote:
  
I just remembered that there should be a plugins release before
Android 4.0.0 goes out because of the moving of the splashscreen
logic out of the platform and into the plugin. As far as I can
tell, that's still unreleased.
   
--
--- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
   
   
  
   

Re: [DISCUSS] cordova-ios 3.8.0 release

[Ian Clelland]

I'm satisfied with that :)

Thanks for the explanation.

On Wed, Feb 4, 2015 at 6:21 PM, Shazron shaz...@gmail.com wrote:

 Migrating to node was not the concern, people will need to upgrade,
 tough luck. I was justifying the minor version bump, not just a patch
 version bump because of the nodejs dependency now for non-CLI users.

 On Wed, Feb 4, 2015 at 3:19 PM, Shazron shaz...@gmail.com wrote:
  Not on iOS. cordova-ios 3.7.0 and below all used bash/python scripts
  (one or two were node but not critical for non-CLI use).
  So post 3.7.0,  non-CLI users will need nodejs installed to create a
  project and run the scripts in the cordova subfolder of a project.
 
 
  On Wed, Feb 4, 2015 at 2:39 PM, Murat Sutunc mura...@microsoft.com
 wrote:
  Before migration there were a lot of nodejs dependencies already:
  Depends on nodejs :
  install-device, install-emulator, list-emulator-images, emulate, run,
 update
 
  Doesn’t depend on nodejs:
  list-devices, list-started-emulators, start-emulator, build, clean,
 log, create
 
  I believe create and build are the important ones here.
  To better understand the problem, what are the key scenarios for
 non-nodejs users? Is it just for builders?
 
  -Original Message-
  From: Shazron [mailto:shaz...@gmail.com]
  Sent: Wednesday, February 4, 2015 12:19 PM
  To: dev@cordova.apache.org
  Subject: Re: [DISCUSS] cordova-ios 3.8.0 release
 
  Normally I would say yes, except for this change:
  http://issues.apache.org/jira/browse/CB-8197 where all the bash
 scripts have been converted to nodejs.
  One could say that for CLI users, this is no big deal, but for users
 using bin/create this creates a dependency on nodejs now (although this is
 not new, there were partial changes to require nodejs in the the previous
 releases).
 
  On Wed, Feb 4, 2015 at 7:30 AM, Ian Clelland iclell...@chromium.org
 wrote:
  +1 for a new release to fix these.
 
  Question: Should a no-new-features-bug-fix-only release be 3.7.1,
  rather than 3.8.0?
 
  On Tue Feb 03 2015 at 9:20:53 PM Andrew Grieve agri...@chromium.org
 wrote:
 
  I know you've been single-handing iOS lately, so thanks for your hard
  work Shaz!
 
  Your list sounds well thought-out, and I've not got anything to add
  other than +1!
 
  On Tue, Feb 3, 2015 at 8:42 PM, Shazron shaz...@gmail.com wrote:
 
   Bug fix release.
  
   The two major fixes that are already in are:
  
   1. https://issues.apache.org/jira/browse/CB-8002
   2.https://issues.apache.org/jira/browse/CB-8036
  
   Others are here (post Oct 30th 2014):
   https://github.com/apache/cordova-ios/commits/master
   I've triaged all the iOS issues in JIRA, nothing else seemed
 critical.
  
   I'm looking at these other small issues that I can add in also if
  possible:
  
   https://issues.apache.org/jira/browse/CB-7606 (I caused this,
   probably)
   https://issues.apache.org/jira/browse/CB-8028 (I caused this,
   probably)
   https://issues.apache.org/jira/browse/CB-8336 (quick fix)
   https://issues.apache.org/jira/browse/CB-8254 (quick fix)
  
   Any other issues that need to get in for the release?
   (no new features - new features should eventually go in the 4.0.0
   branch)
  
   ---
   -- 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] cordova-ios 3.8.0 release

[Ian Clelland]

+1 for a new release to fix these.

Question: Should a no-new-features-bug-fix-only release be 3.7.1, rather
than 3.8.0?

On Tue Feb 03 2015 at 9:20:53 PM Andrew Grieve agri...@chromium.org wrote:

 I know you've been single-handing iOS lately, so thanks for your hard work
 Shaz!

 Your list sounds well thought-out, and I've not got anything to add other
 than +1!

 On Tue, Feb 3, 2015 at 8:42 PM, Shazron shaz...@gmail.com wrote:

  Bug fix release.
 
  The two major fixes that are already in are:
 
  1. https://issues.apache.org/jira/browse/CB-8002
  2.https://issues.apache.org/jira/browse/CB-8036
 
  Others are here (post Oct 30th 2014):
  https://github.com/apache/cordova-ios/commits/master
  I've triaged all the iOS issues in JIRA, nothing else seemed critical.
 
  I'm looking at these other small issues that I can add in also if
 possible:
 
  https://issues.apache.org/jira/browse/CB-7606 (I caused this, probably)
  https://issues.apache.org/jira/browse/CB-8028 (I caused this, probably)
  https://issues.apache.org/jira/browse/CB-8336 (quick fix)
  https://issues.apache.org/jira/browse/CB-8254 (quick fix)
 
  Any other issues that need to get in for the release?
  (no new features - new features should eventually go in the 4.0.0 branch)
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

Re: Cordova Android plugin with a maven dependency?

[Ian Clelland]

Hi Brien,

Are you building with Gradle, or with Ant?

The new Gradle build system has the ability to do that -- it's what I've
been using for the Crosswalk plugin.

You can see how it's done in the GitHub repo at
https://github.com/clelland/cordova-crosswalk-engine , but basically, the
plugin.xml file contains the line:

framework src=libs/xwalk_core_library/xwalk.gradle custom=true
type=gradleReference /

And then the libs/xwalk_core_library/xwalk.gradle file has these two
sections:

repositories {
  maven {
url '
https://download.01.org/crosswalk/releases/crosswalk/android/maven2'
  }
}

dependencies {
compile 'org.xwalk:xwalk_core_library_beta:10.39.235.17'
   }

That downloads the AAR project and compiles it into the app on build.


On Sun Feb 01 2015 at 4:02:13 AM Brien Colwell br...@nextop.io wrote:

 Hey all,

 I'm writing a Cordova plugin for Android that has a Maven dependency. Is
 it possible to add that to the plugin.xml? If not possible, do people
 add a JAR somewhere under src/android? Thanks for the help.

 Best,
 Brien


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

Re: [Code Review] Gradle Changes

[Ian Clelland]

On Tue Jan 06 2015 at 4:09:47 PM Andrew Grieve agri...@chromium.org wrote:

 For anyone following the gradle work that's been happening, I have a PR
 that overhauls how settings are overridden. Rather than using custom
 environment variables, it uses Gradle properties. This is exactly what
 properties in gradle were designed for, and they are more flexible.

 I'd like 2 things:
 1 - Code review for https://github.com/apache/cordova-android/pull/145
 (Ian
 - mostly looking at you :P)


It looks pretty GTM; I've left some comments on the commit.


 2 - Comments about whether there is a need to continue supporting the
 existing environment variables. Given that gradle is not enabled by
 default, and marked as experimental, I think they are fine to just change.


Without the environment variables, can you set the new properties if you
are running cordova/build from the command line? (i.e. no Android Studio,
no Cordova CLI)? If you can, and we document how to do it, then I'm okay
with removing them.

Nobody should be building tooling around the gradle build yet, until we've
released 4.0 and declared it stable. (We may want to give the ionic folks a
warning though, in case they're following master here)

Ian

Re: How to handle CSP for XHR in Cordova 4.0

[Ian Clelland]

On Thu Dec 18 2014 at 9:42:18 AM Andrew Grieve agri...@chromium.org wrote:

 That's a good point Chuck. Since the meaning of access would be changing
 in a dramatic way, I think we should just come up with something new, and
 leave access for anyone that wants to use the legacy-whitelist plugin.

 Maybe:
 allow-navigationPATTERN/allow-navigation
 allow-system-urlPATTERN/allow-system-url

 On Wed, Dec 17, 2014 at 5:29 PM, Chuck Lantz cla...@microsoft.com wrote:
 
  Yeah, I also am thinking about upgrade situations where someone takes
 an
  existing app and moves it to Android Cordova 4.0. It strikes me there
 we'd
  either want the existing behavior to be preserved (flaws aside) or move
 it
  to the top level nav behavior.  Did I read correctly the current
 whitelist
  would be refactored out to a plugin?


And yes, the current whitelist, flaws and all, is refactored out into
org.apache.cordova.legacy-whitelist. The source is in the cordova-plugins
repo; it hasn't been published yet.

Ian


 
  -Chuck
 
  -Original Message-
  From: Ian Clelland [mailto:iclell...@chromium.org]
  Sent: Wednesday, December 17, 2014 1:02 PM
  To: dev@cordova.apache.org
  Subject: Re: How to handle CSP for XHR in Cordova 4.0
 
  I think that access tags (and the widget spec generally) were never a
 good
  fit for the top-level-navigation case. Widgets, as far as I know, were
  always intended to be single page apps, and the access tag wouldn't
 have
  any affect on that at all.
 
  We've used it for nav in the past, though, so the question is whether
  familiarity with the old syntax trumps the fact that we're changing the
  behaviour.
 
  On Wed Dec 17 2014 at 11:47:02 AM Chuck Lantz cla...@microsoft.com
  wrote:
 
   I suppose that is a good question. I took a look at the Widget Access
   Request Policy W3C spec where that element comes from.  It's actually
   pretty ambiguous.
  
   A user agent enforces an access request policy. ... In the default
   policy, a user agent must deny access to network resources external to
   the widget by default, whether this access is requested through APIs
  (e.g.
   XMLHttpRequest) or through markup (e.g. iframe, script, img)..
  
   ... but...
  
   A user agent may apply a different default policy if the widget is
   being used in a context that defines its own policy, such as for
   instance a widget served over HTTP. A more lenient policy can be
   defined with the access-request list as defined in the processing
   section. ... Furthermore, a user agent may grant access to certain URI
   schemes (e.g., mailto:) without the need of an access request if its
   security policy considers those schemes benign.
  
   It strikes me that today we implement the default policy and what
   we're proposing here is a more lenient, alternate policy.
  
   For what it's worth, here's how this is defined in the Windows world:
  
 ApplicationContentUriRules
 Rule Match=https://www.google.com; Type=include /
 /ApplicationContentUriRules
  
   -Chuck
  
   -Original Message-
   From: Ian Clelland [mailto:iclell...@chromium.org]
   Sent: Wednesday, December 17, 2014 8:16 AM
   To: dev@cordova.apache.org
   Subject: Re: How to handle CSP for XHR in Cordova 4.0
  
   Definitely want to handle iOS, with the same policy. I've been working
   on that in parallel with Android.
  
   Do we want to use access for Nav? I wasn't sure, given its history,
   and the fact that we're changing its behaviour. Is it better to stick
   with the familiar tag and change what it tries to do? Or create a new
   tag and deprecate access?
  
   On Wed Dec 17 2014 at 10:30:18 AM Chuck Lantz cla...@microsoft.com
   wrote:
  
What about top level nav and script access?  Would the thought be
that the access elements would map to that in the base platform?
I'm thinking in terms of consistency across the different platforms.
It strikes me we'd want to update iOS at least as well.
   
-Chuck
   
-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
Andrew Grieve
Sent: Tuesday, December 16, 2014 7:21 AM
To: dev
Subject: Re: How to handle CSP for XHR in Cordova 4.0
   
On Mon, Dec 15, 2014 at 8:19 PM, Chuck Lantz cla...@microsoft.com
   wrote:

 Near term, for Windows 8.0/8.1, a custom security policy is in
 place at the platform level for store apps so CSP doesn't really
 apply there at the moment. (And, to be really specific, CSP
 support is pretty limited in
 IE10/11 focusing on the sandbox directive. The Windows 10 Tech
 Preview is where you can see the real support in IE right now.)
 So, it's a more of forward-thinking topic in that world.

 A related question, however - CSP support only started in the
 Android browser with 4.4 did it not? Obviously Crosswalk would
 have it but what about when using the base browser?  Is the
 thought devs should use

Re: How to handle CSP for XHR in Cordova 4.0

[Ian Clelland]

I think that access tags (and the widget spec generally) were never a good
fit for the top-level-navigation case. Widgets, as far as I know, were
always intended to be single page apps, and the access tag wouldn't have
any affect on that at all.

We've used it for nav in the past, though, so the question is whether
familiarity with the old syntax trumps the fact that we're changing the
behaviour.

On Wed Dec 17 2014 at 11:47:02 AM Chuck Lantz cla...@microsoft.com wrote:

 I suppose that is a good question. I took a look at the Widget Access
 Request Policy W3C spec where that element comes from.  It's actually
 pretty ambiguous.

 A user agent enforces an access request policy. ... In the default
 policy, a user agent must deny access to network resources external to the
 widget by default, whether this access is requested through APIs (e.g.
 XMLHttpRequest) or through markup (e.g. iframe, script, img)..

 ... but...

 A user agent may apply a different default policy if the widget is being
 used in a context that defines its own policy, such as for instance a
 widget served over HTTP. A more lenient policy can be defined with the
 access-request list as defined in the processing section. ... Furthermore,
 a user agent may grant access to certain URI schemes (e.g., mailto:)
 without the need of an access request if its security policy considers
 those schemes benign.

 It strikes me that today we implement the default policy and what we're
 proposing here is a more lenient, alternate policy.

 For what it's worth, here's how this is defined in the Windows world:

   ApplicationContentUriRules
   Rule Match=https://www.google.com; Type=include /
   /ApplicationContentUriRules

 -Chuck

 -Original Message-
 From: Ian Clelland [mailto:iclell...@chromium.org]
 Sent: Wednesday, December 17, 2014 8:16 AM
 To: dev@cordova.apache.org
 Subject: Re: How to handle CSP for XHR in Cordova 4.0

 Definitely want to handle iOS, with the same policy. I've been working on
 that in parallel with Android.

 Do we want to use access for Nav? I wasn't sure, given its history, and
 the fact that we're changing its behaviour. Is it better to stick with the
 familiar tag and change what it tries to do? Or create a new tag and
 deprecate access?

 On Wed Dec 17 2014 at 10:30:18 AM Chuck Lantz cla...@microsoft.com
 wrote:

  What about top level nav and script access?  Would the thought be that
  the access elements would map to that in the base platform?  I'm
  thinking in terms of consistency across the different platforms.  It
  strikes me we'd want to update iOS at least as well.
 
  -Chuck
 
  -Original Message-
  From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
  Andrew Grieve
  Sent: Tuesday, December 16, 2014 7:21 AM
  To: dev
  Subject: Re: How to handle CSP for XHR in Cordova 4.0
 
  On Mon, Dec 15, 2014 at 8:19 PM, Chuck Lantz cla...@microsoft.com
 wrote:
  
   Near term, for Windows 8.0/8.1, a custom security policy is in place
   at the platform level for store apps so CSP doesn't really apply
   there at the moment. (And, to be really specific, CSP support is
   pretty limited in
   IE10/11 focusing on the sandbox directive. The Windows 10 Tech
   Preview is where you can see the real support in IE right now.) So,
   it's a more of forward-thinking topic in that world.
  
   A related question, however - CSP support only started in the
   Android browser with 4.4 did it not? Obviously Crosswalk would have
   it but what about when using the base browser?  Is the thought devs
   should use the old whitelist model here?
  
 
  I think one of the big issues is that the whitelist never worked for
  blocking *all* requests. It didn't work pre-3.0, and it doesn't block
  audio, video, websocket in any version. Supporting the illusion of
  a whitelist is probably worse than not supporting it at all.
 
 
 
  
   Safari seems to support it back at least as far as iOS 7 (or 6 with
   a custom header) - the main reason I bring it up is developers could
   see different behaviors between devices and versions if the default
   CSP policy leaves something like inline or eval disabled.
  
   -Chuck
  
   -Original Message-
   From: Ian Clelland [mailto:iclell...@chromium.org]
   Sent: Monday, December 15, 2014 11:17 AM
   To: dev@cordova.apache.org
   Subject: Re: How to handle CSP for XHR in Cordova 4.0
  
   On Mon Dec 15 2014 at 11:28:43 AM Chuck Lantz cla...@microsoft.com
   wrote:
  
For the Windows platform, IE 10 and 11 support CSP 1.0 - there's
one subtle difference (X-Content-Security-Policy vs
Content-Security-Policy in the HTTP header).  The Win 10 Tech
Preview
   already has full CSP support.
In general, the conventional wisdom is to push app models towards
the CSP and away from custom enforcement policies from our point
of
  view.
I love the idea of Cordova heading this same direction.
   
  
   That's great to hear

Re: How to handle CSP for XHR in Cordova 4.0

[Ian Clelland]

On Mon Dec 15 2014 at 11:28:43 AM Chuck Lantz cla...@microsoft.com wrote:

 For the Windows platform, IE 10 and 11 support CSP 1.0 - there's one
 subtle difference (X-Content-Security-Policy vs Content-Security-Policy in
 the HTTP header).  The Win 10 Tech Preview already has full CSP support.
 In general, the conventional wisdom is to push app models towards the CSP
 and away from custom enforcement policies from our point of view. I love
 the idea of Cordova heading this same direction.


That's great to hear.


 Windows apps have a URI whitelist focused on top level navigation and
 JavaScript includes on pages not XHR. The main reason to lock down at this
 level is to reduce the risk of a malicious user navigating the page to a
 URI outside of the app author's control and take advantage of sensitive
 APIs.  So, I think some level of whitelist to help out in this situation is
 advisable even with CSP being used. We’ve mapped access elements in
 config.xml to the top level nav whitelist for this reason. CSP isn’t really
 designed to help with this kind of problem.


Agreed. CSP on the web can't really control navigation, or else web page
authors would be able to trap browser windows on their sites. It makes
sense for installed apps, but not so much for sites or web apps.



 Perhaps a default CSP policy in the template coupled with a top level nav
 whitelist is the right starting point.


That sounds like what I'm trying to implement on Android and iOS. Let me
know what I can do to make that easy for Windows.


 Determining what the CSP policy looks like will be really important – by
 default CSP blocks both inline and eval use. Of the two, inline use tends
 to be the bigger risk factor.


True -- eval without inline can theoretically be controlled, although it's
not great practice. inline, with or without eval is an XSS waiting to
happen, in a web app.



 -Chuck

 -Original Message-
 From: Ian Clelland [mailto:iclell...@google.com]
 Sent: Friday, December 12, 2014 9:34 AM
 To: dev@cordova.apache.org
 Subject: Re: How to handle CSP for XHR in Cordova 4.0

 Default CSP is a good idea. I was worried about leaving new apps
 vulnerable by default but that should close that.

 Do we know what the CSP story is on all platforms, to know that it won't
 break anything else?
 On 12 Dec 2014 11:56, Michal Mocny mmo...@chromium.org wrote:

  I'm fine with 1. coupled with a default CSP in the template application.
 
  For older apps not written from scratch, we can perhaps strongly
  suggest installing the legacy-whitelist, which would change the
  default-open behaviour to default-closed.
 
  Together, that would give sensible defaults that aren't
 open-to-everything?
 
  -Michal
 
  On Fri, Dec 12, 2014 at 9:13 AM, Ian Clelland iclell...@chromium.org
  wrote:
 
   I'm just building the new optional whitelist plugins for Cordova
   Android and iOS 4.x, and I'm thinking about how to encourage
   developers to use
  CSP
   for network requests, as opposed to a
   Cordova-implemented-whitelist-which-probably-leaks-like-a-sieve.
  
   (Note: This is really just about things like XHR requests, img and
   script tags, etc, which are historically the only things that
   we've reliably been able to filter out. Other classes of network
   requests just bypass all of our code anyway, which sucks, and frame
   navigation and external application launches are already well handled
 by the framework).
  
   The policy I've implemented on the unplug-whitelist branches, which
   at first thought at least *sounds* sane, is that network requests
   are
  blocked
   by default. (At least all of the ones that we can intercept). That
   way, a plugin, such as the legacy-whitelist plugin, can open up
   access to
  specific
   resources, and the fallback is safety.
  
   To use CSP, though, we have to open up access to the outside, and we
  don't
   necessarily know what the developer wants to open (the whole point
   is
  that
   they specify in the HTML, not in a config file.) The easiest way is
   to
  open
   up access to *all* resources to the webview, and then restrict it
   through the CSP header/meta-tag, which does a better job of blocking
   those
  requests
   than we do in any case.
  
   I think that we want to encourage developers to use CSP, for a lot
   of reasons, but I'm going to have to do one of these things, and I'm
   not entirely sure which is the right one:
  
   1. Open access to all network resources by default in Cordova 4.x.
 * This doesn't apply to navigations, or launching other apps.
   They're still blocked by default.
 * Any plugin implementing shouldAllowRequest would still be able
   to
  turn
   this into a disallow-by-default whitelist
 * We can't block everything anyway (see websockets, audio/video
  streams /
   probably more), so it removes the illusion that we can.
  
   2. Make another whitelist-y plugin, something like
  org.apache.cordova.csp
   that exists only to open up

How to handle CSP for XHR in Cordova 4.0

[Ian Clelland]

I'm just building the new optional whitelist plugins for Cordova Android
and iOS 4.x, and I'm thinking about how to encourage developers to use CSP
for network requests, as opposed to a
Cordova-implemented-whitelist-which-probably-leaks-like-a-sieve.

(Note: This is really just about things like XHR requests, img and
script tags, etc, which are historically the only things that we've
reliably been able to filter out. Other classes of network requests just
bypass all of our code anyway, which sucks, and frame navigation and
external application launches are already well handled by the framework).

The policy I've implemented on the unplug-whitelist branches, which at
first thought at least *sounds* sane, is that network requests are blocked
by default. (At least all of the ones that we can intercept). That way, a
plugin, such as the legacy-whitelist plugin, can open up access to specific
resources, and the fallback is safety.

To use CSP, though, we have to open up access to the outside, and we don't
necessarily know what the developer wants to open (the whole point is that
they specify in the HTML, not in a config file.) The easiest way is to open
up access to *all* resources to the webview, and then restrict it through
the CSP header/meta-tag, which does a better job of blocking those requests
than we do in any case.

I think that we want to encourage developers to use CSP, for a lot of
reasons, but I'm going to have to do one of these things, and I'm not
entirely sure which is the right one:

1. Open access to all network resources by default in Cordova 4.x.
  * This doesn't apply to navigations, or launching other apps. They're
still blocked by default.
  * Any plugin implementing shouldAllowRequest would still be able to turn
this into a disallow-by-default whitelist
  * We can't block everything anyway (see websockets, audio/video streams /
probably more), so it removes the illusion that we can.

2. Make another whitelist-y plugin, something like org.apache.cordova.csp
that exists only to open up access to network resources. Direct all users
who want to use CSP to install that plugin first
  * It's a 4th network plugin (after legacy-whitelist, navigation-whitelist
and intent-whitelist)
  * Adding it doesn't actually add any CSP protection, so it probably needs
a better name
  * It's an extra step that may confuse people and limit adoption

3. Do something crazy. Maybe a CSP plugin that automatically creates CSP
tags *and* updates the XHR whitelist, both from config directives.
  * Lots more work
  * We probably don't know enough about real requirements to get this right
  * If CSP is doing its job, then the XHR whitelist isn't needed anyway; it
would just be another layer that isn't doing anything different.

I'm leaning towards #1, but its a it's a decision that we really should
think about and decide on-list before moving forward.

Ian

Re: How to handle CSP for XHR in Cordova 4.0

[Ian Clelland]

Default CSP is a good idea. I was worried about leaving new apps vulnerable
by default but that should close that.

Do we know what the CSP story is on all platforms, to know that it won't
break anything else?
On 12 Dec 2014 11:56, Michal Mocny mmo...@chromium.org wrote:

 I'm fine with 1. coupled with a default CSP in the template application.

 For older apps not written from scratch, we can perhaps strongly suggest
 installing the legacy-whitelist, which would change the default-open
 behaviour to default-closed.

 Together, that would give sensible defaults that aren't open-to-everything?

 -Michal

 On Fri, Dec 12, 2014 at 9:13 AM, Ian Clelland iclell...@chromium.org
 wrote:

  I'm just building the new optional whitelist plugins for Cordova Android
  and iOS 4.x, and I'm thinking about how to encourage developers to use
 CSP
  for network requests, as opposed to a
  Cordova-implemented-whitelist-which-probably-leaks-like-a-sieve.
 
  (Note: This is really just about things like XHR requests, img and
  script tags, etc, which are historically the only things that we've
  reliably been able to filter out. Other classes of network requests just
  bypass all of our code anyway, which sucks, and frame navigation and
  external application launches are already well handled by the framework).
 
  The policy I've implemented on the unplug-whitelist branches, which at
  first thought at least *sounds* sane, is that network requests are
 blocked
  by default. (At least all of the ones that we can intercept). That way, a
  plugin, such as the legacy-whitelist plugin, can open up access to
 specific
  resources, and the fallback is safety.
 
  To use CSP, though, we have to open up access to the outside, and we
 don't
  necessarily know what the developer wants to open (the whole point is
 that
  they specify in the HTML, not in a config file.) The easiest way is to
 open
  up access to *all* resources to the webview, and then restrict it through
  the CSP header/meta-tag, which does a better job of blocking those
 requests
  than we do in any case.
 
  I think that we want to encourage developers to use CSP, for a lot of
  reasons, but I'm going to have to do one of these things, and I'm not
  entirely sure which is the right one:
 
  1. Open access to all network resources by default in Cordova 4.x.
* This doesn't apply to navigations, or launching other apps. They're
  still blocked by default.
* Any plugin implementing shouldAllowRequest would still be able to
 turn
  this into a disallow-by-default whitelist
* We can't block everything anyway (see websockets, audio/video
 streams /
  probably more), so it removes the illusion that we can.
 
  2. Make another whitelist-y plugin, something like
 org.apache.cordova.csp
  that exists only to open up access to network resources. Direct all users
  who want to use CSP to install that plugin first
* It's a 4th network plugin (after legacy-whitelist,
 navigation-whitelist
  and intent-whitelist)
* Adding it doesn't actually add any CSP protection, so it probably
 needs
  a better name
* It's an extra step that may confuse people and limit adoption
 
  3. Do something crazy. Maybe a CSP plugin that automatically creates CSP
  tags *and* updates the XHR whitelist, both from config directives.
* Lots more work
* We probably don't know enough about real requirements to get this
 right
* If CSP is doing its job, then the XHR whitelist isn't needed anyway;
 it
  would just be another layer that isn't doing anything different.
 
  I'm leaning towards #1, but its a it's a decision that we really should
  think about and decide on-list before moving forward.
 
  Ian
 

Re: 4.0 Sprint Tasks (Another Hey, let's ship 4.0.x soon post)

[Ian Clelland]

On Thu Dec 11 2014 at 2:51:04 PM Joe Bowser bows...@gmail.com wrote:

 On Thu Dec 11 2014 at 11:46:44 AM Andrew Grieve agri...@chromium.org
 wrote:

  On Thu, Dec 11, 2014 at 2:24 PM, Joe Bowser bows...@gmail.com wrote:
 
   On Wed Dec 10 2014 at 8:03:10 AM Andrew Grieve agri...@chromium.org
   wrote:
  
On Sun, Dec 7, 2014 at 11:53 PM, Joe Bowser bows...@gmail.com
 wrote:
   
 Hey

 After messing with the JS for a week, I decided for now to stop
 work
  on
 MozillaView.  I think I've managed to prove that the concept is at
   least
 possible, but I really feel that it's still too unstable to
 actually
   show
 past a demo/POC at this time.  We've definitely learned some
 lessons,
   and
 I'll probably write a blog post on them soon, and pick up work in
 the
   new
 year.

 That said, we should really concentrate on shipping 4.0 in January,
  we
 should do the following:

 1. Bump up the targeted version to 5.0

   
We should do this for 3.7.0
   
   
   I don't think we should bother with 3.7.0 at this point.  Adobe
 employees
   have a week left before they disappear for Winter Break, and I'm sure
  other
   people are going to vanish as the holidays approach.  We should
 probably
   just go straight to 4.0 in January?
  
 
  There's a lot of changes in 3.7.0 built up already. I don't think it'd
 be a
  good idea to skip it.
 
 
 And this is where I remember that we HAVE to release 3.7.0 because of our
 six month deprecation policy.  I just think that doing a release right
 before people disappear for two weeks is a bad idea.

 So, 3.7.0 and 4.0.0 in January? Also, if we are doing a 3.7.0 release, we
 have some things that MUST go in prior, such as CookieManager stuff in
 CordovaWebView/AndroidWebView.


That sounds good -- I approve of releasing from two major version branches
at the same time, especially if we're adding very similar features to both.


 Joe


 
  
  
   
 2. Allow for users to target KitKat for Quirks Mode (I'm not
 kidding,
 Quirks mode is back.  Chrome is the new IE! WTF MAN!)

   
Please confirm whether you mean something different from letting
 users
specify targetSdkVersion.
   
  
   No, That's what I meant.  I just remembered that we do allow users to
 do
   this.
  
   
   
 3. Get the gradle work in.  MUCH FASTER! LESS SPAM! WOW!

   
Woohoo! It's actually already been shipping in master / 3.6.0 behind
 an
environment variable (ANDROID_BUILD=gradle).
   
   
   I don't like the whole ship behind an environment variable practice,
  since
   it seems like a way to avoid having to create a feature branch.  I
 really
   wish that Gradle was a feature branch thing.


It was on a feature branch for some time before I merged it in. The trouble
with just using feature branches for something like this is that it's very
difficult to get it to end users, and it would otherwise be a major
breaking change, with an almost-entirely untested feature. (And by that,
I'm not saying that we didn't do any testing, just that build systems and
configurations vary incredibly wildly across the developer base, and
there's just no way that any of us could uncover all of the problems before
launch, no matter how careful we try to be. The amount of testing we can do
is dwarfed by the number of developers with test cases we couldn't discover
if we wanted to.)

Putting it behind a flag meant that we could get it to early adopters,
without telling them to get a branch of of the tip-of-tree, and they could
try it out without worrying about not being able to go back if it didn't
work.

Literally everyone I talked to about this was positive, and appreciated
that we had made it possible, without making it mandatory.

/rant

  Also, can one of you guys
   smack the Android team on the back of the head for that Gradle
 dependency
   hell they created?  The whole point of Gradle is to bundle the
  dependencies
   locally so they don't blow up when you change the system, and the
 plugin
   severely screws with that.


If I get to talk to the tools team, I'm definitely bringing that up. Even
their support matrix (that you showed me in IM) makes it look like it's
impossible to satisfy without deep inspection of package version numbers. I
think that we have a working solution to CB-8143 now, though.


  
  
   
 4. Get the JUnit tests working with Gradle/Android Studio.  I don't
   think
 this is a 4.0 task per-se, but we should do it right after 4.0 is
released.
 5. Stare at the pie chart wishing that 9 was 5.  (Anyone who knows
  our
 deprecation policies knows EXACTLY what I'm talking about).

 I do have one API change I want to make.  I want to rename the
 CordovaWebView interface CordovaWebInterface so that it's obvious
  that
it's
 an interface.  Since people using the old CordovaWebView embedded
   feature
 are going to have to do a find/replace on the XML, this doesn't

Re: Browserify JS is in

[Ian Clelland]

On Thu Dec 11 2014 at 9:29:08 PM Anis KADRI anis.ka...@gmail.com wrote:

 On Thu, Dec 11, 2014 at 1:45 PM, Michal Mocny mmo...@chromium.org wrote:
 
  25MB is for the one-time cordova-cli install, and not overhead for the
  app.  Its not perfect but not a blocker imho.


Agreed. In terms of size for a developer tool, that's not too bad. And if
for that we get a community, bug fixes, more eyes, and fixes for the edge
cases that we haven't come across yet, then it's a pretty small price.


 
  There are more troubling things about the change than the size overhead:
  - I don't think browserify has baked at all.  It was landed behind a
  flag, but is it actually used anywhere?
  - Why browserify and not webpack (aside: its 13Mb..)?  Was it compared at
  all..


 - Last time it was discussed, there were still several breaking changes
 for
  plugins.  Were they resolved?
 
  Anyway, how can we get data on the change to see if it is positive?:
  - Existing plugins continue to work (We run mobile spec, and get
 downstream
  distributions run tests on their plugins).
  - Startup time is not negatively affected.
  - Build/prepare time is not negatively affected.
 
  Is that fair?
 

 Absolutely totally fair. Those are valid concerns.

 I tried the core plugins and they all work and all pass mobile-spec. I know
 you guys (ab)use require('./Module') a lot in chrome plugins but they
 should still all pass. I actually would be curious to know the results.


I just checked our code, and the only place I see that construct in plugins
is in org.chromium.runtime -- it uses require('./CryptoJS-sha256') to
access the CryptoJS library, without having to make that a separate plugin.
Is there a better way that we should be doing that?


 Startup should be faster because it is not XHRing a different file to get a
 list of plugins to script inject them. I actually didn't benchmark this
 but it would be interesting.


This is a win -- I remember that we were all pretty excited about not
having all of the code baked in to cordova.js when 3.0 came out, but people
have complained that the result is slower startup times, because of the
extra XHRs.

Build time is slowed down by a few ms (re-read the first email of this
 thread).


And, of course, that's absolutely dwarfed by every other measurable factor.

I think this is a good step forward (so long as it's all working) -- If we
just switch the default, then people still have the ability to build
without it, right?

I just wonder whether semver requires us to bump the major version of
anything because of this (and if so, then what? CLI? JS? Lib? Everything?)
or whether a no breaking changes, no new features change can count as a
patch version increment.


 
  -Michal
 
  On Thu, Dec 11, 2014 at 2:38 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   I'd really like to get it fully spelled out *why* browserify is the
 right
   tool for this. Some thoughts below:
  
   On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux b...@brian.io wrote:
  
we should move browserify to main and drop that insane concat code
   
its not heavyweight at all. it creates a hash in iife with deps
 mapped
in…as to why dep mgmt is better than concatenating…I don't think we
  need
   to
waste our time talking about that!
  
  
  
   What makes the concat code insane?
- It's easy to understand and make changes to
- It seems to work fine and is quite stable
- It has no dependencies (it's 52kb within cordova-js/tasks/lib)
  
   Browserify seems a bit scary to me:
   - It's 25MB and has a tonne of dependencies
   - Do we really need all of that functionality?
  
   I think it would actually help a lot to talk about dependency
 management.
   - Right now cordova-js creates a module for every file in src/
   - Plugins list each module explicitly in their plugin.xml
   With browserify, are you envisioning that this model change at all?
  
  
   Why change anything?
   - cordova-lib should concat plugin modules with cordova.js on prepare
  (this
   is the motivation stated in the JIRA. totally on board with this!)
   What else would I like to see changed?
   - exec.js (and any other platform-specific modules) should move to live
  in
   platform repos
 - This will make code changes that affect both much easier
   - Platforms should depend on cordova-js via package.json and snapshot
   generation should happen in bin/create as well as plugin add/rm
 - This will remove the (somewhat) annoying step of snapshotting
 - This will allow cordova-js to be released as it's own artifact
   - Good because we can do things like add Promise polyfill and not
  need
   to release all platforms to pick it up
   - A bit annoying since it's one more thing to release, but likely
  won't
   get released often.
  
  
   Please don't look at my email as trying to derail the work Anis did. I
   believe most of it is necessary to accomplish these goals whether we
 use
   Browserify, our own, or 

Re: [Android] Gradle is brittle, Android Studio broke my builds

[Ian Clelland]

On Tue Dec 09 2014 at 5:18:47 PM Joe Bowser bows...@gmail.com wrote:

 Hey

 I just upgraded to Android Studio 1.0 and now none of my 4.0 builds work.
 I'm getting gradle errors everywhere, and I have no idea how to resolve
 them.

 I'll file an issue, but this is pretty much a blocker since nothing can
 build once people update their stuff to the latest Android SDK.  I have a
 small demo today, but luckily I already built it before installing Android
 Studio.

 Any ideas?


Don't upgrade right before demos?

/kidding

We talked briefly about this over IM earlier; it looks like there are
issues with the release version of Android Studio installing Gradle 2.x,
which had a hard dependency on a later version of the Android Gradle
plugin, which then breaks all of our dependency checks.

I think the right thing do to (or at least, the thing we've done before in
this situation), is for a couple of us to update all of our build tools,
check that things still work if we update the dependency requirement, and
then update those requirements. We've taken the stance before that it's not
too far out of line to ask developers to be using the latest tools
available.

(Of course, if things *don't* work after updating build tools, then lets
get that fixed ASAP.)

Ian


 Joe

Re: WebView Promise and W3C standards

[Ian Clelland]

On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve agri...@chromium.org
wrote:

 userland means that plugins won't be able to use them unless every plugin
 also includes a copy of the polyfill within it.

 Looking at our core APIs, seems maybe it's just battery-status that will
 require it. Should we have battery-status include the polyfill within it? I
 hope not. I'd hate to get to where several plugins in my app all bundle the
 same polyfill.


I believe that Mozilla's new File API, which I think we're planning to
implement, and which should be as core as File is now, is also heavily
promises-based.



 If we move to having the entire cordova.js built using browserify where
 every plugin gets to contribute to the JS that goes into it - yes I can see
 this solving this use-case as well. But that also seems to me like a much
 larger and much more controversial change.

 Whether you are for or against promises - they are already here. They
 exists natively on most latest mobile webviews, and every vendor has
 committed to adding them. And they are being used in *most* new specs that
 I've seen (sockets, filesystem, permissions, service worker, fetch)

 Are there any concrete downsides to putting Promises polyfill right in
 cordova-js?


As long as the promise doesn't clobber the native implementation, if it
exists, and we can remove it completely from platforms when they don't need
it anymore, it seems to me like a small price for having this available to
all platforms. (Other opinions vary, I'm sure, though)




 On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser bows...@gmail.com wrote:

  +1 to userland. I see other approaches causing more problems.
 
  BTW: The only time I use promises is when the platform explicitly
 requires
  it, and right now that's just MozillaView.  While I think it looks
 awesome,
  I view Promises as a luxury right now and not a standard feature as of
 yet.
 
  I also really wish specs wouldn't rely on code that only exists on the
 very
  latest browsers. It just makes life harder on people who have to
 implement
  stuff.
 

Re: [Android] Gradle is brittle, Android Studio broke my builds

[Ian Clelland]

So the problem appears to be just the Android Gradle plugin, which *we*
hard coded to 0.12.0+, which doesn't work with Gradle 2.x, so we can fix
that.

Looking at the Android team's docs at
http://tools.android.com/tech-docs/new-build-system/version-compatibility
(thanks for the pointer, Joe), it looks like there isn't a consistent
version of the plugin that we can guarantee works for everyone, but we can
check the version of Gradle in use at build time, and get the right plugin
version then.

I've updated the build.gradle file in cordova-android to test for Gradle
2.1+, and to download a version of the plugin that works. I've tested it on
my system (updated today, with AS 1.0 and Gradle 2.2.1), and we've tested
it on a machine with Gradle 1.12; it works on both, and updates
automatically when you upgrade Gradle.

Joe -- can you try this out? If it works, I'll mark CB-8143 resolved.

Ian

On Wed Dec 10 2014 at 9:06:06 AM Ian Clelland iclell...@chromium.org
wrote:

 On Tue Dec 09 2014 at 5:18:47 PM Joe Bowser bows...@gmail.com wrote:

 Hey

 I just upgraded to Android Studio 1.0 and now none of my 4.0 builds work.
 I'm getting gradle errors everywhere, and I have no idea how to resolve
 them.

 I'll file an issue, but this is pretty much a blocker since nothing can
 build once people update their stuff to the latest Android SDK.  I have a
 small demo today, but luckily I already built it before installing Android
 Studio.

 Any ideas?


 Don't upgrade right before demos?

 /kidding

 We talked briefly about this over IM earlier; it looks like there are
 issues with the release version of Android Studio installing Gradle 2.x,
 which had a hard dependency on a later version of the Android Gradle
 plugin, which then breaks all of our dependency checks.

 I think the right thing do to (or at least, the thing we've done before in
 this situation), is for a couple of us to update all of our build tools,
 check that things still work if we update the dependency requirement, and
 then update those requirements. We've taken the stance before that it's not
 too far out of line to ask developers to be using the latest tools
 available.

 (Of course, if things *don't* work after updating build tools, then lets
 get that fixed ASAP.)

 Ian


 Joe

Re: Plugins blog post review

[Ian Clelland]

PR sent :)

I cleaned up a lot of the change log. I'll go back through the plugins
themselves to update the README files, too. (We really need to get better
at our commit messages)

Sorry, I'm not in CA this week. Have fun!

Ian

On Tue Dec 09 2014 at 12:34:03 AM Steven Gill stevengil...@gmail.com
wrote:

 https://github.com/cordova/apache-blog-posts/blob/master/
 2014-12-08-plugins-release.md

 PRs welcomed. Sorry didn't get it out sooner. Am attending JSFEST right now
 in Oakland (no wifi). Anyone else attending?

Re: Plugins blog post review

[Ian Clelland]

And going over the list, I realized that I didn't merge in the
whitelist-breakout-compatibility changes in file-transfer and inappbrowser
:(

Oh well, I suppose I can volunteer to release those two next week.

Ian

On Tue Dec 09 2014 at 9:28:45 AM Ian Clelland iclell...@chromium.org
wrote:

 PR sent :)

 I cleaned up a lot of the change log. I'll go back through the plugins
 themselves to update the README files, too. (We really need to get better
 at our commit messages)

 Sorry, I'm not in CA this week. Have fun!

 Ian


 On Tue Dec 09 2014 at 12:34:03 AM Steven Gill stevengil...@gmail.com
 wrote:

 https://github.com/cordova/apache-blog-posts/blob/master/201
 4-12-08-plugins-release.md

 PRs welcomed. Sorry didn't get it out sooner. Am attending JSFEST right
 now
 in Oakland (no wifi). Anyone else attending?

Re: 4.0 Sprint Tasks (Another Hey, let's ship 4.0.x soon post)

[Ian Clelland]

On Sun Dec 07 2014 at 11:54:29 PM Joe Bowser bows...@gmail.com wrote:

 Hey

 After messing with the JS for a week, I decided for now to stop work on
 MozillaView.  I think I've managed to prove that the concept is at least
 possible, but I really feel that it's still too unstable to actually show
 past a demo/POC at this time.  We've definitely learned some lessons, and
 I'll probably write a blog post on them soon, and pick up work in the new
 year.


I'm glad that it's at least possible, even if it's not trivial. Do you
think there are any other changes we'll need to make -- hooks that we'll
need to provide -- before that project can be called a success? If so, I'd
want to at least consider making those changes for 4.0, so we don't have to
make another major version bump for MozillaView.



 That said, we should really concentrate on shipping 4.0 in January, we
 should do the following:

 1. Bump up the targeted version to 5.0
 2. Allow for users to target KitKat for Quirks Mode (I'm not kidding,
 Quirks mode is back.  Chrome is the new IE! WTF MAN!)


Hasn't Android always done that? I thought that was the whole point of
targetSdkVersion (maybe not webview specifically, but device quirks in
general). Anyway, +1 to letting the developer set it if necessary.


 3. Get the gradle work in.  MUCH FASTER! LESS SPAM! WOW!


It's pretty much all in, and should be the default in 4.0 (I'll check that
to make sure it's true). The last piece is the AAR library support, which
I'm going to test and merge this week.

4. Get the JUnit tests working with Gradle/Android Studio.  I don't think
 this is a 4.0 task per-se, but we should do it right after 4.0 is released.
 5. Stare at the pie chart wishing that 9 was 5.  (Anyone who knows our
 deprecation policies knows EXACTLY what I'm talking about).

 I do have one API change I want to make.  I want to rename the
 CordovaWebView interface CordovaWebInterface so that it's obvious that it's
 an interface.  Since people using the old CordovaWebView embedded feature
 are going to have to do a find/replace on the XML, this doesn't really
 matter.


If you're convinced that it's not going to cause any additional pain for
the developers, then I say go for it. It makes more sense as a name (It's
messed me up more than once, looking for the *actual* view class)


 Of course, the people using this feature may beg to differ.  If
 you're using this feature, and you care about it still working with your
 current code, PLEASE TEST 4.0 NOW.


Strongly agreed.




 Thoughts?

 Joe

Re: [Android] MozillaView Update: PoC is working

[Ian Clelland]

That's great news, Josh - glad to hear another positive data point :)

I'll look at the code again today, (and maybe Andrew can weigh in faster
than I can figure it out) but I think that there is a solution to the
minSdkVersion issue in the gradle config; possibly involving a build-extras
file.

On Mon Dec 08 2014 at 11:39:11 AM Josh Bavari jbav...@gmail.com wrote:

 Joe and Ningxin,

 I'd love to focus fire the help in testing. I work with Ionic, and we'd
 love to assist in having Cordova with pluggable webviews for Android.

 Since I'm not as well caught up as everyone else, I could use a little help
 with direction.

 As far as Cordova 4.0, I've been using that 4.0.x branch to work with the
 cordova-crosswalk-engine, and I can offer some results and testing from
 that.

 How can I help moving forward? I can confirm gradle worked (other than the
 minimum sdk version issue Ningxin also had), the plugin loaded, and I could
 access some of the core cordova plugin functionality.

 I'd love to help with a little more direction, please advise!

 On Sun, Dec 7, 2014 at 11:14 PM, Hu, Ningxin ningxin...@intel.com wrote:

  Hi Joe,
 
   Crosswalk doesn't work the same way as the default AndroidWebView and
   MozillaView from my experience, so some of the tests wouldn't work for
 it
   and are specific to the default WebView.  These would be all the JUnit
  tests
   related to embedding the webview.  I think these tests should remain
 for
   Cordova, but Crosswalk needs to have its own JUnit tests.
  
 
  Agree. From crosswalk plugin perspective, we at least need to test the
  CordovaWebView interface and plugin interface.
 
  
   
I think it makes sense to release the crosswalk plugin against
Crosswalk stable channel every 6 weeks.
   
Any thoughts on above items?
   
   
   I agree!  This sounds like a good idea once the JUnit tests are figured
  out.
  
 
  Sounds great! We will focus on the JUnit tests of crosswalk plugin first.
 
  Thanks,
  -ningxin
 
   Joe
  
  
  
Thanks,
-ningxin
   

  Best regards,
  -ningxin
 
   -Original Message-
   From: Carlos Santana [mailto:csantan...@gmail.com]
   Sent: Thursday, November 27, 2014 11:30 AM
   To: dev@cordova.apache.org
   Subject: Re: [Android] MozillaView Update: PoC is working
  
   Great news Joe. I agree with the time statement, post vacation
  time.
   Allows time for doc, test, and logistics for release.
  
   Documenting some guides on what these two plugins means for
   developer in terms of features, support and handling a single
   project that wants to target Android 2.3 + Android 4.x.
   Instrumenting test framework to test integration between
   cordova-andoird and plugins.
   Also discuss how the release cycle will work. Who owns what?
   From what I little understand is that cordova-android remains
   ASF and owned by Apache Cordova. But this cordova-android is a
   new version that has an API to support plugins that replace the
   OS web
view.
  
   The plugins are not owned by ASF/Apache Cordova, we just need
 to
   document and support a stable API. And the gecko view plugin
   will be
  owned
   by Mozilla outside ASF, and crosswalk owned by Intel outside
 ASF?
  
  
   On Wed, Nov 26, 2014 at 7:58 PM, Ally Ogilvie
   aogil...@wizcorp.jp
  wrote:
  
Thoughts?
   
That. Is. Awesome.
   
How far back can you target Android?
   
   
On Thu, Nov 27, 2014 at 9:08 AM, Joe Bowser
bows...@gmail.com
 wrote:
   
 Hey

 Just an update, I have a working PoC of the GeckoView-based
 WebView ready for people to look at here:

 https://github.com/infil00p/cordova-mozillaview-engine

 This is definitely a very different webview than what we
 have had currently, and I've had to re-think a lot of how
 we
 do things with
Cordova
 because of it.  The asynchronous bridge that uses promises
 is very interesting on GeckoView, as well as how this is
 properly
 sandboxed.
 I like it a lot better than how Chrome based web-views are
 currently
working
 with just bolting on an synchronous object.  However, due
 to
 time, and because I didn't want to repaint the bike shed
 again, I kept the basic bridge architecture mostly intact.

 At any rate, from the initial tests, the bridge works and
 the plugins are mostly intact.  I override the exec with
 clobbers, and while I haven't
run
 Mobile-Spec against the plugin version, the fact that it
 fires tells me that the clobbers probably will work.

 I am really worried about the Splashscreen and how we show
 and hide the webviews, since this was found to be 

Re: WebView Promise and W3C standards

[Ian Clelland]

I have two reasons for not wanting this as a plugin (both of which, I'm
sure, are entirely subjective)

The biggest one is just that native support for this really is coming
quickly, and one day, we'll be able to remove it, because just about every
platform that we care about will have support built in. Those that don't
can have the polyfill included as part of *their* cordova.js, and the
modern platforms can run without it.

If, by the time we get there, there are a hundred plugins that all depend
on org.apache.cordova.promise, then we have no choice but to maintain that
plugin, and we have to tell people to include it, and depend on it, even
when 95% of devices have native support. On the other hand, when we stop
supporting iOS 7, if we have included the polyfill in cordova-ios.js, then
we just remove it, and nothing at all changes for anyone else. Plugin
developers, application developers, even core Cordova developers who have
been relying on the polyfill for support, just see everything continue to
work, and Cordova is lighter as a result.

The second reason is that I can already see things in Cordova itself that
I'd like to write in a promise style. I'd love to replace the deviceready
event with something like

cordova.deviceReady().then(function() {
do stuff
}, function() {
  handle error
});

and even

cordova.exec(Plugin, arguments).then(successCallback).;

This requires support before plugins load, though. (And I accept that not
everyone is going to agree with the design)


On Fri Dec 05 2014 at 3:04:46 PM Max Woghiren m...@chromium.org wrote:

 I can easily change to expanded (non-minified) code; I went with smaller
 size, expecting that people wouldn't be wanting to inspect the promise
 polyfill code.  No big deal.

 Earlier in this very thread, people (Jesse included) asserted that it
 should be in core, and Andrew outlined rationale.  I was trying to make
 progress on a task that seemed like a go-ahead and was then left hanging.
 If enough people believe it should be a plugin, then we can certainly go
 that way.  Looking forward to more input.

 On Fri, Dec 5, 2014 at 2:10 PM, Jesse purplecabb...@gmail.com wrote:

  We would be mandating its support, we have plenty of issues in Jira,
  and this solves none of them.
  ... and minified code? Why? How can I evaluate it?
 
  My mantra is and will remain Plugins are everything, and everything
  is a plugin
  What is the inconvenience in having a dependency on a promise plugin?
  I don't see the downside, and I think it would be perfect for those
  who want to use it.
 
  Personally I think we should be pushing the browserify functionality
  in cordova-js, and ripping stuff out, not adding it.
 
 
   On Dec 5, 2014, at 9:59 AM, Max Woghiren m...@chromium.org wrote:
  
   I think it's nice to remove that obstacle from in front of plugin
   developers who want to use promises.  If we're going to suggest that
  people
   drop the polyfill in themselves, I don't see the harm in just having it
   there, especially if we don't mandate its use.
  
   Going forward, many/most APIs will use promises; it might get a little
   unwieldy to have a whole bunch of plugins depend on a promise plugin.
  
   The bottom line, for me, is that this doesn't force anyone to use
  promises;
   it's just easy and there for those who want it.
  
   On Fri, Dec 5, 2014 at 12:11 PM, Jesse purplecabb...@gmail.com
 wrote:
  
   Nice, but please don't add this.
   Anyone who wants or needs this can do what you did, and if I start
  seeing
   promise code throughout Cordova.js I may run.
  
   We should be looking to get rid of Cordova.js entirely, not add more
  deps.
  
   Why not a promise plugin?
  
   Fyi: promises invoke my fight or flight response, and I have only
 found
   them useful for blocking contribution. That said, they already exist
 in
   windows8.1 as part of winjs.
  
  
   Sent from mobile
  
   On Dec 5, 2014, at 8:40 AM, Max Woghiren m...@chromium.org wrote:
  
   I've created a topic branch called promise
   
  
  https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=
 shortlog;h=refs/heads/promise
  
   to cordova-js.  It has a commit that adds this ES6 promise polyfill
   https://github.com/jakearchibald/es6-promise (minified) to
  cordova.js
   and
   a simple test to ensure it's found.
  
   That's literally all it is right now—please take a look, though.
 Shall
   we
   move forward on this?
  
   On Thu, Aug 14, 2014 at 9:35 AM, Bryan Higgins 
 br...@bryanhiggins.net
  
   wrote:
  
   BB10 does have a native secure element API. I may be able to dig up
  some
   code which bridges this to JavaScript.
  
  
   On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker 
 ignisvul...@gmail.com
   wrote:
  
   I created https://issues.apache.org/jira/browse/CB-7310 to track
  this.
  
  
   2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:
  
   Good to know. Thanks.
   Am 13.08.2014 20:56 schrieb Josh Soref 

Re: [VOTE] Plugins Release Dec 2, 2014

[Ian Clelland]

+1

* Verified archive contents against public repos at the matching hashes
* Verified signatures of release packages
* Ran mobile spec on Android (5.0, 4.4.4) and iOS (6.0, 7.0.6 and 8.0.2)

On Tue Dec 02 2014 at 7:18:35 PM Steven Gill stevengil...@gmail.com wrote:

 Please review and vote on the release of this plugins release.

 Release issue: https://issues.apache.org/jira/browse/CB-8110

 The plugins have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8110/

 The packages were published from their corresponding git tags:
 cordova-plugin-battery-status: 0.2.12 (ec59ef11a5)
 cordova-plugin-camera: 0.3.4 (2045e0a644)
 cordova-plugin-console: 0.2.12 (9e57b0d5c3)
 cordova-plugin-contacts: 0.2.15 (1347f12868)
 cordova-plugin-device: 0.2.13 (a0e4edceb1)
 cordova-plugin-device-motion: 0.2.11 (110b27671f)
 cordova-plugin-device-orientation: 0.3.10 (eef90c5659)
 cordova-plugin-dialogs: 0.2.11 (d7e34c28b7)
 cordova-plugin-file: 1.3.2 (d2c00a155b)
 cordova-plugin-file-transfer: 0.4.8 (04e114e055)
 cordova-plugin-geolocation: 0.3.11 (0db6fd9952)
 cordova-plugin-globalization: 0.3.3 (65db106599)
 cordova-plugin-inappbrowser: 0.5.4 (b9653af691)
 cordova-plugin-media: 0.2.15 (b8088cd6c8)
 cordova-plugin-media-capture: 0.3.5 (9f8d409aa0)
 cordova-plugin-network-information: 0.2.14 (17a38609fb)
 cordova-plugin-splashscreen: 0.3.5 (67e8b9f01d)
 cordova-plugin-statusbar: 0.1.9 (e445123e4c)
 cordova-plugin-vibration: 0.3.12 (57c92693fe)

 Upon a successful vote I will upload the archives to dist/, upload
 them to the Plugins Registry, and post the corresponding blog post.

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and
 subdependencies have Apache-compatible licenses
 * Ran mobile spec on my android. It passed

Re: [Discuss] Plugins release

[Ian Clelland]

+1, I heartily support this.

I'll take a look at the PRs and call out any that I think need extra
consideration. (We here in Canada can spend some time on Thursday and
Friday merging some of them in :) )
On Mon Nov 24 2014 at 5:28:51 PM Steven Gill stevengil...@gmail.com wrote:

 I want to do a plugins release next Monday, Dec 1. (Thursday/Friday are
 holidays in the states).

 I will review PRs the next few days, please bring any that you deem
 important to my attention.

Re: Introduction

[Ian Clelland]

Welcome, Daniel!

That's a really interesting project -- I'm looking forward to trying that
out. How much work (if any) has gone in to the OSX or Linux components?

Do you see this eventually becoming a first-class Cordova platform, or do
you have different plans for it?

Ian

On Tue Nov 25 2014 at 1:47:27 AM Toplak Daniel d.top...@cadenas.de wrote:

 Hi,

 my name is Daniel Toplak, I am the team leader of the mobile development
 department of CADENAS GmbH, Augsburg, Germany, http://www.cadenas.de.
 We are using Cordova for our mobile app development since phonegap 2.6.
 We have signed the CCLA, and created an account on Jira.

 I have a cordova implementation based on CEF (Chromium Embedded Framework)
 which is not yet production ready, but more a proof of concept:
 https://github.com/hsimpson/cordova-cef (my private github account)

 I'm following the dev list long ago and happy to contribute to a great
 project.


 Mit freundlichen Grüßen / Best regards

 CADENAS GmbH
 Head of Mobile Development
 Daniel Toplak

Re: Firefox OS problem

[Ian Clelland]

What was the actual problem, John?

(I'm worried that I may be a similar sort of user; I'm seeing almost
exactly the same result trying to add the browser platform, even with the
latest tools)

On Mon Nov 24 2014 at 5:13:03 PM Michal Mocny mmo...@chromium.org wrote:

 [[Stupid User] Problem] or [Stupid [User Problem]] ? ;)

 On Sat, Nov 22, 2014 at 6:32 AM, John M. Wargo jwarg...@gmail.com wrote:

  Nevermind. Stupid User Problem.
 
 
 
   Original Message 
  Subject:Firefox OS problem
  Date:   Fri, 21 Nov 2014 21:27:40 -0500
  From:   John M. Wargo jwarg...@gmail.com
  To: Cordova Dev dev@cordova.apache.org
 
 
 
  Guys,
 
  There seems to be a problem with the Firefox OS platform:
 
  C:\Users\jwargo\dev\ac4p\compasscordova platform add firefoxos
  npm http GET https://registry.npmjs.org/cordova-firefoxos/3.6.3
  npm http 401 https://registry.npmjs.org/cordova-firefoxos/3.6.3
  Unable to fetch platform firefoxos: Error: unauthorized Name or password
  is incorrect.: cordova-firefoxos/3.6.3
 
  C:\Users\jwargo\dev\ac4p\compass
 
 
  Some sort of password problem with npm?
 
  --
  John M. Wargo
  @johnwargo http://twitter.com/johnwargo
  www.johnwargo.com http://www.johnwargo.com
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  --
 
  --
  John M. Wargo
  @johnwargo http://twitter.com/johnwargo
  www.johnwargo.com http://www.johnwargo.com
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  --
 
 
 

Re: [iOS 8] WKWebView moving forward

[Ian Clelland]

On Tue Nov 18 2014 at 2:00:34 PM Jesse purplecabb...@gmail.com wrote:

 Shaz's solution has less impact and seems more elegant.

 // if ([self respondsToSelector:@selector(nativeFullPath:)]) {

 If no-one ( generically ) has provided the nativeFullPath method, then use
 it as is, otherwise call it.
 No need for any (direct) dependency between File + LocalServer.


My first instinct, looking at the code, was that it was wrong, exactly
because there *is* a dependency. You don't normally add code to a base
class to change its behaviour when there is a category defined on it.
Normally that goes the other way: when you add a category to a base class,
all of the code that's relevant to that category is *in the category*, and
the base class needs to know nothing at all about it, including its
existence.

As I said in the PR, it may be that this really is the cleanest and best
way to go forward with this; I just wanted to have this discussion and
figure it out with the community before committing to any
hard-to-change-later technical debt. It does become an API surface, and we
will have to maintain whatever we adopt.

Ian



 @purplecabbage
 risingj.com

 On Tue, Nov 18, 2014 at 10:42 AM, Andrew Grieve agri...@chromium.org
 wrote:

  Having the localserver plugin add behaviour to file plugin feels like the
  dependency is in the wrong direction to me.
 
  How about having CDVFile.m do something like:
 
  CDVPlugin* p = [commandDelegate getCommandInstance:@LocalServer];
  if (p != nil) {
nativeURL = [p transformURL:nativeURL]; // do some local declaration to
  make this not complain about unrecognized selector
  }
 
  Would probably also need an untransformURL to go the other direction as
  well.
 
  On Tue, Nov 18, 2014 at 12:05 AM, Shazron shaz...@gmail.com wrote:
 
   Filed https://issues.apache.org/jira/browse/CB-8032 with pull request
   included.
  
   On Mon, Nov 17, 2014 at 2:47 PM, Shazron shaz...@gmail.com wrote:
  
Sorry I should have looked into the File API code first (no
 JavaScript
changes, that would not work).
   
Essentially I need to override this line from my plugin:
   
  
  https://github.com/apache/cordova-plugin-file/blob/
 82f803ea0d61cde051dcffd27b21dc0ed92a0fdf/src/ios/
 CDVAssetLibraryFilesystem.m#L74
(plus the CDVLocalFileSystem equivalent).
   
Since Obj-C categories can't really override methods (behavior
undefined), and I don't want to do some runtime swap implementation
   voodoo,
I would replace the line above with something like:
   
NSString* nativeURL = [NSString stringWithFormat:@
assets-library:/%@,fullPath];
if ([self respondsToSelector:@selector(nativeFullPath:)]) { // some
unique selector name perhaps
 nativeURL = [self nativeFullPath:fullPath]; // this code won't
compile, pseudo-code for now. Will call my category method defined in
  my
plugin for CDVAssetLibraryFileSystem
}
dirEntry[@nativeURL] = nativeURL;
   
Backwards compatible.
   
   
On Mon, Nov 17, 2014 at 1:44 PM, Shazron shaz...@gmail.com wrote:
   
Local Web Server Checklist:
1. We have random port usage
2. We have the token/cookie check
3. We have the localhost check
4. The app is now installed under http://localhost:RANDOM_PORT/www/
   
It'll be easy (relatively) to add  support for:
http://localhost:RANDOM_PORT/asset-library/
http://localhost:RANDOM_PORT/file-system/
   
The only issue now is changing FileEntry.toURL(). I'm thinking of
 some
runtime 'magic' in the local web server where it detects the File
   plugin,
and change the implementation of FileEntry.toURL() (or through
  injecting
JavaScript, probably easier).
   
   
On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve 
 agri...@chromium.org
wrote:
   
We could restrict access to the webserver by stuffing a cookie into
  the
webview with an access token, then have the server just 500 on any
request
missing the cookie. We should also be able to restrict external
   requests
just by listening on 127.0.0.1 instead of 0.0.0.0 (doesn't look
like GCDWebServer supports this, but we can hack it in).
   
The problem of port conflicts is annoying though. Maybe we try
 random
ports
until one works? Is there any need to use the same port for
 multiple
runs?
   
The CORS thing is sad, because it also means things like Camera
  plugin
will
be broken (can't use resulting URL in img).
   
Although we might just do (this is different than the current
 mapping
   in
the plugin):
http://localhost:RANDOM_PORT/www
http://localhost:RANDOM_PORT/asset-library
http://localhost:RANDOM_PORT/file-system
   
to proxy the three locations.
   
This also means we can't use FileEntry.toURL() and have it work,
  unless
toURL returns http://localhost:RANDOM_PORT/file-system/...   Maybe
that's
fine?
   
   
I don't think it's weird that an app will need to 

Re: [GitHub] cordova-plugin-file-transfer pull request: CB-7944 Pending unsuppo...

[Ian Clelland]

Looks good, thanks! I've pushed it up to master.

On Fri Nov 14 2014 at 8:11:27 AM MariaBukharina g...@git.apache.org wrote:

 Github user MariaBukharina commented on the pull request:

 https://github.com/apache/cordova-plugin-file-transfer/
 pull/48#issuecomment-63062423

 Thaks for you comments!
 I've fixed small formatting issues. Please review, if everything ok
 now?


 ---
 If your project is set up for it, you can reply to this email and have your
 reply appear on GitHub as well. If your project does not have this feature
 enabled and wishes so, or if the feature is enabled but not working, please
 contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

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

Re: I've fixed an issue. What's next?

[Ian Clelland]

Well, I think what you've just done (pinging the list) is pretty close to
the right next step.

You should probably assign the issue back to Shaz with a note directed to
him asking him to take a look and merge it in. (I'd merge it, but I haven't
been following iOS 8 development closely enough to judge its correctness)

And thanks for taking it on!

Ian

On Fri Nov 14 2014 at 2:32:14 AM julio cesar sanchez jcesarmob...@gmail.com
wrote:

 CB-7734 (https://issues.apache.org/jira/browse/CB-7734) was reported and I
 asked if it could be assigned to me.
 Shazron assigned to me and I fixed it with this pull request
 https://github.com/apache/cordova-plugin-dialogs/pull/39

 It's been 3 weeks and it hasn't been merged, so I don't know if I have to
 do something else, it's the first issue assigned to me.

Re: I've fixed an issue. What's next?

[Ian Clelland]

On Fri Nov 14 2014 at 2:24:41 PM Shazron shaz...@gmail.com wrote:

 General question to everybody:

 The patch requires the iOS 8 SDK (i.e. Xcode 6). We require Xcode 6 in
 cordova-ios 3.7.0 and there was consensus on it.
 However, the plugin.xml itself does not have an engine tag to specify what
 it supports.

 Question:
   Do we have engine tag support in the CLI, where it won't install a
 plugin if the requirements are not met?


We certainly do, for Android at least -- I've been using it for Crosswalk
development, and it works  (I get caught every time I switch back to
master, and the crosswalk plugin refuses to install :) )



 If not, we would have to do a #ifdef __IPHONE_8_0 macro in the code.


 On Fri, Nov 14, 2014 at 11:18 AM, Shazron shaz...@gmail.com wrote:

 Thanks Julio!
 I'll comment on the PR itself.

 Shaz

 On Fri, Nov 14, 2014 at 8:42 AM, Ian Clelland iclell...@chromium.org
 wrote:

 Well, I think what you've just done (pinging the list) is pretty close
 to the right next step.

 You should probably assign the issue back to Shaz with a note directed
 to him asking him to take a look and merge it in. (I'd merge it, but I
 haven't been following iOS 8 development closely enough to judge its
 correctness)

 And thanks for taking it on!

 Ian


 On Fri Nov 14 2014 at 2:32:14 AM julio cesar sanchez 
 jcesarmob...@gmail.com wrote:

 CB-7734 (https://issues.apache.org/jira/browse/CB-7734) was reported
 and I
 asked if it could be assigned to me.
 Shazron assigned to me and I fixed it with this pull request
 https://github.com/apache/cordova-plugin-dialogs/pull/39

 It's been 3 weeks and it hasn't been merged, so I don't know if I have
 to
 do something else, it's the first issue assigned to me.

Re: Whitelist breakout update

[Ian Clelland]

Sorry for dropping this thread for a week; let me see if I can address that
--

By default, for brand new apps created with Cordova 4.x with no plugins,
those will be blocked (this includes protocols like tel: and mailto:) .
This was considered to be a security issue earlier this year, and we put
measures unto Cordova 3.5.1 to ensure that Cordova apps couldn't launch
other intents without the app author's cooperation. (This makes Cordova
apps a bit more like native apps, and a bit less like websites, when
displaying external content, which is probably a good thing re: security)

If you add the cordova-legacy-whitelist plugin, then you get back exactly
the same level of control that you had with Cordova, say, 3.7.0, and the
goal is that you don't have to do anything else to get backwards
compatibility. If you find any regressions, bring them up on the list or in
JIRA, and we should be able to resolve them. (Hopefully before 4.0.0 is
released).

Any other behaviour that you need should be possible through a plugin;
whether that means a custom one for your app, or something from the
community that hundreds of other devs use, I don't know :)

On Tue Nov 04 2014 at 11:11:57 AM Frederico Galvão 
frederico.gal...@pontoget.com.br wrote:

 I understand and am already familiar with the configuration for external
 URLs that do not interfere/launch third party apps or intents.
 I just want to understand better what's gonna happen with the custom
 protocols I call, like tel: or mailto:, or even URLs that have custom
 handlers on each platform.

 2014-11-04 14:03 GMT-02:00 Ian Clelland iclell...@chromium.org:

  On Tue Nov 04 2014 at 10:46:52 AM Frederico Galvão 
  frederico.gal...@pontoget.com.br wrote:
 
   So we actually have 4 new plugins:
   org.apache.cordova.whitelist
   org.apache.cordova.legacy-whitelist
   org.apache.cordova.navigation-whitelist
   org.apache.cordova.intent-whitelist
  
 
  I think that org.apache.cordova.legacy-whitelist is a better name for
 what
  I have published at https://github.com/clelland/cordova-plugin-whitelist
  as
  org.apache.cordova.whitelist.
 
  So where I had a single plugin implementing the old behaviour, Andrew has
  suggested releasing three plugins: legacy-whitelist, which is what I
  implemented; and two new ones: navigation-whitelist, which implements
  navigation control, and intent-whitelist, which would control launching
  external apps.
 
  (And there's also the very sound advice of just skip the whitelist
 plugins
  and use CORS if you can get away with it)
 
  
   Right?
  
   If that's the case, then this is not entirely true:
  
   If what
you want is no change at all in behaviour, then your upgrade should
 be
just:
   
cordova plugin add org.apache.cordova.whitelist
   
There would be no configuration changes to make: the plugin reads the
  old
access tags, just as before, and applies the same policies based on
  them
that it did in 3.6.
   
  
 
 
  The messaging is still simple, if all you want is backwards
 compatibility,
  but if you want something better, then the instructions are more
  complicated, and depend on your actual needs.
 
 
  
   2014-11-04 2:13 GMT-02:00 Andrew Grieve agri...@chromium.org:
  
Since the whitelist plugin blocks only a subset of sub-resource loads
   (just
like the existing whitelists), I think we really want to call out
 that
people should not just include the backwards-compatible plugin.
 Here's
  a
stab at messaging:
   
   
If you want nothing to change, use org.apache.cordova.legacy-
 whitelist.
   If
you care about security, then please understand that there are three
   types
of whitelists to consider:
   
1. Network traffic - The whitelist has never been able to fully block
  all
network requests in this manner (on iOS and Android). Instead, we
   recommend
using meta http-equiv=Content-Security-Policy content=[POLICY
 GOES
HERE] in your head, which is supported on Android 4.4 and iOS 7.
   
2. Navigation - By default the webview is allowed to navigate to any
  page
within the same directory tree as the start page. If you'd like to
   navigate
to a different directory, or to a http(s) address, then you should
 use
org.apache.cordova.navigation-whitelist.
   
3. Intents - By default all URLs that cause an external action (e.g.
   tel:,
sms:, etc) are disabled. If you need to use any of these, then you
  should
use org.apache.cordova.intent-whitelist.
   
   
On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland 
 iclell...@chromium.org
wrote:
   
 On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard cmarc...@gmail.com
 
wrote:

  This sounds very interesting and relatively graceful.
 
  For a user upgrading to this new world, what would the migration
   steps
  look like? Or in other words, what would a rough sketch of the
   upgrade
  guide for this look like? The reason I ask is to see how much

Re: Suggestion: Warning about usage of patterns that conflict with the Firefox OS CSP

[Ian Clelland]

I'm not familiar enough with the FirefoxOS architecture, but on Android, we
had also considered the possibility of injecting a Content-Security-Policy
in the response header for the application's start page -- this would be
more secure, arguably, than a meta tag. The biggest problem is that that
trick only works on the initial page load; if you have a multi-page app,
then you don't get the chance to do that for subsequent pages, but that's
an android-specific limitation.

(It's something that we will be able to do soon for iOS, since it looks
like we're going to control the entire HTTP process.)

On Wed Nov 12 2014 at 8:54:23 AM Frederik Braun fbr...@mozilla.com wrote:

 Response inline

 On 12.11.2014 14:35, Michal Mocny wrote:
  We could add meta http-equiv=Content-Security-Policy content=.. to
  the default template, or create a plugin that injects it automatically
 and
  try to get developers to install that plugin.
 
  This has some benefits for security of cordova apps and has been brought
 up
  on these lists in that context (very recently by Ian's whitelist -
 plugin
  thread).
 

 Meta CSP is quite a nice idea, yet we're unfortunately lacking support
 in Firefox (and Firefox OS) so far
 (https://bugzilla.mozilla.org/show_bug.cgi?id=663570).

 I was thinking that some sort of early feedback (i.e. build step
 warning) could help avoiding these patterns when app developement has
 *just* started.

  Finally, perhaps you can use the `vulcanize --csp` tool to externalize
  scripts automatically? (This issue applies to chrome apps, and vulcanize
 is
  used to solve the problem with web component inline scripts).
 

 That's an interesting suggestion, thanks!



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

Re: plugin.xml config-file for json files

[Ian Clelland]

Relevant existing work:
https://tools.ietf.org/html/rfc6902 - JSON Patch
https://github.com/benjamine/jsondiffpatch - JSON diff / patch -- not sure
if it uses the same format as the RFC


On Tue Nov 11 2014 at 2:38:11 PM Jesse purplecabb...@gmail.com wrote:

 Adding json-file would/could lead to the deprecation of the xml config
 files, but ultimately we will always need to write xml anyway, so this just
 adds functionality.
 Given that it is just an added tag, and matching worker module, this has
 near zero impact on the existing system.

 Modification of elements is supported in xml, optimistically, assuming
 there are never conflicts. This is especially important for things like
 plist modification, where most values are specified as defaults.




 @purplecabbage
 risingj.com

 On Tue, Nov 11, 2014 at 11:18 AM, Michal Mocny mmo...@chromium.org
 wrote:

  I'd also recommend hooks for now.
 
  json-file tag sounds potentially more resilient to change, but since
 you
  have to explicitly reference the path to target I don't think its any
  better in practice.
 
  Additionally, we've expressed interest in replacing our xml based configs
  with json manifests, and while that work may not be in a hurry, it seems
  counterproductive to extend the scope of plugin/app configs right now.
 
  -Michal
 
  On Tue, Nov 11, 2014 at 2:09 PM, Axel Nennker ignisvul...@gmail.com
  wrote:
 
   I would not modify the value. Can config-file replace values?
   Just adding stuff would be good enough for my (current) purposes.
   I would throw on existing keys.
   When two plugins add the same key then plugman should throw and I don't
   want to track all changes over all plugins.
  
   2014-11-11 19:58 GMT+01:00 Jesse purplecabb...@gmail.com:
  
I would like to see a new element titled 'json-file' and matching
  parser
that does the work.
something like this?
   
json-file target=someManifest.json parent=some.object.path
{the:{stringValue:2,b:added},or:{modified:true}}
/json-file
   
   
@purplecabbage
risingj.com
   
On Tue, Nov 11, 2014 at 9:02 AM, Shazron shaz...@gmail.com wrote:
   
 Have you considered plugin hooks?
 I just implemented this yesterday to modify the root config.xml
 file:


   
  
  https://github.com/apache/cordova-plugins/blob/master/
 local-webserver/plugin.xml

 On Tuesday, November 11, 2014, Axel Nennker ignisvul...@gmail.com
 
wrote:

  Hi,
 
  if I remember correctly then this was discussed before but I
 can't
   find
 the
  email exchange.
 
  We are trying to use our cordova app on firefoxos and would like
 to
 modify
  manifest.webapp which is a json file.
 
  In plugin.xml we can only modify xml files using the config-file
element.
 
  What are your preference on how to implenent this?
  - reuse config-file with new attribute type=json (default
 xml)
or new element e.g. config-file-json
  - only adding to the json and throw if key already exists?
  - ...
 
  Should I file an issue and implement it?
 
  cheers
  Axel
 

   
  
 

Re: Review: Tools Release blog post

[Ian Clelland]

Are there any changes at all to plugman that necessitate its release, or is
it just being released so that there's a version that uses the new
cordova-lib? It seems odd that it's in the announcement, but missing from
the releasenotes.

On Fri Nov 07 2014 at 5:22:51 PM Mark Koudritsky kam...@google.com wrote:

 Please review and send PRs!
 https://github.com/kamrik/apache-blog-posts/blob/master/
 2014-11-10-tools-release.md

Re: cordova 64-bit support

[Ian Clelland]

I know that's been our Android policy; I though that iOS was roughly we
support the current release and the one previous release, which would mean
that we're already good to start just supporting iOS 7 and 8 exclusively.

(Not that it's a big difference -- a 1-month delay is about what it would
take to get another cordova-ios release out anyway :) )

On Mon Nov 10 2014 at 10:30:35 AM Michal Mocny mmo...@chromium.org wrote:

 Our policy has historically been to drop support if usage is under 5%.
 There some amount of leeway in judgement here as well: is it trivial to
 continue support or causing us pain?

 For iOS, 5% of usage comes from iOS6 or below as reported by
 https://developer.apple.com/support/appstore/.  I'd venture and say thats
 almost all iOS 6, which puts us right on the border.

 That said, the support story for cordova is: all existing apps continue to
 work, if you want to target the older platform you can continue to use an
 older cordova-ios, so I think we can be bold here.  1 more month of iphone
 sales and itll be 5% usage for iOS6 ;)

 -Michal

 On Sun, Nov 9, 2014 at 6:20 PM, julio cesar sanchez 
 jcesarmob...@gmail.com
 wrote:

  Apple just says earlier 5%. That should be iOS 5 and iOS 6
 
  El domingo, 9 de noviembre de 2014, Terence M. Bandoian 
 tere...@tmbsw.com
  
  escribió:
 
   It might make sense to consider dropping support for an iOS version
 when
   usage, as reported by Apple, drops below a certain level.
  
   -Terence Bandoian
  
  
   On 11/8/2014 5:13 PM, julio cesar sanchez wrote:
  
   iOS 5 support was removed on cordova 3.5, released on may 2014, I
 think
   it's too soon to remove iOS 6 support with all the devices left behind
   (iphone 3gs and ipod touch 4gen), just to add swift plugins.
  
   I'm ok with dropping support to old versions when there are real
   advantages
   or security reasons.
  
   I'm limited on resources too, but I volunteer to test on my ipod touch
  
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
   For additional commands, e-mail: dev-h...@cordova.apache.org
  
  
 

Re: cordova 64-bit support

[Ian Clelland]

The question doesn't reference any particular platform, for one. Is this a
Windows phone question? An iOS question? Android? Workstation? There's no
actual answer to it, as stated.

I totally agree that we should document which platforms support / require
64-bit binaries, along with what we support in general, it's just that, as
Joe said, we need more into to answer the original question.

iOS supports 64-bit devices (as of 3.4.1). I haven't looked to see whether
the compiled binaries are 64-bit, or if they're 32-bit but run on both
arm32 and arm64.

Android is a Java platform, and so doesn't care about 32- or 64- bit width
at the level that Cordova operates on. The crosswalk plugin includes native
code, and that code is 32-bit on both ARM and x86 right now. I haven't
tested on a 64-bit device yet, but I expect that the libxwalkcore.so
library will at least load on them.

Other people can chime in on other platforms, if what I've written isn't
what the original question was about.

On Fri Nov 07 2014 at 10:56:54 AM Josh Soref jso...@blackberry.com wrote:

 Vadiraj V wrote:
  I would like to know if cordova supports 64-bit - if so, from which
  version it supports and any supporting documentation exists. Thanks.

 Joe Bowser wrote:
  Can you be more specific?
  I'm not sure what you're asking.

 http://cordova.apache.org/docs/en/4.0.0/guide_support_index.
 md.html#Platfor
 m%20Support
 http://cordova.apache.org/docs/en/4.0.0/guide_support_index.md.html#Platform%20Support


 Doesn't include any reference to 64bit.

 It's a reasonable question.
 Are the apps that are generated, 32bit or 64bit or both (as applicable)?

Re: Let's try to release Cordova-Android 4.0.x soon

[Ian Clelland]

I'd love to see us get that out.

Ideally, I'd like to see both the pluggable webviews and pluggable
whitelists go out with it. Then we can get whitelist plugin, a real
Crosswalk plugin, and a GeckoView plugin, published, and we can see what
else the community can come up with, with all of the new flexibility.

What do you see as the other big features that would go into a RELEASENOTES
for 4.0.0?


On Wed Nov 05 2014 at 11:34:05 AM Joe Bowser bows...@gmail.com wrote:

 Hey

 I know that we've been talking about this for a while, but I think that
 we've let the 4.0.x branch go on for too long without releasing it and
 moving it back into mainline.  It's getting super insane feature creep and
 I would rather do a 4.0.x and a 5.0.x instead of cramming more stuff into
 the current release branch.

 I know that we don't really have consensus on the API, and there are some
 minor API changes that I want to see, like a renaming of CordovaWebView to
 CordovaWebViewInterface, but I think it's better to see this out the door
 by the end of 2014 instead of sometime next year, or never.  I'm finishing
 off the MozillaView in the next two weeks, and that has been an interesting
 experience shedding light on what I think really needs to be
 documented/hacked/flensed in the next version of Cordova.

 That being said, we need to get the features that we have landed out sooner
 rather than later, and while we could try for perfect, we should go with
 what we have now for the most part, just to get it out there.

 Thoughts?

 Joe

Re: Whitelist breakout update

[Ian Clelland]

On Tue Nov 04 2014 at 10:46:52 AM Frederico Galvão 
frederico.gal...@pontoget.com.br wrote:

 So we actually have 4 new plugins:
 org.apache.cordova.whitelist
 org.apache.cordova.legacy-whitelist
 org.apache.cordova.navigation-whitelist
 org.apache.cordova.intent-whitelist


I think that org.apache.cordova.legacy-whitelist is a better name for what
I have published at https://github.com/clelland/cordova-plugin-whitelist as
org.apache.cordova.whitelist.

So where I had a single plugin implementing the old behaviour, Andrew has
suggested releasing three plugins: legacy-whitelist, which is what I
implemented; and two new ones: navigation-whitelist, which implements
navigation control, and intent-whitelist, which would control launching
external apps.

(And there's also the very sound advice of just skip the whitelist plugins
and use CORS if you can get away with it)


 Right?

 If that's the case, then this is not entirely true:

 If what
  you want is no change at all in behaviour, then your upgrade should be
  just:
 
  cordova plugin add org.apache.cordova.whitelist
 
  There would be no configuration changes to make: the plugin reads the old
  access tags, just as before, and applies the same policies based on them
  that it did in 3.6.
 



The messaging is still simple, if all you want is backwards compatibility,
but if you want something better, then the instructions are more
complicated, and depend on your actual needs.



 2014-11-04 2:13 GMT-02:00 Andrew Grieve agri...@chromium.org:

  Since the whitelist plugin blocks only a subset of sub-resource loads
 (just
  like the existing whitelists), I think we really want to call out that
  people should not just include the backwards-compatible plugin. Here's a
  stab at messaging:
 
 
  If you want nothing to change, use org.apache.cordova.legacy-whitelist.
 If
  you care about security, then please understand that there are three
 types
  of whitelists to consider:
 
  1. Network traffic - The whitelist has never been able to fully block all
  network requests in this manner (on iOS and Android). Instead, we
 recommend
  using meta http-equiv=Content-Security-Policy content=[POLICY GOES
  HERE] in your head, which is supported on Android 4.4 and iOS 7.
 
  2. Navigation - By default the webview is allowed to navigate to any page
  within the same directory tree as the start page. If you'd like to
 navigate
  to a different directory, or to a http(s) address, then you should use
  org.apache.cordova.navigation-whitelist.
 
  3. Intents - By default all URLs that cause an external action (e.g.
 tel:,
  sms:, etc) are disabled. If you need to use any of these, then you should
  use org.apache.cordova.intent-whitelist.
 
 
  On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard cmarc...@gmail.com
  wrote:
  
This sounds very interesting and relatively graceful.
   
For a user upgrading to this new world, what would the migration
 steps
look like? Or in other words, what would a rough sketch of the
 upgrade
guide for this look like? The reason I ask is to see how much pain
  we'll
ask our users to go through.
   
  
   That's certainly a concern -- so for one thing, this would have to be
 on
  a
   4.x version of any platforms that it applies to. It is a break in
  backwards
   compatibility, so users should at least be prepared for it.
  
   That said, I've tried to make it as simple as possible for them: If
 what
   you want is no change at all in behaviour, then your upgrade should be
   just:
  
   cordova plugin add org.apache.cordova.whitelist
  
   There would be no configuration changes to make: the plugin reads the
 old
   access tags, just as before, and applies the same policies based on
 them
   that it did in 3.6.
  
   And if your application doesn't rely on access to external sites, then
  it's
   even simpler -- don't install the plugin, and you're likely more secure
   than you were before.
  
  
On Oct 30, 2014, at 4:04 PM, Ian Clelland iclell...@chromium.org
   wrote:
   
 I've spent the majority of the week finishing up the
  whitelist-breakout
 code, and I'd invite the rest of the community to take a look,
 before
   we
 make anything official.
   

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



 --

 *Frederico Galvão*

 Diretor de Tecnologia

 PontoGet Inovação Web


 ( +55(62) 8131-5720

 * www.pontoget.com.br http://www.pontoget.com/

Whitelist breakout update

[Ian Clelland]

I've spent the majority of the week finishing up the whitelist-breakout
code, and I'd invite the rest of the community to take a look, before we
make anything official.

In order to retain some kind of backward compatibility with existing apps
(because it's a terrible situation for everyone when we break that), I've
endeavoured to provide hooks so that all of the existing functionality can
be moved to a plugin, and so that *something* useful still happens if you
don't have any plugins at all.

Policy decisions are made centrally (in Android, by CordovaUriHelper; in
iOS, by CDVViewController), first by asking all installed plugins whether
to allow or deny the request, and if no plugins reply, then by applying a
default policy (which is sane, but more restrictive than Cordova 3.6)

Without any plugins, Cordova will allow navigation within the app itself,
to file urls, and will allow resource loads (XHRs) from that space as well.
External applications are *not* launched. access tags in config.xml are
completely ignored.

I've also modified the config parsers so that they can be used by plugins.
(For example, the sample cordova-plugin-whitelist plugin reads config.xml
to extract access tags for building its own whitelist, but other plugins
could use any other method they wanted)

All of this is in git, on branches named unplug-whitelist, on these repos:
cordova-android
cordova-ios
cordova-plugin-inappbrowser
cordova-plugin-file-transfer
cordova-mobile-spec

I wrote a sample plugin --
https://github.com/clelland/cordova-plugin-whitelist -- which implements
the Cordova 3.6 behaviour. With that plugin, access tags in config.xml
are parsed, just as they are right now. Navigation and XHR access to
external resources is controlled by access origin=...  tags, and
launching of other applications is controlled by access origin=...
launch-external=yes tags.

Comments welcome  -- either here or on
https://issues.apache.org/jira/browse/CB-7747

Ian

Re: [cordova-js] replaceNavigator

[Ian Clelland]

On Mon Oct 27 2014 at 3:41:48 PM Shazron shaz...@gmail.com wrote:

 Ouch, sorry about this :(


Don't be -- you did the right thing, and nobody actually tried it out on
the devices it's failing on.

I was talking to Andrew about it earlier, and he reminded me of the utility
functions we have for this in cordova.js -- defineGetterSetter might be the
one; I don't remember specifically. Would it be possible to use the utility
methods instead? They're pretty well tested on all platforms.

Ian


 On Fri, Oct 24, 2014 at 8:41 AM, Ian Clelland iclell...@chromium.org
 wrote:

  I'm sorry that I missed this, and that it never got the review that it
  deserved -- thanks for at least taking the right step and giving the
 whole
  dev community the chance to review it first, though.
 
  According to a bug report this morning (
  https://issues.apache.org/jira/browse/CB-7868), it looks like this code
  breaks on Android, from versions 2.3 to 4.0.3. I haven't verified it, but
  it looks likely. (Not sure whether 4.0.4 would be affected as well)
 
  If I get a chance this afternoon, I'll see if I can come up with a
  cross-platform solution for it. Otherwise, if anyone sees an obvious fix
  before I get to it, feel free to jump in (Joe? Andrew?)
 
  Ian
 
  On Wed, Sep 10, 2014 at 12:09 PM, Shazron shaz...@gmail.com wrote:
 
   PR: https://github.com/apache/cordova-js/pull/80
   Issue: https://issues.apache.org/jira/browse/CB-6911
  
   May I humbly request a review of the pull request above. Since it
 affects
   all platforms, I thought it would be prudent.
  
   Note the deprecation error is just a warning (not sure why Safari Web
   Inspector shows it with an error icon) since it doesn't really affect
 the
   app (no exception), but it's better to fix it now rather than later.
  
   replaceNavigator proxies window.navigator functions so that cordova can
   override/clobber window.navigator functions, this patch enables it to
  proxy
   properties as well, removing the error message.
  
 

Re: [cordova-js] replaceNavigator

[Ian Clelland]

I'm sorry that I missed this, and that it never got the review that it
deserved -- thanks for at least taking the right step and giving the whole
dev community the chance to review it first, though.

According to a bug report this morning (
https://issues.apache.org/jira/browse/CB-7868), it looks like this code
breaks on Android, from versions 2.3 to 4.0.3. I haven't verified it, but
it looks likely. (Not sure whether 4.0.4 would be affected as well)

If I get a chance this afternoon, I'll see if I can come up with a
cross-platform solution for it. Otherwise, if anyone sees an obvious fix
before I get to it, feel free to jump in (Joe? Andrew?)

Ian

On Wed, Sep 10, 2014 at 12:09 PM, Shazron shaz...@gmail.com wrote:

 PR: https://github.com/apache/cordova-js/pull/80
 Issue: https://issues.apache.org/jira/browse/CB-6911

 May I humbly request a review of the pull request above. Since it affects
 all platforms, I thought it would be prudent.

 Note the deprecation error is just a warning (not sure why Safari Web
 Inspector shows it with an error icon) since it doesn't really affect the
 app (no exception), but it's better to fix it now rather than later.

 replaceNavigator proxies window.navigator functions so that cordova can
 override/clobber window.navigator functions, this patch enables it to proxy
 properties as well, removing the error message.

Re: whitelist as a plugin

[Ian Clelland]

I'm still thinking in the old CadVer world here -- yes, it is a breaking
change, and would absolutely require a major version change. 3.7.0 is
certainly not a possible version number for it.

I suppose the issue of master vs. 4.0.x in my head was whether the feature
branch should be rooted on the branch named 4.0.x, and so depend on
pluggable-webviews, or rooted on where master is today, and so be eligible
for landing before the webview breakout.

Of course, I'd really love both for pluggable webviews to ship, and to not
have to do the whitelist work twice, so I'm happy with basing it on the
4.0.x branch.


On Thu, Oct 9, 2014 at 2:28 PM, Andrew Grieve agri...@chromium.org wrote:

 It's technically a breaking change, so agree 4.0.x makes sense.

 On Thu, Oct 9, 2014 at 12:09 PM, Joe Bowser bows...@gmail.com wrote:

  This should land in 4.0.x
  On Oct 9, 2014 7:38 AM, Ian Clelland iclell...@chromium.org wrote:
 
   I'm running into more and more problems caused by the whitelist (today,
   it's because of the dual use of the internal whitelist for should be
  able
   to navigate to URL and should be able to XHR from URL)
  
   I'm going to start to pull it out, on a topic branch based off of
 Android
   4.0.x right now. I'll create a JIRA issue to track the work.
  
   Is 4.0.x the best place for this to land, or is there any support for
   putting it on master as well, for an eventual 3.7 release?
  
  
   On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote:
  
+1 to remove it  for all the above reasons (and WKWebView in iOS 8)
Those interested in this security blanket for checkmark ✓ purposes
 can
install the plugin, and perhaps maintain it as well.
   
On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote:
 Or remove it altogether and let the evolution of that code be
   maintained
by
 those interested in the narrative it provides? :)

 On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org
   wrote:

 Sounds like we both agree that it doesn't work and adds a false
  sense
   of
 security (to those that do opt into it) :P.

 Maybe what we should do is redesign the whitelist to do something
  more
 useful.

 e.g. A whitelist that says what URLs you can navigate to is useful
  and
easy
 to implement. Let's just drop the trying to stop network requests
aspect of
 it?


 On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
 javascript:; wrote:

  I'm in agreement with Andrew on this one.  If we can get CSP
   working,
  that's a far better solution than our Whitelist, which was done
  because it was needed at the time for the enterprise use case
 that
   IBM
  had.  I don't think we're ever going to stop are users from
 doing
   dumb
  things like including thirdpartyadnetworkthatdoesnoteusehttps.js
  in
  their apps any time soon, but they'll have to jump through more
   hoops
  to do dumb things, and making dumb things harder is a good
 thing.
 
  On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io
javascript:;
 wrote:
   Heh. Why do we always seem to be at the opposite end of
considerations?
   (Not a bad thing anyhow. ;)
  
   So making whitelist a plugin would most certainly isolate the
  code
 which
   would help us better understand:
  
   1.) where the surface for bugs are (we seem to miss/find new
security
  holes
   each quarter…)
   2.) if people actually use it
  
   I'm more interested in #2. I suspect the only people whom do
 use
   it
are
   security researchers disproving the whitelist veracity. I feel
   this
API
  was
   a mistake, is misleading, and ultimately leads to poor web
   security
   practices wrt 3rd part scripts. I'd like the evidence to
 remove
  it
   completely and making it a plugin would do that. (And still
  allow
for
 its
   existence to those whom want to contribute to a marketing
  based
api.)
  
  
  
   On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve 
   agri...@chromium.org
 javascript:;
  wrote:
  
   I don't think moving the whitelist to a plugin would aid in
 its
   understanding. Right now the whitelist is used for two
 things:
  
   1. Whether to allow network requests through (although this
 is
broken
  for
   audio/video on iOS, and broken for them + websockets on
   Android
   2. Whether to allow top frame navigations (e.g. clicking a
 link
   to
  http://
   *
   opens in system browser vs. webview)
  
   #1 doesn't work very well due to technical limitations.
   #2 is actually the more import one security-wise I think,
 and I
don't
  think
   should be relegated to a plugin.
  
   I'm hoping medium-term that CSP can replace the use-case of
 #1

Re: whitelist as a plugin

[Ian Clelland]

I'm running into more and more problems caused by the whitelist (today,
it's because of the dual use of the internal whitelist for should be able
to navigate to URL and should be able to XHR from URL)

I'm going to start to pull it out, on a topic branch based off of Android
4.0.x right now. I'll create a JIRA issue to track the work.

Is 4.0.x the best place for this to land, or is there any support for
putting it on master as well, for an eventual 3.7 release?


On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote:

 +1 to remove it  for all the above reasons (and WKWebView in iOS 8)
 Those interested in this security blanket for checkmark ✓ purposes can
 install the plugin, and perhaps maintain it as well.

 On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote:
  Or remove it altogether and let the evolution of that code be maintained
 by
  those interested in the narrative it provides? :)
 
  On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org wrote:
 
  Sounds like we both agree that it doesn't work and adds a false sense of
  security (to those that do opt into it) :P.
 
  Maybe what we should do is redesign the whitelist to do something more
  useful.
 
  e.g. A whitelist that says what URLs you can navigate to is useful and
 easy
  to implement. Let's just drop the trying to stop network requests
 aspect of
  it?
 
 
  On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
  javascript:; wrote:
 
   I'm in agreement with Andrew on this one.  If we can get CSP working,
   that's a far better solution than our Whitelist, which was done
   because it was needed at the time for the enterprise use case that IBM
   had.  I don't think we're ever going to stop are users from doing dumb
   things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
   their apps any time soon, but they'll have to jump through more hoops
   to do dumb things, and making dumb things harder is a good thing.
  
   On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io
 javascript:;
  wrote:
Heh. Why do we always seem to be at the opposite end of
 considerations?
(Not a bad thing anyhow. ;)
   
So making whitelist a plugin would most certainly isolate the code
  which
would help us better understand:
   
1.) where the surface for bugs are (we seem to miss/find new
 security
   holes
each quarter…)
2.) if people actually use it
   
I'm more interested in #2. I suspect the only people whom do use it
 are
security researchers disproving the whitelist veracity. I feel this
 API
   was
a mistake, is misleading, and ultimately leads to poor web security
practices wrt 3rd part scripts. I'd like the evidence to remove it
completely and making it a plugin would do that. (And still allow
 for
  its
existence to those whom want to contribute to a marketing based
 api.)
   
   
   
On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve agri...@chromium.org
  javascript:;
   wrote:
   
I don't think moving the whitelist to a plugin would aid in its
understanding. Right now the whitelist is used for two things:
   
1. Whether to allow network requests through (although this is
 broken
   for
audio/video on iOS, and broken for them + websockets on Android
2. Whether to allow top frame navigations (e.g. clicking a link to
   http://
*
opens in system browser vs. webview)
   
#1 doesn't work very well due to technical limitations.
#2 is actually the more import one security-wise I think, and I
 don't
   think
should be relegated to a plugin.
   
I'm hoping medium-term that CSP can replace the use-case of #1.
   
   
On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland 
 iclell...@chromium.org
  javascript:;
wrote:
   
 What would be the security implication of removing it from core?
 No
access
 at all by default? Or unlimited access by default?

 I suspect that if the default policy with no plugin installed is
 the
 latter, then we will be given the impression that it's not
 important
   at
all
 :)

 I had considered just turning the whitelist settings into a
 plugin
  --
 either leaving the default rules as they are, and writing a
 cordova-security plugin that locks it down, or tighten
 everything
  by
 default, and tell people to install cordova-plugin-insecurity
 if
   they
 want to open it up :)

 I like the idea of making the entire whitelist architecture into
 a
plugin,
 though. If nothing else, it should be easier to reason about it,
 and
easier
 to fix or replace it in the future if we need to.


 On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com
  javascript:; wrote:

  Actually it's already possible in any iOS version, we just
 have to
  make sure the plugin loads at startup. This is for UIWebView
 only,
  WKWebView has this issue:
  https://issues.apache.org/jira/browse

Re: whitelist as a plugin

[Ian Clelland]

CB-7747, for those following along at home.

On Thu, Oct 9, 2014 at 10:38 AM, Ian Clelland iclell...@chromium.org
wrote:

 I'm running into more and more problems caused by the whitelist (today,
 it's because of the dual use of the internal whitelist for should be able
 to navigate to URL and should be able to XHR from URL)

 I'm going to start to pull it out, on a topic branch based off of Android
 4.0.x right now. I'll create a JIRA issue to track the work.

 Is 4.0.x the best place for this to land, or is there any support for
 putting it on master as well, for an eventual 3.7 release?


 On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote:

 +1 to remove it  for all the above reasons (and WKWebView in iOS 8)
 Those interested in this security blanket for checkmark ✓ purposes can
 install the plugin, and perhaps maintain it as well.

 On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote:
  Or remove it altogether and let the evolution of that code be
 maintained by
  those interested in the narrative it provides? :)
 
  On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org wrote:
 
  Sounds like we both agree that it doesn't work and adds a false sense
 of
  security (to those that do opt into it) :P.
 
  Maybe what we should do is redesign the whitelist to do something more
  useful.
 
  e.g. A whitelist that says what URLs you can navigate to is useful and
 easy
  to implement. Let's just drop the trying to stop network requests
 aspect of
  it?
 
 
  On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com
  javascript:; wrote:
 
   I'm in agreement with Andrew on this one.  If we can get CSP working,
   that's a far better solution than our Whitelist, which was done
   because it was needed at the time for the enterprise use case that
 IBM
   had.  I don't think we're ever going to stop are users from doing
 dumb
   things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
   their apps any time soon, but they'll have to jump through more hoops
   to do dumb things, and making dumb things harder is a good thing.
  
   On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io
 javascript:;
  wrote:
Heh. Why do we always seem to be at the opposite end of
 considerations?
(Not a bad thing anyhow. ;)
   
So making whitelist a plugin would most certainly isolate the code
  which
would help us better understand:
   
1.) where the surface for bugs are (we seem to miss/find new
 security
   holes
each quarter…)
2.) if people actually use it
   
I'm more interested in #2. I suspect the only people whom do use
 it are
security researchers disproving the whitelist veracity. I feel
 this API
   was
a mistake, is misleading, and ultimately leads to poor web security
practices wrt 3rd part scripts. I'd like the evidence to remove it
completely and making it a plugin would do that. (And still allow
 for
  its
existence to those whom want to contribute to a marketing based
 api.)
   
   
   
On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve 
 agri...@chromium.org
  javascript:;
   wrote:
   
I don't think moving the whitelist to a plugin would aid in its
understanding. Right now the whitelist is used for two things:
   
1. Whether to allow network requests through (although this is
 broken
   for
audio/video on iOS, and broken for them + websockets on
 Android
2. Whether to allow top frame navigations (e.g. clicking a link to
   http://
*
opens in system browser vs. webview)
   
#1 doesn't work very well due to technical limitations.
#2 is actually the more import one security-wise I think, and I
 don't
   think
should be relegated to a plugin.
   
I'm hoping medium-term that CSP can replace the use-case of #1.
   
   
On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland 
 iclell...@chromium.org
  javascript:;
wrote:
   
 What would be the security implication of removing it from
 core? No
access
 at all by default? Or unlimited access by default?

 I suspect that if the default policy with no plugin installed
 is the
 latter, then we will be given the impression that it's not
 important
   at
all
 :)

 I had considered just turning the whitelist settings into a
 plugin
  --
 either leaving the default rules as they are, and writing a
 cordova-security plugin that locks it down, or tighten
 everything
  by
 default, and tell people to install cordova-plugin-insecurity
 if
   they
 want to open it up :)

 I like the idea of making the entire whitelist architecture
 into a
plugin,
 though. If nothing else, it should be easier to reason about
 it, and
easier
 to fix or replace it in the future if we need to.


 On Mon, Jul 7, 2014 at 3:55 PM, Shazron shaz...@gmail.com
  javascript:; wrote:

  Actually it's already possible in any iOS version, we just
 have to
  make sure

Re: [VOTE] Tools Release

[Ian Clelland]

That's awesome, Sergey: Thanks!

I didn't expect the patch to be so small :)

I'll take a look at the others this morning and merge them in as well.

Ian

On Tue, Oct 7, 2014 at 4:26 AM, Sergey Grebnov (Akvelon) 
v-seg...@microsoft.com wrote:

 I've investigated both blocking issues (CB-7718, CB-6777), here is the fix
 (root cause is the same):
 https://github.com/apache/cordova-lib/pull/102

 Please also review and include to release branch the following PRs since
 we have real cases when build fails w/o those fixes.

 CB-7670 Fixes failure when trying to fetch dependent plugin while adding
 platform
 https://github.com/apache/cordova-lib/pull/96

 CB-7715 Fix windows build if folder has '.(js|htm|etc)' in name
 https://github.com/apache/cordova-lib/pull/99

 Thx!
 Sergey
 -Original Message-
 From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of Ian
 Clelland
 Sent: Monday, October 6, 2014 7:31 PM
 To: dev@cordova.apache.org
 Cc: Steven Gill; Parashuram Narasimhan (MS OPEN TECH); Shazron
 Subject: Re: [VOTE] Tools Release

 We can look at doing that; CB-6481 is a series of 12 commits, though, so
 it may be more difficult than just removing a single commit.

 (Also, Marcel pointed me to CB-7677, which is the same issue -- I've
 upgraded it to blocker as well)

 On Mon, Oct 6, 2014 at 11:26 AM, Parashuram Narasimhan (MS OPEN TECH) 
 panar...@microsoft.com wrote:

  Should we simply cherry pick that comment out and go ahead with the
  release? The existing latest release (3.6.4) has a bunch of bugs in
  the Windows platform that need to be fixed.
 
  -Original Message-
  From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of
  Ian Clelland
  Sent: Monday, October 6, 2014 7:57 AM
  To: Steven Gill
  Cc: Shazron; dev@cordova.apache.org
  Subject: Re: [VOTE] Tools Release
 
  FYI, I just opened CB-7718 as a blocking issue against CordovaLib. I
  haven't tracked down the cause (except that it's somewhere in the
  CB-6481
  code) but if we were to re-open the vote, I'd have to -1 it.
 
  On Fri, Oct 3, 2014 at 7:39 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
   Okay, taking this discussion back into independent platform release
   summary thread
  
   On Fri, Oct 3, 2014 at 4:21 PM, Shazron shaz...@gmail.com wrote:
  
Did we have consensus on 4.0 though? I would think a bigger
version would increase separation - and that's what I sensed
 consensus on.
After a few releases, the cordova platforms will already be at
4.0, and we're at
   square
one.
   
On Fri, Oct 3, 2014 at 2:38 PM, Steven Gill
stevengil...@gmail.com
wrote:
   
I am going to close this vote and redo it with CLI + Lib
versioning set
   to
4.0.0
   
On Thu, Oct 2, 2014 at 7:37 AM, Steven Gill
stevengil...@gmail.com
wrote:
   
 I must have forgot to run svn up. I'll do it soon when I get to
 my computer.


 On Thursday, October 2, 2014, Sergey Grebnov (Akvelon) 
 v-seg...@microsoft.com wrote:

 I don't see Tools packages on
 https://dist.apache.org/repos/dist/dev/cordova/CB-7661/
 Am I looking to wrong location?

 Thx!
 Sergey
 -Original Message-
 From: Steven Gill [mailto:stevengil...@gmail.com]
 Sent: Thursday, October 2, 2014 3:14 AM
 To: dev@cordova.apache.org
 Subject: [VOTE] Tools Release

 Please review and vote on this Tools Release.

 Release issue: https://issues.apache.org/jira/browse/CB-7661

 Both tools have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-766
 1/

 The packages were published from their corresponding git tags:

 cordova-js: 3.7.0 (d84626637e)
 cordova-lib: 3.7.0 (329275484b)
 cordova-plugman: 0.22.11 (6ac534395a)
 cordova-cli: 3.7.0 (88e0c3ac00)

 You can test the cli by running npm install -g cordova@rc

 To test Android, Browser, Windows, WP, use --usegit flag when
 adding
them
 to your project.
 ex. cordova platform add android --usegit


 As you can see, in this release I have made the cli semver
  compliant.
 The version is now 3.7.0.
 I have also made cordova-lib's version 3.7.0 to sync up the two.
 If
   you
 have any issues with this, lets discuss.


 Upon a successful vote I will upload the archives to dist/,
 publish
them
 to NPM, and post the corresponding blog post.

 Voting guidelines:

   
   https://github.com/apache/cordova-coho/blob/master/docs/release-voti
   ng
   .md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Used `license-checker` to ensure all dependencies have
 Apache-compatible licenses


   
   
   
  
 

Re: Independent platform release summary

[Ian Clelland]

(b) was mostly made in jest; it definitely fails the should be
monotonically increasing test for version numbering schemes :)

(d) is attractive, and we could probably make it work. It would mean that
CLI versions would likely move way ahead of platform versions, but that's
OK. The big change from today is that, instead of telling people to
download cordova 3.7.0 from npm, we would just say

Download cordova from npm, and then run 'cordova platform add android@3.7.0
'

So long as the CLI maintains backwards-compatibility with old platforms,
there's never a reason for users to *not* keep updating the CLI in that
case.


On Mon, Oct 6, 2014 at 8:29 PM, Michal Mocny mmo...@chromium.org wrote:

 Just got through this thread.  Summarizing Proposals:

 (a) CLI moves to v10.0.0, and version numbers increment at same rate as
 (union of) platforms.
- This has benefits, but is confusing as shit given our current plan.
 I'm not sure it needs to be this confusing, but we shouldn't make moves
 forward until we think this through some more.
- This kinda conflicts with the whole point of independent releases,
 too: a version bump for a platform you don't care about still affects you
 (a bit).

 (b) CLI version is a sum of all platform versions
- I think this seems an minor management improvement over (a), but falls
 apart when you consider what happens when you deprecate a platform in the
 future.

 (c) We move back to pinning platform versions to CLI version (aka, there
 is a single cordova version number shared by everything)
- This conflicts with independant versioning, but maybe not independent
 releases (which is what we are really after).
- This implies (I think) releases by date / cadence version, and not
 real semver (Or semver but for the union of all platforms and tools, kinda
 pointless).
- To do independent platform releases, we should first find a
 lightweight way to bump platform versions without a release (i.e.
 cordova-ios@3.6.0 - @3.7.0 rename when cordova-android bumps to @3.7.0).
 Otherwise, devs will be upgrading platforms for no reason constantly.

 (d) CLI versions completely independent of platforms, just like plugins.
- In this case, we need to implement platform-cli version requirements
  (node peerDependancies?)
- Basically means we play down CLI version entirely, users are just
 expected to stay up to date with CLI always.  Platform versions are all
 that matters.  I don't think this is too different than what we have today.

 I personally like (d) most.  Sure, I do like the simplified versioning
 story of (c) (basically cad-ver), but I think its less important now that
 we are doing platform releases to npm.  I hope we won't rely on users
 getting cordova from download links from the website, but rather just npm
 upgrade -g.  I think (a) just complicates (d) needlessly without giving
 real value to users.

 Did I make any mistakes?  Shall we meet to discuss this at PGDay US, or
 shall we do a hangout this week if we hope to have something to present to
 the audience in time for PGDay US?

 -Michal

 On Mon, Oct 6, 2014 at 6:37 PM, Smith, Peter pet...@fast.au.fujitsu.com
 wrote:

  Super version flexibility == Super version confusion.
 
  The Cordova site seems in need of a kind of
  Cordova/Platform/CLI/CorePlugin version dependency matrix which
  officially documents what-works-with-what (e.g. what has passed the
  official testing). Perhaps it would look something like the API support
  matrix at
 
 http://cordova.apache.org/docs/en/3.6.0/guide_support_index.md.html#Platform%20Support
  .
 
  It might not be easy to do, but if the combined wit of Cordova committers
  is unable to clearly document versioning dependencies then what hope is
  there for end users to understand it?
 
  Peter
 
  -Original Message-
  From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
  Grieve
  Sent: Sunday, 5 October 2014 5:05 AM
  To: Treggiari, Leo
  Cc: Brian LeRoux; Andrew Grieve; dev@cordova.apache.org; Marcel Kinard
  Subject: Re: Independent platform release summary
 
  To the best of my knowledge, the version numbers of platforms do not
  signify that platforms have the same functionality. Version numbers for
  plugins also don't really do this - many plugins have different
  capabilities on different platforms even at the same version number.
 
  For example, whitelists mean different things on different platforms.
  Another example is that different platforms added support for
 ArrayBuffers
  over the exec() bridge at different times. Historically - platform
 version
  numbers just mean that they were all released at the same time.
 
  For the most part, platforms keep changing to keep up with OS changes,
 but
  almost never are there features that are added across all platforms at
 the
  same time.
 
 
 
 
  On Fri, Oct 3, 2014 at 10:10 PM, Treggiari, Leo leo.treggi...@intel.com
 
  wrote:
 
Here’s my concern regarding versions of 

Re: [VOTE] Tools Release

[Ian Clelland]

These are all merged in, on the master branch. GitHub claimed that #96 was
failing on the Travis server, but I tested it, and didn't see any test
failures here.

I didn't cherry-pick them onto 3.7.x; I don't know if the 3.7.x branch is
considered a release branch right now. All of the commits since 3.7.0 was
tagged seem like they should probably go into the next release anyway, so
I'd probably just want to re-branch from master for 4.0.0, or 10.0.0, or
whatever the next version turns out to be.

Ian

On Tue, Oct 7, 2014 at 7:16 AM, Ian Clelland iclell...@chromium.org wrote:

 That's awesome, Sergey: Thanks!

 I didn't expect the patch to be so small :)

 I'll take a look at the others this morning and merge them in as well.

 Ian

 On Tue, Oct 7, 2014 at 4:26 AM, Sergey Grebnov (Akvelon) 
 v-seg...@microsoft.com wrote:

 I've investigated both blocking issues (CB-7718, CB-6777), here is the
 fix (root cause is the same):
 https://github.com/apache/cordova-lib/pull/102

 Please also review and include to release branch the following PRs since
 we have real cases when build fails w/o those fixes.

 CB-7670 Fixes failure when trying to fetch dependent plugin while adding
 platform
 https://github.com/apache/cordova-lib/pull/96

 CB-7715 Fix windows build if folder has '.(js|htm|etc)' in name
 https://github.com/apache/cordova-lib/pull/99

 Thx!
 Sergey
 -Original Message-
 From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of
 Ian Clelland
 Sent: Monday, October 6, 2014 7:31 PM
 To: dev@cordova.apache.org
 Cc: Steven Gill; Parashuram Narasimhan (MS OPEN TECH); Shazron
 Subject: Re: [VOTE] Tools Release

 We can look at doing that; CB-6481 is a series of 12 commits, though, so
 it may be more difficult than just removing a single commit.

 (Also, Marcel pointed me to CB-7677, which is the same issue -- I've
 upgraded it to blocker as well)

 On Mon, Oct 6, 2014 at 11:26 AM, Parashuram Narasimhan (MS OPEN TECH) 
 panar...@microsoft.com wrote:

  Should we simply cherry pick that comment out and go ahead with the
  release? The existing latest release (3.6.4) has a bunch of bugs in
  the Windows platform that need to be fixed.
 
  -Original Message-
  From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of
  Ian Clelland
  Sent: Monday, October 6, 2014 7:57 AM
  To: Steven Gill
  Cc: Shazron; dev@cordova.apache.org
  Subject: Re: [VOTE] Tools Release
 
  FYI, I just opened CB-7718 as a blocking issue against CordovaLib. I
  haven't tracked down the cause (except that it's somewhere in the
  CB-6481
  code) but if we were to re-open the vote, I'd have to -1 it.
 
  On Fri, Oct 3, 2014 at 7:39 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
   Okay, taking this discussion back into independent platform release
   summary thread
  
   On Fri, Oct 3, 2014 at 4:21 PM, Shazron shaz...@gmail.com wrote:
  
Did we have consensus on 4.0 though? I would think a bigger
version would increase separation - and that's what I sensed
 consensus on.
After a few releases, the cordova platforms will already be at
4.0, and we're at
   square
one.
   
On Fri, Oct 3, 2014 at 2:38 PM, Steven Gill
stevengil...@gmail.com
wrote:
   
I am going to close this vote and redo it with CLI + Lib
versioning set
   to
4.0.0
   
On Thu, Oct 2, 2014 at 7:37 AM, Steven Gill
stevengil...@gmail.com
wrote:
   
 I must have forgot to run svn up. I'll do it soon when I get to
 my computer.


 On Thursday, October 2, 2014, Sergey Grebnov (Akvelon) 
 v-seg...@microsoft.com wrote:

 I don't see Tools packages on
 https://dist.apache.org/repos/dist/dev/cordova/CB-7661/
 Am I looking to wrong location?

 Thx!
 Sergey
 -Original Message-
 From: Steven Gill [mailto:stevengil...@gmail.com]
 Sent: Thursday, October 2, 2014 3:14 AM
 To: dev@cordova.apache.org
 Subject: [VOTE] Tools Release

 Please review and vote on this Tools Release.

 Release issue: https://issues.apache.org/jira/browse/CB-7661

 Both tools have been published to
 dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-766
 1/

 The packages were published from their corresponding git tags:

 cordova-js: 3.7.0 (d84626637e)
 cordova-lib: 3.7.0 (329275484b)
 cordova-plugman: 0.22.11 (6ac534395a)
 cordova-cli: 3.7.0 (88e0c3ac00)

 You can test the cli by running npm install -g cordova@rc

 To test Android, Browser, Windows, WP, use --usegit flag when
 adding
them
 to your project.
 ex. cordova platform add android --usegit


 As you can see, in this release I have made the cli semver
  compliant.
 The version is now 3.7.0.
 I have also made cordova-lib's version 3.7.0 to sync up the two.
 If
   you
 have any issues with this, lets discuss.


 Upon a successful vote I

Re: List replies

[Ian Clelland]

There used to be a Reply-To header, telling the MUA to reply to 
dev@cordova.apache.org. It looks like that was removed just a few days ago
(I see it on messages from Oct 2, but not from Oct 3)

I've no idea why it changed, or who did it, but I'm certain that's the
difference.

Ian

On Tue, Oct 7, 2014 at 8:31 AM, Josh Soref jso...@blackberry.com wrote:

 ‎Personally, I don't mind. My mail client has a (prominent) reply all
 button. The previous configuration of this list just poisoned my mail
 client -- resulting in Person ‎dev@cordova.apache.org and such.

Re: [VOTE] Tools Release

[Ian Clelland]

FYI, I just opened CB-7718 as a blocking issue against CordovaLib. I
haven't tracked down the cause (except that it's somewhere in the CB-6481
code) but if we were to re-open the vote, I'd have to -1 it.

On Fri, Oct 3, 2014 at 7:39 PM, Steven Gill stevengil...@gmail.com wrote:

 Okay, taking this discussion back into independent platform release
 summary thread

 On Fri, Oct 3, 2014 at 4:21 PM, Shazron shaz...@gmail.com wrote:

  Did we have consensus on 4.0 though? I would think a bigger version would
  increase separation - and that's what I sensed consensus on. After a few
  releases, the cordova platforms will already be at 4.0, and we're at
 square
  one.
 
  On Fri, Oct 3, 2014 at 2:38 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
  I am going to close this vote and redo it with CLI + Lib versioning set
 to
  4.0.0
 
  On Thu, Oct 2, 2014 at 7:37 AM, Steven Gill stevengil...@gmail.com
  wrote:
 
   I must have forgot to run svn up. I'll do it soon when I get to my
   computer.
  
  
   On Thursday, October 2, 2014, Sergey Grebnov (Akvelon) 
   v-seg...@microsoft.com wrote:
  
   I don't see Tools packages on
   https://dist.apache.org/repos/dist/dev/cordova/CB-7661/
   Am I looking to wrong location?
  
   Thx!
   Sergey
   -Original Message-
   From: Steven Gill [mailto:stevengil...@gmail.com]
   Sent: Thursday, October 2, 2014 3:14 AM
   To: dev@cordova.apache.org
   Subject: [VOTE] Tools Release
  
   Please review and vote on this Tools Release.
  
   Release issue: https://issues.apache.org/jira/browse/CB-7661
  
   Both tools have been published to
   dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-7661/
  
   The packages were published from their corresponding git tags:
  
   cordova-js: 3.7.0 (d84626637e)
   cordova-lib: 3.7.0 (329275484b)
   cordova-plugman: 0.22.11 (6ac534395a)
   cordova-cli: 3.7.0 (88e0c3ac00)
  
   You can test the cli by running npm install -g cordova@rc
  
   To test Android, Browser, Windows, WP, use --usegit flag when adding
  them
   to your project.
   ex. cordova platform add android --usegit
  
  
   As you can see, in this release I have made the cli semver compliant.
   The version is now 3.7.0.
   I have also made cordova-lib's version 3.7.0 to sync up the two. If
 you
   have any issues with this, lets discuss.
  
  
   Upon a successful vote I will upload the archives to dist/, publish
  them
   to NPM, and post the corresponding blog post.
  
   Voting guidelines:
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
  
   Voting will go on for a minimum of 48 hours.
  
   I vote +1:
   * Ran coho audit-license-headers over the relevant repos
   * Used `license-checker` to ensure all dependencies have
   Apache-compatible licenses
  
  
 
 
 

Re: [VOTE] Tools Release

[Ian Clelland]

We can look at doing that; CB-6481 is a series of 12 commits, though, so it
may be more difficult than just removing a single commit.

(Also, Marcel pointed me to CB-7677, which is the same issue -- I've
upgraded it to blocker as well)

On Mon, Oct 6, 2014 at 11:26 AM, Parashuram Narasimhan (MS OPEN TECH) 
panar...@microsoft.com wrote:

 Should we simply cherry pick that comment out and go ahead with the
 release? The existing latest release (3.6.4) has a bunch of bugs in the
 Windows platform that need to be fixed.

 -Original Message-
 From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of Ian
 Clelland
 Sent: Monday, October 6, 2014 7:57 AM
 To: Steven Gill
 Cc: Shazron; dev@cordova.apache.org
 Subject: Re: [VOTE] Tools Release

 FYI, I just opened CB-7718 as a blocking issue against CordovaLib. I
 haven't tracked down the cause (except that it's somewhere in the CB-6481
 code) but if we were to re-open the vote, I'd have to -1 it.

 On Fri, Oct 3, 2014 at 7:39 PM, Steven Gill stevengil...@gmail.com
 wrote:

  Okay, taking this discussion back into independent platform release
  summary thread
 
  On Fri, Oct 3, 2014 at 4:21 PM, Shazron shaz...@gmail.com wrote:
 
   Did we have consensus on 4.0 though? I would think a bigger version
   would increase separation - and that's what I sensed consensus on.
   After a few releases, the cordova platforms will already be at 4.0,
   and we're at
  square
   one.
  
   On Fri, Oct 3, 2014 at 2:38 PM, Steven Gill stevengil...@gmail.com
   wrote:
  
   I am going to close this vote and redo it with CLI + Lib versioning
   set
  to
   4.0.0
  
   On Thu, Oct 2, 2014 at 7:37 AM, Steven Gill
   stevengil...@gmail.com
   wrote:
  
I must have forgot to run svn up. I'll do it soon when I get to
my computer.
   
   
On Thursday, October 2, 2014, Sergey Grebnov (Akvelon) 
v-seg...@microsoft.com wrote:
   
I don't see Tools packages on
https://dist.apache.org/repos/dist/dev/cordova/CB-7661/
Am I looking to wrong location?
   
Thx!
Sergey
-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Thursday, October 2, 2014 3:14 AM
To: dev@cordova.apache.org
Subject: [VOTE] Tools Release
   
Please review and vote on this Tools Release.
   
Release issue: https://issues.apache.org/jira/browse/CB-7661
   
Both tools have been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-7661/
   
The packages were published from their corresponding git tags:
   
cordova-js: 3.7.0 (d84626637e)
cordova-lib: 3.7.0 (329275484b)
cordova-plugman: 0.22.11 (6ac534395a)
cordova-cli: 3.7.0 (88e0c3ac00)
   
You can test the cli by running npm install -g cordova@rc
   
To test Android, Browser, Windows, WP, use --usegit flag when
adding
   them
to your project.
ex. cordova platform add android --usegit
   
   
As you can see, in this release I have made the cli semver
 compliant.
The version is now 3.7.0.
I have also made cordova-lib's version 3.7.0 to sync up the two.
If
  you
have any issues with this, lets discuss.
   
   
Upon a successful vote I will upload the archives to dist/,
publish
   them
to NPM, and post the corresponding blog post.
   
Voting guidelines:
   
  
  https://github.com/apache/cordova-coho/blob/master/docs/release-voting
  .md
   
Voting will go on for a minimum of 48 hours.
   
I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Used `license-checker` to ensure all dependencies have
Apache-compatible licenses
   
   
  
  
  
 

Re: Translations

[Ian Clelland]

I'm working on these now -- they should be mostly done by the end of the
day today.

Victor -- there were already some changes proposed to the spanish
translations in the Device plugin here:
https://github.com/apache/cordova-plugin-device/pull/17 -- some of them are
independent of your changes, and others conflict. I've pulled your PR in,
but could you take a look and see if any other changes need be made?


On Mon, Oct 6, 2014 at 10:30 AM, Victor Sosa sosah.vic...@gmail.com wrote:

 Thanks for the introduction Lisa!
 Happy to help the community a little bit :-D

 2014-10-06 8:13 GMT-05:00 Lisa Seacat DeLuca ldel...@us.ibm.com:

  Team, just as an FYI, you should have been seeing some pull requests from
  Victor Adrian Sosa Herrera for the translation effort.  I am mentoring
 him
  through helping out with translation so there will be someone else who
  knows how the process works besides me.  He is not yet a committer so
  unfortunately we have to manually pull in his pull requests rather than
  automatically accept.  This means there will be a number of pull requests
  coming in.  Thank you Victor for agreeing to help me out!
 
 
  Lisa
 
 
  Lisa Seacat DeLuca
  Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org*
  ldel...@apache.org | *ldel...@us.ibm.com* ldel...@us.ibm.com |
  *lisaseacat.com* http://www.lisaseacat.com/ | [image: follow
  @LisaSeacat on twitter] http://www.twitter.com/LisaSeacat| [image:
  follow Lisa Seacat DeLuca on linkedin]
  http://www.linkedin.com/in/lisaseacat




 --
 Victor Adrian Sosa Herrera
 IBM Software Engineer
 Guadalajara, Jalisco

Re: project version info

[Ian Clelland]

On Fri, Oct 3, 2014 at 10:58 AM, Michal Mocny mmo...@chromium.org wrote:

 The reason CLI is reporting that number is because we tried to go semver in
 an odd way (CAD-SEM) and CLI version was supposed to be just the SEM part
 and the CAD was just informational -- which hasn't worked out so well.  The
 next CLI release is going to drop the old SEM and turn the existing CAD
 into the new SEM.  i.e.: npm install -g cordova@rc you'll notice that its
 just 3.7.0.


There's also the issue that the CLI version doesn't necessarily correspond
exactly to the platform versions. CLI 3.6.0-0.2.9 by default installs
Android 3.6.0, for instance, but FFOS 3.6.1. And with independent platform
releases, it's about to get a lot weirder.

I don't know if a better question is which CLI version you used to create a
project, or which platform versions are actually installed (which you can
get from `cordova platfom ls`)

Ian



 w.r.t. reporting installed version and not workspace created version: the
 version of the CLI that was used to create a project should not be what is
 important.  Its the current versions of the platforms and plugins within
 your workspace that are actually important.

 This is because when you upgrade your CLI, we will not use the version that
 was used to create the project any more.  There have been proposals for
 this, but its not implemented, we just assume you always want the latest
 CLI to manage your workspace.

 This could become an issue if the CLI breaks compatibility with directory
 structure / old platform/plugin structure, but that hasn't come up yet.  If
 that *does* happen, we can introduce a created-with at that point, and
 use the lack of created-with as a signal for old version.

 For what its worth, for cca we drop a created-with-cca-version file
 inside your platforms/ folder, since we currently also pin platforms.  When
 you upgrade your cca tool, we then know to prompt for a platforms upgrade.
 I don't know if this will still be necessary with independent platform
 releases.

 -Michal


 On Fri, Oct 3, 2014 at 6:41 AM, Ray Camden rayca...@adobe.com wrote:

  I¹m posting this here as opposed to the Google Group as it seems like the
  type of thing that may have been discussed, then turned down, and I
  figured this list was best to answer why.
 
  Unless I¹m not seeing it, there is no way to tell what version of the CLI
  was used to build a project. Oddly ³cordova info² will return Cordova
  version, but for me, the # makes no sense. Here is one I got with a
 recent
  project: 0.21.13.
 
  Is there a reason why 3.6.3 isn¹t returned and not saved in config.xml?
 
  I¹m assuming it is because plugin version info is more important, but I
  can definitely seeing wanting to know what CLI version was used.
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

Re: Cordova Android 3.5.1 XAS Security Vulnerability -- possibility of releasing a 2.7-based patched version

[Ian Clelland]

That patch fixes the startURL / errorURL issue, which is one of the major
components of the 3.5.1 security release (CVE-2014-3500).

The other issue is CVE-2014-3502, which is that intent urls can be launched
by a Cordova app regardless of the whitelist settings. There isn't a patch
which addresses this on the 2.x branch (unless IBM has produced one --
Mike?) but it shouldn't be much work to simply remove the all of the code
that handles intent / sms / geo / tel / etc. URLs from the
shouldOverrideUrlLoading method of CordovaWebViewClient.java. If you remove
the intent-launching code from that method, then it should stop your
application from launching external applications.

That being said, if you can afford to upgrade to 3.x (3.6.x now) then it
will be much easier for you to get additional security patches in the
future. We're not running or testing 2.x anymore, and can't guarantee, for
instance, that the patch that Andrew mentioned or the technique that I just
described will actually work.

Ian

On Thu, Oct 2, 2014 at 11:40 AM, Andrew Grieve agri...@chromium.org wrote:

 That said, the relevant patch is here:


 https://github.com/apache/cordova-android/commit/2ab81bc5aeb575fef3657cf48a671607e81ca37d

 (Ian / Joe, please correct me if there's more than that)



 On Thu, Oct 2, 2014 at 11:29 AM, Joe Bowser bows...@gmail.com wrote:

 No, you should upgrade to 3.5.1.  We have dropped support for Cordova 2.x
 months ago, and we recommend upgrading.

 On Thu, Oct 2, 2014 at 7:33 AM, steve.wil...@bentley.com wrote:

  We have released applications in the Google Play store based on Cordova
  2.7.0 and have received notification from Google that these apps are
  vulnerable to an Android Cordova security issue (
  http://cordova.apache.org/announcements/2014/08/04/android-351.html).
 
  Upgrading to Cordova 3.5.1 would require significant work on our part.
 Is
  there any possibility that you can release a patched Cordova Android
  version based on 2.7 that would fix this security vulnerability?
 
  Please let me know whether you think this would be possible on your
 part.
  Thank you!
 
  Thanks,
  Steve Wilson
 

Re: Independent platform release summary

[Ian Clelland]

On Thursday, October 2, 2014, Steven Gill stevengil...@gmail.com wrote:

 We would have to restart the tools vote to change the version.

 I don't see much difference from jumping to 4.0 compared to 5.0 or 10.0


It's entirely psychological. A big jump is just leaving the older
versioning further behind.


 Higher version jump would be to build some separation between platforms
 versions and cli version. Even if we go to 4.0, Cordova version jumps will
 be frequent and rapid.

 I personally think it makes more sense to make the version jump now then
 later. I'm not to inclined to tie a major version jump to a conference but
 rather when it feels right due to our versioning policies.


Agreed. Conference-based-versioning would be an odd standard to have to
hold ourselves to :)


 Below is a overview of how I see versioning.

 Semver summary

 Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible
manner, and
3. PATCH version when you make backwards-compatible bug fixes.

 My proposal:

 CLI + Lib versioning (imagine version for cli + lib is at 4.0.0):

 if a platform does a patch version jump (ex ios 3.7.1), then cli + lib
 should do a patch jump (ex 4.0.1)
 If a platform does a minor version jump (ex ios 3.7.0), then cli + lib
 should do a minor jump (ex 4.0.1)
 If a platform does a major version jump (ex android 4.0.0), then cli + lib
 should do a major jump. (ex up to 5.0.0)


I was thinking this when I was reading your first email in the thread. I
think it makes sense.

Interestingly, it also means that we could legitimately give the tools
release a version which is the *sum* of all of the platforms included :)


 Platform versioning:

 Introduce any breaking changes, bump major
 Regular releases, bump minor
 Small fixes, bump patch

 Questions for platforms:


All my opinions:


 1) What happens when cordova-iOS adds support for iOS8? (3.7.0 or 4.0.0)

Minor version bump

2) What happens when cordova-iOS drops support for iOS6?

Major version bump


 3) How do we ensure we have common functionality between different
 platforms? When we went from 2.x to 3.x, all platforms had to have similar
 subset of features. If cordova-android is at version 7.0.0, cordova-ios at
 5.0.0, cordova-firefoxos at 3.7.0, how do keep track of this? Is being tied
 to a specific CLI version with docs enough?

This is harder, especially if platforms don't all get the feature at  the
same time. I would suggest that we solve it with documentation.

4) Windows adds universal app support, what is the version for
 cordova-windows?

Minor version bump

 5) Windows supports windows 10, what is the version?

Minor bump



 Plugin Versioning

 Non backwards compatible change, bump major
 Adding new api/feature, keeping backwards compatibility, bumb minor
 Small bug fixes, Most of our regular releases, bump patch

Sounds about right!

There's some interplay between plugins and platforms as well: when a
feature is added to one platform in one version, and then to a second
platform in another version. I suppose it's two minor bumps in that case,
but I'd want to be careful to avoid the analogous situation where we have
to have two, three, or more major bumps in a row because of out-of-sync
platform-specific changes.





 Feedback please!





 On Thu, Oct 2, 2014 at 1:48 PM, Parashuram Narasimhan (MS OPEN TECH) 
 panar...@microsoft.com javascript:; wrote:

  Would jumping to 4.x mean we have to re-tag restart the vote process?
  Traditionally, Cordova has had major version bump close to Phonegap day -
  If we continue this to be 3.7.0, will we have another release close to
  Phonegap day, calling that 4.0 ?
 
  -Original Message-
  From: brian.ler...@gmail.com javascript:; [mailto:
 brian.ler...@gmail.com javascript:;] On Behalf Of
  Brian LeRoux
  Sent: Thursday, October 2, 2014 12:58 PM
  To: Steven Gill
  Cc: Shazron; dev@cordova.apache.org javascript:;
  Subject: Re: Independent platform release summary
 
  I'm down with jumping to 4.x but not convinced a jump to 5.x would
  actually spur more understanding. (Also thanks for tackling this Steve.)
 
  On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill stevengil...@gmail.com
 javascript:;
  wrote:
 
   I'm not opposed to a big version jump. It would draw attention to the
   fact that we are changing our versioning  releasing process. How do
   others feel?
  
   -Steve
  
   On Thu, Oct 2, 2014 at 11:45 AM, Shazron shaz...@gmail.com
 javascript:; wrote:
  
Thanks Steve for writing that up.
I can definitely see the confusion in messaging, especially at the
start of this new process.
   
So for 2) CLI + Lib version I am proposing a radical idea (à la
Windows
10) where we jump to a new version totally separate from the current
3.x series to further detach the association of the CLI version with
platform versions. 

Re: WKWebView for iOS8

[Ian Clelland]

Fantastic news if it works!

Do we have any idea whether a page loaded with this API will have the
ability to navigate to other URLs in the same origin?
On 27 Sep 2014 10:08, Shazron shaz...@gmail.com wrote:

Fixed 8 hrs ago! 
http://trac.webkit.org/changeset/174029/trunk

On Friday, September 26, 2014, Ally Ogilvie aogil...@wizcorp.jp wrote:

 Indeed.
 FYI, for others reading this, Apple Devs (including Tim) won't engage in
an
 Apple related interrogations. :)

 On Fri, Sep 26, 2014 at 4:23 PM, Shazron shaz...@gmail.com
javascript:;
 wrote:

  Good news, kind of. Ally was re-tweeting Timothy Hatcher (WebKit
 Developer
  Experience Manager at Apple) so I looked back at his timeline and he
says
  that the file:// url bug is Top of our list:
  https://twitter.com/xeenon/status/514536288590893056
 
  Which sounds promising. They never comment on timelines so we don't know
  when the bug fix will land. Reading his timeline, this bug (and the
  Safari upload one) was definitely the result of them tightening the
 WebKit
  sandbox on iOS.
 
  On Thu, Sep 25, 2014 at 9:13 PM, Ally Ogilvie aogil...@wizcorp.jp
 javascript:; wrote:
 
   Not able to load web resource from within html that reference
   Library/Caches/*.jpg :(
   As you said; looks like a total whitelist-style security policy.
  
   On Fri, Sep 26, 2014 at 12:44 PM, Ally Ogilvie aogil...@wizcorp.jp
 javascript:;
   wrote:
  
Not too bothered about that as long as all our assets
(images/sounds)
  can
be downloaded into cache and the html in /tmp can load them.
   
As discussed a previous thread I (we/Wizcorp) have a native loader
to
steam the game/app from cloudz. As long as we can put html to /tmp
 and
assets to cache, html is light enough to be re-downloaded each time.
   
For offline mode we may restore html to /tmp from a saved blob in
   database
in /cache or NSData in NSUserDefaults.
   
   
   
On Fri, Sep 26, 2014 at 12:13 PM, Shazron shaz...@gmail.com
 javascript:; wrote:
   
Also, since it is in tmp -- eventually you will leave to copy over
 the
www,
*again* once the system clears it out. That's no good.
   
On Thu, Sep 25, 2014 at 7:50 PM, Shazron shaz...@gmail.com
 javascript:; wrote:
   
 Ally - I seriously doubt it, this appears to be more low level.
 When
using
 loadHTMLString to load the initial HTML file it is fine, but any
   assets
 that the HTML tries to load is subject to the low level loader
  which I
 presume has a security policy disallowing unauthorized locations.

 You could modify my test project to test it out but it has to be
 dynamically generated since the (hard-coded) paths will be
 different
   on
 each environment.

 In any case if it worked, it would not be a 'simple' solution.

 --- An idea, perhaps on first load, it loads on UIWebView, then
 next
time,
 WKWebView after the bundle has been copied? The more that I think
   about
it,
 none of this is a good solution, it's really a hack. I would say
  local
web
 server is looking more and more better.

 On Thu, Sep 25, 2014 at 7:25 PM, Ally Ogilvie 
 aogil...@wizcorp.jp javascript:;
wrote:

 Not tested but i'd be interested to know if once the html from
 /tmp
   is
 loaded, can the html pull in images using img / with a path of
file:///
 absolute path to library caches /myImage.jpg.

 On Fri, Sep 26, 2014 at 11:14 AM, Brian LeRoux b...@brian.io
 javascript:; wrote:

  cool, guess this is a bit of a startup penalty (but that'd be
  it?)
 
  On Thu, Sep 25, 2014 at 7:05 PM, Shazron shaz...@gmail.com
 javascript:;
   wrote:
 
   Mixed news from iOS 8.0.2. Only local files from *tmp* can
be
loaded.
  Test
   using https://github.com/shazron/WKWebViewFIleUrlTest
  
  
  
   Documents, Library, Library/Caches and inside your app
bundle
  --
   no
 files
   there can be loaded using the file:// protocol, only from
 tmp.
  
  
  
   The Safari file upload fix probably allowed tmp file://
 loading
thus
   allowing it for WKWebView as well.
  
  
   So we can use this -- all we need is to copy the www folder
 to
   tmp,
 easy.
  
   On Thu, Sep 18, 2014 at 9:03 AM, Shazron shaz...@gmail.com
 javascript:;
wrote:
  
Yeah no update in iOS 8 GM. So moving to contingency. I
 still
think
  it's
   a
bug and not a policy change:
https://issues.apache.org/jira/browse/CB-7539
   
Should be pretty easy (minus the securing it part is a bit
  more
 work).
   
   
On Wed, Sep 17, 2014 at 8:31 PM, Ally Ogilvie 
aogil...@wizcorp.jp javascript:;
   wrote:
   
Interested in any updates if you have 'em @Shazron ?
Following Brian's tweet i'm kinda hoping there has been a
 breakthrough
   to
load local files!
  

Re: plugin with AAR

[Ian Clelland]

Work in progress is serious here. I wouldn't count on the Gradle build
being completely stable until you see a 3.7 or a 4.0 release candidate.

If you're developing plugins with specialized build requirements using
Gradle, we're very eager to accommodate you. Just be aware that it's a
moving target at this point.

Ian

On Tuesday, September 23, 2014, Andrew Grieve agri...@chromium.org wrote:

 Gradle support on master is still somewhat a work-in-progress, but I think
 it's coming along nicely :)

 What you want to do hasn't been done before that I know of, but it *might*
 just work if you add a build-extras.gradle to your plugin and adding the
 extra Dependencies line in there.

 More eyes on Gradle would be great, as it's still changing quite a bit.

 On Tue, Sep 23, 2014 at 4:02 AM, Fu, Junwei junwei...@intel.com
 javascript:; wrote:

  Hi,
 
  I know that the cordova-android master can build subproject with Gradle,
  but I have a question. I want to develop a plugin that dependence AAR
 from
  remote maven repository, the AAR is library project. I need to make the
  plugin to  android project which include AndroidManifest.xml and
  project.properties files, but it isn't  what I want. I expect simple
  development with follow steps:
 
  1.   Develop plugin with AAR
 
  Write a library.gradle file that include how to compiling the AAR, it
  looks like:
 
  Repositories {
 
 Maven {
 
  mavenCentral()
 
}
 }
 
 Dependencies {
 Compile 'com.sqlcipher:sqlcipher:3.0.1'
  }
 
 
  2.   Plugman install the plugin
 
  The plugin library.gradle can apply to build.gradle that host in root
  project.
 
 
 
  3.   The build multiple apk can open after install the plugin.
 
  Can we develop cordova plugin like that?
 
  Thanks,
  Junwei.
 

Re: new NPM 2.x

[Ian Clelland]

It shouldn't matter for users, but I have seen several issues in the past
where using the wrong version of npm means that you can't publish modules
or plugins. It's something to be aware of, at least.

On Mon, Sep 22, 2014 at 12:30 PM, Ray Camden rayca...@adobe.com wrote:

 Being lazy, but can you explain why it matters? Ie, is there a reason
 *not* to just upgrade? I assume most folks would think, ³new version of
 npm, just update and don¹t worry about it² - but does it impact using
 Cordova?


 On 9/22/14, 11:09 AM, Carlos Santana csantan...@gmail.com wrote:

 NPM 2.x was released last week.
 
 latest nodejs stable 0.10.32 comes with npm@1.4.28
 
 if you do $ npm install -g npm  (you will get npm@2.0.0)
 
 More about npm 2.x and semver:
 http://blog.npmjs.org/post/98131109725/npm-2-0-0
 
 cordova and phonegap get's mentioned in the blog post.
 
 For now just pay close attention which npm you are using 1.x or 2.x with $
 npm -v
 
 --
 Carlos Santana
 csantan...@gmail.com

Re: prepare logic decoupling between LIB and Platforms

[Ian Clelland]

It would seem that the separation in that case should be between what and
how -- make -lib responsible for what needs to be done (add an icon,
add a splash screen, set the start page), and the platforms responsible for
actually implementing it.

(Obviously easy to say; I'm sure there are a hundred things I haven't
thought of. We could at least start by looking at the use cases: see what
common things -lib is currently responsible for)

On Fri, Sep 19, 2014 at 10:00 AM, Michal Mocny mmo...@chromium.org wrote:

 Not sure about this.  On the surface the request seems fine, but I think
 its easier to do lib updates than platform updates, and the reverse problem
 would happen if we made the switch: if we want to improve the way we do
 parsing (say to add a new config option), we now have to do a full platform
 release and get users to upgrade their projects.

 -Michal

 On Fri, Sep 19, 2014 at 9:27 AM, Sergey Grebnov (Akvelon) 
 v-seg...@microsoft.com wrote:

  Hi,
 
  Currently LIB is on response for handling config.xml params and updating
  platforms, for example on Android[1] LIB edits AndroidManifest.xml as per
  config.xml, handles icons and splash images, etc.  Moving forward with
  independed platform releases I see how it would be valuable to be able
 add
  some changes to prepare logic  with platform release. Another point of
  moving this logic to platforms is better decoupling of platform specific
  logic/code and shared functionality managed by LIB.
 
  So I propose to add 'prepare' script to the platforms similar to
  build/deploy so that LIB contains minimal required functionality and the
  rest of the logic is exposed by platform itself.
 
  Thoughts?
 
  [1]
 
 https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/metadata/android_parser.js
 
  Thx!
  Sergey
 

Re: Cordova Meetup @ Google Berlin

[Ian Clelland]

So, this is getting finalized -- I think that Brian has sent out a message
to everyone who had tickets to PGDEU; I'm not sure what other avenues are
good for getting the word out.

There's going to be an all-day event at the Google Berlin office next
Friday; I'd *love* it if anyone from the dev@ list could make it! If you
can, there's a signup form at
https://docs.google.com/forms/d/1oXkGhlaoTKBU1fbcxdLX0HFXThbcU7wonPoLry8SX1A
-- put your name down, and I'll make sure that there's a spot for you

On Fri, Sep 12, 2014 at 6:01 PM, Ian Clelland iclell...@chromium.org
wrote:



 On Friday, September 12, 2014, Archana Naik naik.arch...@gmail.com
 wrote:

 Wow!! This is a news to me...When did it get rescheduled? Is it happening
 at all?


 And, re-reading your message, I realize you probably didn't see what
 prompted this: I only saw yesterday, on pgday.phonegap.com, that the
 European conference had been postponed until spring 2015.

 It seems that Adobe has been refunding the event tickets. Several of us
 have non-refundable travel plans, though, so we're making the best of it :)



 On Fri, Sep 12, 2014 at 1:52 PM, Michal Mocny mmo...@chromium.org
 wrote:

  3 Googlers have non refundable tickets, and probably there are a few
 others
  who are already too excited about oktoberfest to back out ;)
 
  Anyway, Ian found a meetup was already being organized spontaneously (
  www.meetup.com/Hybrid-Mobile-App-Meetup-Berlin/events/206658982/), so
  Andrew secured a room in the Google Berlin office since it happened to
 be
  free.
 
  I won't be going either, sadly.
 
  -Michal
 
  On Fri, Sep 12, 2014 at 4:46 PM, Joe Bowser bows...@gmail.com wrote:
 
   Sadly, I already pulled the plug on my Berlin trip yesterday.  Perhaps
  this
   would make more sense in San Francisco next month.
  
   On Fri, Sep 12, 2014 at 1:43 PM, Ian Clelland iclell...@chromium.org
 
   wrote:
  
Since it appears that PhoneGapDayEU has been postponed, and there
 are
several of us already committed to going to Berlin, we (Google)
 figured
that we might take the opportunity to host a Cordova / PhoneGap
 meetup
  in
our Berlin office, on the original conference dates.
   
I've put up a quick site here, to which I'll add more details as
 soon
  as
   I
have them: http://goo.gl/BVRmIe
   
I know that some people have cancelled travel plans already, but I
 hope
   we
can still see some folks there!
   
Ian
   
  
 

Re: Android: activityResultKeepRunning

[Ian Clelland]

The patch that they applied was actually taken from the
Cordova-crosswalk-engine plugin, so in this case, they're keeping up with
us :)

And yeah, once we get this all sorted out, it should be documented.

On Fri, Sep 12, 2014 at 1:55 AM, Andrey Kurdumov kant2...@googlemail.com
wrote:

 Hi,

 I periodically check how Crosswalk engine developed and seen that they land
 functionality which you are discussing today/yesterday
 https://github.com/crosswalk-project/crosswalk-cordova-android/pull/136

 Maybe there make sense keep compatibility with them too. Or at least if
 timers would be paused, this should be documented.
 Would be good if alternative engines have compatible lifecycle as much as
 possible.

 Best regargs,
 Andrey Kurdyumov


 2014-09-12 0:58 GMT+06:00 Andrew Grieve agri...@chromium.org:

  I guess I can see the value of providing a safety option for pause my
  app in the background, but in general I think it's better practice to
  not pause forcefully, and instead have apps listen to the pause
  event, and stop battery-draining activity there instead. So... let's
  keep the option in, and keep it off by default.
 
  Joe / Tommy - not sure from your comments as to whether they were
  directed at the idea of removing the option completely, or to the
  patch I sent that gets rid of unconditionally pausing timers during
  startActivityForResult flows. Really can't see why you'd want that,
  and I think it would just cause subtle bugs.
 
  On Wed, Sep 10, 2014 at 8:42 PM, Tommy Williams to...@devgeeks.org
  wrote:
   Big -1 for breaking current background behaviour.
  
   Or am I misunderstanding?
   On 11 Sep 2014 10:34, Joe Bowser bows...@gmail.com wrote:
  
   Pausing timers means that the JS isn't running in the background at
 all.
This now means that the Javascript is running constantly, regardless
 of
   whether it's an event.  This means that setInterval is still running.
  This
   could break people's applications.
  
   On Wed, Sep 10, 2014 at 5:29 PM, Andrew Grieve agri...@chromium.org
   wrote:
  
Getting off track here a bit.
   
Here's what I'm suggesting with my original email:
   
   
  
 
 https://github.com/agrieve/cordova-android/compare/apache:4.0.x...no_disable_timers?expand=1
   
I was further asking if there was any use in ever pausing timers
 (aka,
removing the KeepRunning preference).
   
   
   
On Wed, Sep 10, 2014 at 4:56 PM, Brian LeRoux b...@brian.io wrote:
 I consider 4 a release branch. Merge in tested green lit code to
  your
 hearts desire but 4.0 is definitely not a feature. It should be
  always
in a
 releasable state.
 On Sep 10, 2014 1:53 PM, Michal Mocny mmo...@chromium.org
  wrote:

 Question is, do you consider the fact that bugs are introduced 
discovered
 (possibly with pain) a sign that the system is broken, or a sign
  that
the
 system is working?

 I sense that Andrew worries that if work has to land on a feature
branch of
 this feature branch, it won't get eyeballs.

 I sense that Joe worries that if we land everything/anything in
Android-4.0
 it will become unstable, as mistakes are prone to happen (see
 i.e.
recent
 issue with black background).

 Personally, I prefer eyeballs and instability to delayed
 discovery
   and a
 sense of stability, especially for a feature branch like
  Android-4.0.
  There are workarounds for demos (i.e. create your own branch off
  of a
 known working version), but its not as easy to solve the eyeball
problem.

 -Michal

 On Wed, Sep 10, 2014 at 3:50 PM, Joe Bowser bows...@gmail.com
   wrote:

  I think this needs to be thought through more, and I'm
 extremely
   wary
 when
  you say this is a single commit, especially based on the last
  couple
of
  months and how long it took 3.6 to go through.  Given that we
  have
people
  travelling halfway across the planet who intend to show people
  their
work
  in less than two weeks, I would definitely like it if you were
 to
   put
 this
  in your own branch for testing.
 
  On Wed, Sep 10, 2014 at 12:41 PM, Andrew Grieve 
   agri...@chromium.org

  wrote:
 
   I don't think there'd be much value in that. It'll be a
 single
commit
   that almost entirely just deletes lines.
  
   What do you think about the never auto-pausing on
  backgrounding?
   or
   about auto-pausing when intent sending?
  
   On Wed, Sep 10, 2014 at 12:32 PM, Joe Bowser 
  bows...@gmail.com
 wrote:
Can you put this on its own branch before it lands in
 4.0.x?
That'd
 be
awesome!
   
On Tue, Sep 9, 2014 at 5:32 PM, Andrew Grieve 
agri...@chromium.org
   wrote:
   
For cordova-android 4.0, I'd like to go as far as just
  deleting
the
KeepRunning preference.
   
Apps get a 

Re: Is there any plan to make InAppBrowser plugin based on CordovaWebView

[Ian Clelland]

On Fri, Sep 12, 2014 at 2:23 AM, julio cesar sanchez jcesarmob...@gmail.com
 wrote:

 About the WKWebView and UIWebView being the only renderers because the
 apple rule, ludei's cocoonjs uses their own renderer based on chromium


Do you have a source for that claim? It would be incredibly cool (and maybe
even possible, according to a strict reading of Apple's review guidelines),
but I can't confirm it.

The closest thing that I can find is their Webview+ project, for Android
4.0+ (http://support.ludei.com/hc/en-us/articles/201952993), and the
release notes announcing it (
http://support.ludei.com/hc/en-us/articles/201941147-CocoonJS-v2-0-0), but
also only for Android.

Ian

Re: Is there any plan to make InAppBrowser plugin based on CordovaWebView

[Ian Clelland]

Technically we could browse the web, though. Just setting

access origin=* /
content src=https://www.google.com/; /

in your config.xml is enough to turn your app into a general-purpose
Cordova-enabled web browser.

That's what I mean by a strict reading, though: A properly-sandboxed
Cordova application should be able to use whatever sort of code it wants,
to do its own internal UI rendering, as long as it doesn't ever
accidentally use that code to render external web pages.

I don't know if anyone is willing to put the necessary engineering
resources into actually developing another HTML rendering engine for iOS,
though, given that it could only ever be used for hybrid apps, and that
Apple would be free to reject apps based on it anyway, if their reading of
the terms differs from mine.


On Fri, Sep 12, 2014 at 11:54 AM, julio cesar sanchez 
jcesarmob...@gmail.com wrote:

 Anyway, reading the app store policies


- 2.17

Apps that browse the web must use the iOS WebKit framework and WebKit
Javascript


 Technically we don't browse the web, that should apply to InAppBrowser
 plugin only

Cordova Meetup @ Google Berlin

[Ian Clelland]

Since it appears that PhoneGapDayEU has been postponed, and there are
several of us already committed to going to Berlin, we (Google) figured
that we might take the opportunity to host a Cordova / PhoneGap meetup in
our Berlin office, on the original conference dates.

I've put up a quick site here, to which I'll add more details as soon as I
have them: http://goo.gl/BVRmIe

I know that some people have cancelled travel plans already, but I hope we
can still see some folks there!

Ian

Re: Cordova Meetup @ Google Berlin

[Ian Clelland]

It's not phonegapday -- we definitely don't have the organization to throw
together a whole conference in  2 weeks :)

I expect it'll be a less formal meetup, with presentations, and a chance to
get together and hang out with other devs, and hopefully some contributors.

On Friday, September 12, 2014, Archana Naik naik.arch...@gmail.com wrote:

 Wow!! This is a news to me...When did it get rescheduled? Is it happening
 at all?

 On Fri, Sep 12, 2014 at 1:52 PM, Michal Mocny mmo...@chromium.org
 javascript:; wrote:

  3 Googlers have non refundable tickets, and probably there are a few
 others
  who are already too excited about oktoberfest to back out ;)
 
  Anyway, Ian found a meetup was already being organized spontaneously (
  www.meetup.com/Hybrid-Mobile-App-Meetup-Berlin/events/206658982/), so
  Andrew secured a room in the Google Berlin office since it happened to be
  free.
 
  I won't be going either, sadly.
 
  -Michal
 
  On Fri, Sep 12, 2014 at 4:46 PM, Joe Bowser bows...@gmail.com
 javascript:; wrote:
 
   Sadly, I already pulled the plug on my Berlin trip yesterday.  Perhaps
  this
   would make more sense in San Francisco next month.
  
   On Fri, Sep 12, 2014 at 1:43 PM, Ian Clelland iclell...@chromium.org
 javascript:;
   wrote:
  
Since it appears that PhoneGapDayEU has been postponed, and there are
several of us already committed to going to Berlin, we (Google)
 figured
that we might take the opportunity to host a Cordova / PhoneGap
 meetup
  in
our Berlin office, on the original conference dates.
   
I've put up a quick site here, to which I'll add more details as soon
  as
   I
have them: http://goo.gl/BVRmIe
   
I know that some people have cancelled travel plans already, but I
 hope
   we
can still see some folks there!
   
Ian
   
  
 

Re: Cordova Meetup @ Google Berlin

[Ian Clelland]

On Friday, September 12, 2014, Archana Naik naik.arch...@gmail.com wrote:

 Wow!! This is a news to me...When did it get rescheduled? Is it happening
 at all?


And, re-reading your message, I realize you probably didn't see what
prompted this: I only saw yesterday, on pgday.phonegap.com, that the
European conference had been postponed until spring 2015.

It seems that Adobe has been refunding the event tickets. Several of us
have non-refundable travel plans, though, so we're making the best of it :)



 On Fri, Sep 12, 2014 at 1:52 PM, Michal Mocny mmo...@chromium.org
 javascript:; wrote:

  3 Googlers have non refundable tickets, and probably there are a few
 others
  who are already too excited about oktoberfest to back out ;)
 
  Anyway, Ian found a meetup was already being organized spontaneously (
  www.meetup.com/Hybrid-Mobile-App-Meetup-Berlin/events/206658982/), so
  Andrew secured a room in the Google Berlin office since it happened to be
  free.
 
  I won't be going either, sadly.
 
  -Michal
 
  On Fri, Sep 12, 2014 at 4:46 PM, Joe Bowser bows...@gmail.com
 javascript:; wrote:
 
   Sadly, I already pulled the plug on my Berlin trip yesterday.  Perhaps
  this
   would make more sense in San Francisco next month.
  
   On Fri, Sep 12, 2014 at 1:43 PM, Ian Clelland iclell...@chromium.org
 javascript:;
   wrote:
  
Since it appears that PhoneGapDayEU has been postponed, and there are
several of us already committed to going to Berlin, we (Google)
 figured
that we might take the opportunity to host a Cordova / PhoneGap
 meetup
  in
our Berlin office, on the original conference dates.
   
I've put up a quick site here, to which I'll add more details as soon
  as
   I
have them: http://goo.gl/BVRmIe
   
I know that some people have cancelled travel plans already, but I
 hope
   we
can still see some folks there!
   
Ian
   
  
 

Re: [DISCUSS] Plugins Release

[Ian Clelland]

I've seen the same thing with the new test runner.. it appears that the
framework itself is rather fragile, and certain things, like calling done()
twice within a test, will cause the whole test runner to go wonky.

The file tests did this a couple of weeks ago, and I resolved it with
CB-7431; I was running into it again this morning with the Contacts tests
on Android, but the CB-7532 fix seems to have helped that.

On Thu, Sep 11, 2014 at 1:22 PM, Archana Naik naik.arch...@gmail.com
wrote:

 I am not sure if they are blockers. Mostly not. I am seeing about 12
 failures. spec 83, 84, 100,104,105,106108,110,113,114116,125,126127,128.
 I am also seeing weird thing about mobilespec reporting the failures. It
 reports each failure twice and runs the whole autotests twice. On top
 window i see finished in 50.0003s finished in 14.209s twice. Ofcourse
 second run reports almost double the failures coz it adds from previous
 run.

 As far as plugin release goes, i think we will need sometime in debugging
 these failures as well as mobilespec reporting bugs. I suppose we can go
 ahead with release and I will fix in parallel in master branch of file
 plugin.
 sounds good?

 Archana

 On Thu, Sep 11, 2014 at 10:07 AM, Martin Gonzalez 
 martin.c.glez.g...@gmail.com wrote:

  Hi Archana, which specs or what kind of failures are you getting over
  amazon-fireOs? is there any Jira Item related to that?
 
  2014-09-11 12:02 GMT-05:00 Marcel Kinard cmarc...@gmail.com:
 
   Archana, do you think these are a blocker? If so, what would be your
 time
   estimate to get them fixed?
  
   On Sep 11, 2014, at 12:00 PM, Archana Naik naik.arch...@gmail.com
  wrote:
  
With latest tests in plugins, I am seeing many failures on
  amazon-fireos
esp in file tests. I would like to fix those if possible.
  
  
 
 
  --
  Regards,
  Martin Gonzalez