Re: [DISCUSS] Cordova-Android 4.0.0 Release
. 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 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
merged. thanks! On Thu, Apr 9, 2015 at 3:01 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I have another small PR to the blog post for the release: https://github.com/cordova/apache-blog-posts/pull/36/commits Thanks, Nikhil -Original Message- From: Serge Huijben [mailto:s.huij...@gmail.com] Sent: Thursday, April 9, 2015 11:47 AM To: Ian Clelland; dev@cordova.apache.org Cc: leo.treggi...@intel.com Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release Then, it seems strange to me that it logs an error and repeated warnings if the meta tag is missing. Perhaps we should remove that from the plugin. Op do 9 apr. 2015 om 20:21 schreef Ian Clelland iclell...@chromium.org Moving from [VOTE] thread: On Thu, Apr 9, 2015 at 1:44 PM, Serge Huijben s.huij...@gmail.com wrote: But why is the meta csp tag required? It's not required, only recommended. It's more secure, as it can restrict more network access than the whitelist itself is capable of. (streaming audio and video tags, for instance). On Thu, Apr 9, 2015 at 1:44 PM, Treggiari, Leo leo.treggi...@intel.com wrote: Another question, based upon my understanding, which must be wrong! The 4.0.0 Android Release will require the cordova-plugin-whitelist in order to get a whitelist implemented correctly. Given its name (dash-style) it is only available as an node component. The is no released CLI that knows how to fetch from npm? Or does 4.3, even though I don't see it in the release notes? Even so, there are many previous CLI releases which will not work? This is at least partly resolved by the fact that no released CLI points to cordova-android 4.0.0. Once 4.0.0 is released. we will be able to release a version of the CLI which downloads it by default. The whitelist plugins are published already, and discussion is underway about voting/releasing cordova-lib (and accompanying tools), so I think there are only two possible timelines: A) whitelist plugins released, then cordova-android 4 released, then tools released (supports NPM plugins and Android 4). B) plugins released, then tools released (supports NPM plugins), then cordova-android 4 released, then a small bump of tools is released (to pin to cordova-android 4) In either case, users of the released CLI always have a version which works. It would be good for the release notes to explain the situation. Leo On Thu, Apr 9, 2015 at 1:24 PM, Michal Mocny mmo...@chromium.org wrote: Splashscreens was mentioned, icons was not. I don't think there is an icons change? On Thu, Apr 9, 2015 at 1:17 PM, Joe Bowser bows...@gmail.com wrote: So, wasn't there a change regarding icons and spashscreens being moved? I have no idea if we want to add that, or if adding that should happen after the release? On Wed, Apr 8, 2015 at 7:09 PM Andrew Grieve agri...@chromium.org wrote: CB-8684 is now merged and I've updated the targetSdk (and made a couple other changes). I'll start the release process in the morning as long as there no objections. On Tue, Apr 7, 2015 at 2:20 PM, Andrew Grieve agri...@chromium.org wrote: I'll start on it once CB-8684 lands (Tony - assuming you'll have this done shortly and would prefer it lands?) On Tue, Apr 7, 2015 at 1:33 PM, Jesse purplecabb...@gmail.com wrote: Sweet! @purplecabbage risingj.com On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve agri...@chromium.org wrote: Let's do it! On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com wrote: So, I think we should put off the embedder's guide until after the release. A lot of it has changed, and since we're still technically obligated to support the 3.x release tree for six months, that should buy us some time to figure out how that is going to work. Getting Cordova to work with a vanilla Android Studio project is a non-trivial task. Given that everything else appears to be done, should we start voting on an RC for this? What do people think? On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve agri...@chromium.org wrote: Here's issues: https://issues.apache.org/jira/browse/CB-8715 (docs) https://issues.apache.org/jira/browse/CB-8716 (whitelist) https://issues.apache.org/jira/browse/CB-8717 (write RELEASENOTES.md) On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana csantan...@gmail.com wrote: I would say let's start RC testing and voting, But not pin the version in Cordova CLI until the tasks that Andrew mentioned
Re: [DISCUSS] Cordova-Android 4.0.0 Release
plugins, - and making it so that the default project template includes plugin name=cordova-plugin-whitelist /) On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
/jira/browse/CB-8717 (write RELEASENOTES.md) On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana csantan...@gmail.com wrote: I would say let's start RC testing and voting, But not pin the version in Cordova CLI until the tasks that Andrew mentioned are done. Andrew can you create the JIRA Items for the tasks that need to be done. I thought there was a discussion about creating JIRA Items to help track and know what's left for release something. - upgrade guide, - publishing whitelist plugins, - and making it so that the default project template includes plugin name=cordova-plugin-whitelist /) On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
there was a discussion about creating JIRA Items to help track and know what's left for release something. - upgrade guide, - publishing whitelist plugins, - and making it so that the default project template includes plugin name=cordova-plugin-whitelist /) On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
CB-8684 is now merged and I've updated the targetSdk (and made a couple other changes). I'll start the release process in the morning as long as there no objections. On Tue, Apr 7, 2015 at 2:20 PM, Andrew Grieve agri...@chromium.org wrote: I'll start on it once CB-8684 lands (Tony - assuming you'll have this done shortly and would prefer it lands?) On Tue, Apr 7, 2015 at 1:33 PM, Jesse purplecabb...@gmail.com wrote: Sweet! @purplecabbage risingj.com On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve agri...@chromium.org wrote: Let's do it! On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com wrote: So, I think we should put off the embedder's guide until after the release. A lot of it has changed, and since we're still technically obligated to support the 3.x release tree for six months, that should buy us some time to figure out how that is going to work. Getting Cordova to work with a vanilla Android Studio project is a non-trivial task. Given that everything else appears to be done, should we start voting on an RC for this? What do people think? On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve agri...@chromium.org wrote: Here's issues: https://issues.apache.org/jira/browse/CB-8715 (docs) https://issues.apache.org/jira/browse/CB-8716 (whitelist) https://issues.apache.org/jira/browse/CB-8717 (write RELEASENOTES.md) On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana csantan...@gmail.com wrote: I would say let's start RC testing and voting, But not pin the version in Cordova CLI until the tasks that Andrew mentioned are done. Andrew can you create the JIRA Items for the tasks that need to be done. I thought there was a discussion about creating JIRA Items to help track and know what's left for release something. - upgrade guide, - publishing whitelist plugins, - and making it so that the default project template includes plugin name=cordova-plugin-whitelist /) On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
Let's do it! On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com wrote: So, I think we should put off the embedder's guide until after the release. A lot of it has changed, and since we're still technically obligated to support the 3.x release tree for six months, that should buy us some time to figure out how that is going to work. Getting Cordova to work with a vanilla Android Studio project is a non-trivial task. Given that everything else appears to be done, should we start voting on an RC for this? What do people think? On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve agri...@chromium.org wrote: Here's issues: https://issues.apache.org/jira/browse/CB-8715 (docs) https://issues.apache.org/jira/browse/CB-8716 (whitelist) https://issues.apache.org/jira/browse/CB-8717 (write RELEASENOTES.md) On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana csantan...@gmail.com wrote: I would say let's start RC testing and voting, But not pin the version in Cordova CLI until the tasks that Andrew mentioned are done. Andrew can you create the JIRA Items for the tasks that need to be done. I thought there was a discussion about creating JIRA Items to help track and know what's left for release something. - upgrade guide, - publishing whitelist plugins, - and making it so that the default project template includes plugin name=cordova-plugin-whitelist /) On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
Sweet! @purplecabbage risingj.com On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve agri...@chromium.org wrote: Let's do it! On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com wrote: So, I think we should put off the embedder's guide until after the release. A lot of it has changed, and since we're still technically obligated to support the 3.x release tree for six months, that should buy us some time to figure out how that is going to work. Getting Cordova to work with a vanilla Android Studio project is a non-trivial task. Given that everything else appears to be done, should we start voting on an RC for this? What do people think? On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve agri...@chromium.org wrote: Here's issues: https://issues.apache.org/jira/browse/CB-8715 (docs) https://issues.apache.org/jira/browse/CB-8716 (whitelist) https://issues.apache.org/jira/browse/CB-8717 (write RELEASENOTES.md) On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana csantan...@gmail.com wrote: I would say let's start RC testing and voting, But not pin the version in Cordova CLI until the tasks that Andrew mentioned are done. Andrew can you create the JIRA Items for the tasks that need to be done. I thought there was a discussion about creating JIRA Items to help track and know what's left for release something. - upgrade guide, - publishing whitelist plugins, - and making it so that the default project template includes plugin name=cordova-plugin-whitelist /) On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
I'll start on it once CB-8684 lands (Tony - assuming you'll have this done shortly and would prefer it lands?) On Tue, Apr 7, 2015 at 1:33 PM, Jesse purplecabb...@gmail.com wrote: Sweet! @purplecabbage risingj.com On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve agri...@chromium.org wrote: Let's do it! On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com wrote: So, I think we should put off the embedder's guide until after the release. A lot of it has changed, and since we're still technically obligated to support the 3.x release tree for six months, that should buy us some time to figure out how that is going to work. Getting Cordova to work with a vanilla Android Studio project is a non-trivial task. Given that everything else appears to be done, should we start voting on an RC for this? What do people think? On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve agri...@chromium.org wrote: Here's issues: https://issues.apache.org/jira/browse/CB-8715 (docs) https://issues.apache.org/jira/browse/CB-8716 (whitelist) https://issues.apache.org/jira/browse/CB-8717 (write RELEASENOTES.md) On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana csantan...@gmail.com wrote: I would say let's start RC testing and voting, But not pin the version in Cordova CLI until the tasks that Andrew mentioned are done. Andrew can you create the JIRA Items for the tasks that need to be done. I thought there was a discussion about creating JIRA Items to help track and know what's left for release something. - upgrade guide, - publishing whitelist plugins, - and making it so that the default project template includes plugin name=cordova-plugin-whitelist /) On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
So, I think we should put off the embedder's guide until after the release. A lot of it has changed, and since we're still technically obligated to support the 3.x release tree for six months, that should buy us some time to figure out how that is going to work. Getting Cordova to work with a vanilla Android Studio project is a non-trivial task. Given that everything else appears to be done, should we start voting on an RC for this? What do people think? On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve agri...@chromium.org wrote: Here's issues: https://issues.apache.org/jira/browse/CB-8715 (docs) https://issues.apache.org/jira/browse/CB-8716 (whitelist) https://issues.apache.org/jira/browse/CB-8717 (write RELEASENOTES.md) On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana csantan...@gmail.com wrote: I would say let's start RC testing and voting, But not pin the version in Cordova CLI until the tasks that Andrew mentioned are done. Andrew can you create the JIRA Items for the tasks that need to be done. I thought there was a discussion about creating JIRA Items to help track and know what's left for release something. - upgrade guide, - publishing whitelist plugins, - and making it so that the default project template includes plugin name=cordova-plugin-whitelist /) On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
Here's issues: https://issues.apache.org/jira/browse/CB-8715 (docs) https://issues.apache.org/jira/browse/CB-8716 (whitelist) https://issues.apache.org/jira/browse/CB-8717 (write RELEASENOTES.md) On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana csantan...@gmail.com wrote: I would say let's start RC testing and voting, But not pin the version in Cordova CLI until the tasks that Andrew mentioned are done. Andrew can you create the JIRA Items for the tasks that need to be done. I thought there was a discussion about creating JIRA Items to help track and know what's left for release something. - upgrade guide, - publishing whitelist plugins, - and making it so that the default project template includes plugin name=cordova-plugin-whitelist /) On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
I would say let's start RC testing and voting, But not pin the version in Cordova CLI until the tasks that Andrew mentioned are done. Andrew can you create the JIRA Items for the tasks that need to be done. I thought there was a discussion about creating JIRA Items to help track and know what's left for release something. - upgrade guide, - publishing whitelist plugins, - and making it so that the default project template includes plugin name=cordova-plugin-whitelist /) On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
+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 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
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 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
+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
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: [DISCUSS] Cordova-Android 4.0.0 Release
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 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
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 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: [DISCUSS] Cordova-Android 4.0.0 Release
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 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
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 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: [DISCUSS] Cordova-Android 4.0.0 Release
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: [DISCUSS] Cordova-Android 4.0.0 Release
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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
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? This thread is a month long, and not the first discussion of 4.0.0 for Android. @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: [DISCUSS] Cordova-Android 4.0.0 Release
Why do we need both the legacy and new-style whitelists released before we do a cordova-android 4.0.x release? Is there something that the new-style whitelist needs to change in the API that would force us to do a 5.0.x release? On Mon Mar 02 2015 at 2:04:59 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: [DISCUSS] Cordova-Android 4.0.0 Release
it! (unless I'm missing something) On Wed, Feb 4, 2015 at 10:11 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
top-level LinearLayout. Plugins and embedders can easily add in layouts if they want. Still waiting on a tools release for 3.7.1. Still need to update platform docs for 4.0.0 But... I think that's it! (unless I'm missing something) On Wed, Feb 4, 2015 at 10:11 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
I'm just about finished working through fixing mobilespec to work with the latest whitelist changes. Once I've figured out things, I'll kick up a discuss about how it works. Right now, on master, all network requests are blocked without a plugin enabling them. But I think we should discuss whether we want to change that default, and the merits of installing the whitelist plugin by default. 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? This thread is a month long, and not the first discussion of 4.0.0 for Android. @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: [DISCUSS] Cordova-Android 4.0.0 Release
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: [DISCUSS] Cordova-Android 4.0.0 Release
/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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
, 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
I can't come up with any. Let's not delay the release on that. So, other than the platform docs, we should be good to go, right? On Thu Feb 19 2015 at 11:42:40 AM Andrew Grieve agri...@chromium.org wrote: Thanks for the quick review. I'll have a look through your comments. Now's a good time to change names, so feel free to suggest alternatives. On Thu, Feb 19, 2015 at 1:32 PM, Joe Bowser bows...@gmail.com wrote: I've done a quick read of the pull request and left some comments in there. I'm in Salt Lake this week, so I haven't had a chance to really test this pull request yet, but while I'm not in love with the naming convention used, it looks mostly OK. On Thu Feb 19 2015 at 11:19:51 AM Andrew Grieve agri...@chromium.org wrote: They would need to do similar to the PR for xwalk. It's actually a lot less code now to implement a custom engine, so I think it makes geckoview much more feasible. The embedded case (I'm guessing you mean layout xml?) is one of the unit tests. Have a look here: https://github.com/agrieve/cordova-android/blob/engine/ test/src/org/apache/cordova/test/CordovaWebViewTestActivity.java If we delete LinearLayout, we just pass the WebView itself to setContentView(). It will still have a FrameLayout as a parent (which is the unchangeable root View of all Activities) For reference, here's now NativePageTransitions inserts their own Layout: https://github.com/Telerik-Verified-Plugins/ NativePageTransitions/blob/ master/src/android/NativePageTransitions.java#L74 On Thu, Feb 19, 2015 at 1:01 PM, Joe Bowser bows...@gmail.com wrote: So, I know that XWalk is the only production-ready WebView right now, but what would other third party providers need to implement/change for their webviews to work? Also, I'm not clear how the embedded CordovaWebView use case would work in this scenario. If we delete the LinearLayout, what do we attach our view for the default use case? On Thu Feb 19 2015 at 10:39:59 AM Andrew Grieve agri...@chromium.org wrote: I've finished playing with third-party plugins. If anyone else wants to have fun with them, use --thirdpartyplugins in createmobilespec.js, and then find the manual test for them. TLDR - most compiled/worked fine. Two that interacted with Views a lot had lots of compile errors, but in the end I don't think there's a good way to fix them on our end. I've also taken some time to try and eliminate copy paste between AndroidWebView and XWalkWebView. I'd love to get some feedback on the changes (and hopefully get them in). More info /w PRs here: https://issues.apache.org/jira/browse/CB-8510 Another thing that came out of looking at these plugins is that they add in their own Layout, or have logic to handle various parent layout. So... I think we'd be fine (and should) delete our top-level LinearLayout. Plugins and embedders can easily add in layouts if they want. Still waiting on a tools release for 3.7.1. Still need to update platform docs for 4.0.0 But... I think that's it! (unless I'm missing something) On Wed, Feb 4, 2015 at 10:11 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
Yes, did some no-op changes on master to make the PR diff smaller / more readable. Are you saying some relate to existing JIRA issues, or that some should make JIRA issues for? Not saying none are deserving of one, just want to clarify what you're thinking. On Thu, Feb 19, 2015 at 1:38 PM, Joe Bowser bows...@gmail.com wrote: Andrew, I noticed a bunch of commits done 3 hours ago that were added. They're minor, but some should have some record in JIRA. I know that JIRA is a mess, but since we've talked about the issues on the list, we should probably track them. On Thu Feb 19 2015 at 11:32:07 AM Joe Bowser bows...@gmail.com wrote: I've done a quick read of the pull request and left some comments in there. I'm in Salt Lake this week, so I haven't had a chance to really test this pull request yet, but while I'm not in love with the naming convention used, it looks mostly OK. On Thu Feb 19 2015 at 11:19:51 AM Andrew Grieve agri...@chromium.org wrote: They would need to do similar to the PR for xwalk. It's actually a lot less code now to implement a custom engine, so I think it makes geckoview much more feasible. The embedded case (I'm guessing you mean layout xml?) is one of the unit tests. Have a look here: https://github.com/agrieve/cordova-android/blob/engine/test/ src/org/apache/cordova/test/CordovaWebViewTestActivity.java If we delete LinearLayout, we just pass the WebView itself to setContentView(). It will still have a FrameLayout as a parent (which is the unchangeable root View of all Activities) For reference, here's now NativePageTransitions inserts their own Layout: https://github.com/Telerik-Verified-Plugins/NativePageTransitions/blob/ master/src/android/NativePageTransitions.java#L74 On Thu, Feb 19, 2015 at 1:01 PM, Joe Bowser bows...@gmail.com wrote: So, I know that XWalk is the only production-ready WebView right now, but what would other third party providers need to implement/change for their webviews to work? Also, I'm not clear how the embedded CordovaWebView use case would work in this scenario. If we delete the LinearLayout, what do we attach our view for the default use case? On Thu Feb 19 2015 at 10:39:59 AM Andrew Grieve agri...@chromium.org wrote: I've finished playing with third-party plugins. If anyone else wants to have fun with them, use --thirdpartyplugins in createmobilespec.js, and then find the manual test for them. TLDR - most compiled/worked fine. Two that interacted with Views a lot had lots of compile errors, but in the end I don't think there's a good way to fix them on our end. I've also taken some time to try and eliminate copy paste between AndroidWebView and XWalkWebView. I'd love to get some feedback on the changes (and hopefully get them in). More info /w PRs here: https://issues.apache.org/jira/browse/CB-8510 Another thing that came out of looking at these plugins is that they add in their own Layout, or have logic to handle various parent layout. So... I think we'd be fine (and should) delete our top-level LinearLayout. Plugins and embedders can easily add in layouts if they want. Still waiting on a tools release for 3.7.1. Still need to update platform docs for 4.0.0 But... I think that's it! (unless I'm missing something) On Wed, Feb 4, 2015 at 10:11 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
Thanks for the quick review. I'll have a look through your comments. Now's a good time to change names, so feel free to suggest alternatives. On Thu, Feb 19, 2015 at 1:32 PM, Joe Bowser bows...@gmail.com wrote: I've done a quick read of the pull request and left some comments in there. I'm in Salt Lake this week, so I haven't had a chance to really test this pull request yet, but while I'm not in love with the naming convention used, it looks mostly OK. On Thu Feb 19 2015 at 11:19:51 AM Andrew Grieve agri...@chromium.org wrote: They would need to do similar to the PR for xwalk. It's actually a lot less code now to implement a custom engine, so I think it makes geckoview much more feasible. The embedded case (I'm guessing you mean layout xml?) is one of the unit tests. Have a look here: https://github.com/agrieve/cordova-android/blob/engine/ test/src/org/apache/cordova/test/CordovaWebViewTestActivity.java If we delete LinearLayout, we just pass the WebView itself to setContentView(). It will still have a FrameLayout as a parent (which is the unchangeable root View of all Activities) For reference, here's now NativePageTransitions inserts their own Layout: https://github.com/Telerik-Verified-Plugins/NativePageTransitions/blob/ master/src/android/NativePageTransitions.java#L74 On Thu, Feb 19, 2015 at 1:01 PM, Joe Bowser bows...@gmail.com wrote: So, I know that XWalk is the only production-ready WebView right now, but what would other third party providers need to implement/change for their webviews to work? Also, I'm not clear how the embedded CordovaWebView use case would work in this scenario. If we delete the LinearLayout, what do we attach our view for the default use case? On Thu Feb 19 2015 at 10:39:59 AM Andrew Grieve agri...@chromium.org wrote: I've finished playing with third-party plugins. If anyone else wants to have fun with them, use --thirdpartyplugins in createmobilespec.js, and then find the manual test for them. TLDR - most compiled/worked fine. Two that interacted with Views a lot had lots of compile errors, but in the end I don't think there's a good way to fix them on our end. I've also taken some time to try and eliminate copy paste between AndroidWebView and XWalkWebView. I'd love to get some feedback on the changes (and hopefully get them in). More info /w PRs here: https://issues.apache.org/jira/browse/CB-8510 Another thing that came out of looking at these plugins is that they add in their own Layout, or have logic to handle various parent layout. So... I think we'd be fine (and should) delete our top-level LinearLayout. Plugins and embedders can easily add in layouts if they want. Still waiting on a tools release for 3.7.1. Still need to update platform docs for 4.0.0 But... I think that's it! (unless I'm missing something) On Wed, Feb 4, 2015 at 10:11 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
I've done a quick read of the pull request and left some comments in there. I'm in Salt Lake this week, so I haven't had a chance to really test this pull request yet, but while I'm not in love with the naming convention used, it looks mostly OK. On Thu Feb 19 2015 at 11:19:51 AM Andrew Grieve agri...@chromium.org wrote: They would need to do similar to the PR for xwalk. It's actually a lot less code now to implement a custom engine, so I think it makes geckoview much more feasible. The embedded case (I'm guessing you mean layout xml?) is one of the unit tests. Have a look here: https://github.com/agrieve/cordova-android/blob/engine/ test/src/org/apache/cordova/test/CordovaWebViewTestActivity.java If we delete LinearLayout, we just pass the WebView itself to setContentView(). It will still have a FrameLayout as a parent (which is the unchangeable root View of all Activities) For reference, here's now NativePageTransitions inserts their own Layout: https://github.com/Telerik-Verified-Plugins/NativePageTransitions/blob/ master/src/android/NativePageTransitions.java#L74 On Thu, Feb 19, 2015 at 1:01 PM, Joe Bowser bows...@gmail.com wrote: So, I know that XWalk is the only production-ready WebView right now, but what would other third party providers need to implement/change for their webviews to work? Also, I'm not clear how the embedded CordovaWebView use case would work in this scenario. If we delete the LinearLayout, what do we attach our view for the default use case? On Thu Feb 19 2015 at 10:39:59 AM Andrew Grieve agri...@chromium.org wrote: I've finished playing with third-party plugins. If anyone else wants to have fun with them, use --thirdpartyplugins in createmobilespec.js, and then find the manual test for them. TLDR - most compiled/worked fine. Two that interacted with Views a lot had lots of compile errors, but in the end I don't think there's a good way to fix them on our end. I've also taken some time to try and eliminate copy paste between AndroidWebView and XWalkWebView. I'd love to get some feedback on the changes (and hopefully get them in). More info /w PRs here: https://issues.apache.org/jira/browse/CB-8510 Another thing that came out of looking at these plugins is that they add in their own Layout, or have logic to handle various parent layout. So... I think we'd be fine (and should) delete our top-level LinearLayout. Plugins and embedders can easily add in layouts if they want. Still waiting on a tools release for 3.7.1. Still need to update platform docs for 4.0.0 But... I think that's it! (unless I'm missing something) On Wed, Feb 4, 2015 at 10:11 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
They would need to do similar to the PR for xwalk. It's actually a lot less code now to implement a custom engine, so I think it makes geckoview much more feasible. The embedded case (I'm guessing you mean layout xml?) is one of the unit tests. Have a look here: https://github.com/agrieve/cordova-android/blob/engine/test/src/org/apache/cordova/test/CordovaWebViewTestActivity.java If we delete LinearLayout, we just pass the WebView itself to setContentView(). It will still have a FrameLayout as a parent (which is the unchangeable root View of all Activities) For reference, here's now NativePageTransitions inserts their own Layout: https://github.com/Telerik-Verified-Plugins/NativePageTransitions/blob/master/src/android/NativePageTransitions.java#L74 On Thu, Feb 19, 2015 at 1:01 PM, Joe Bowser bows...@gmail.com wrote: So, I know that XWalk is the only production-ready WebView right now, but what would other third party providers need to implement/change for their webviews to work? Also, I'm not clear how the embedded CordovaWebView use case would work in this scenario. If we delete the LinearLayout, what do we attach our view for the default use case? On Thu Feb 19 2015 at 10:39:59 AM Andrew Grieve agri...@chromium.org wrote: I've finished playing with third-party plugins. If anyone else wants to have fun with them, use --thirdpartyplugins in createmobilespec.js, and then find the manual test for them. TLDR - most compiled/worked fine. Two that interacted with Views a lot had lots of compile errors, but in the end I don't think there's a good way to fix them on our end. I've also taken some time to try and eliminate copy paste between AndroidWebView and XWalkWebView. I'd love to get some feedback on the changes (and hopefully get them in). More info /w PRs here: https://issues.apache.org/jira/browse/CB-8510 Another thing that came out of looking at these plugins is that they add in their own Layout, or have logic to handle various parent layout. So... I think we'd be fine (and should) delete our top-level LinearLayout. Plugins and embedders can easily add in layouts if they want. Still waiting on a tools release for 3.7.1. Still need to update platform docs for 4.0.0 But... I think that's it! (unless I'm missing something) On Wed, Feb 4, 2015 at 10:11 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
I've finished playing with third-party plugins. If anyone else wants to have fun with them, use --thirdpartyplugins in createmobilespec.js, and then find the manual test for them. TLDR - most compiled/worked fine. Two that interacted with Views a lot had lots of compile errors, but in the end I don't think there's a good way to fix them on our end. I've also taken some time to try and eliminate copy paste between AndroidWebView and XWalkWebView. I'd love to get some feedback on the changes (and hopefully get them in). More info /w PRs here: https://issues.apache.org/jira/browse/CB-8510 Another thing that came out of looking at these plugins is that they add in their own Layout, or have logic to handle various parent layout. So... I think we'd be fine (and should) delete our top-level LinearLayout. Plugins and embedders can easily add in layouts if they want. Still waiting on a tools release for 3.7.1. Still need to update platform docs for 4.0.0 But... I think that's it! (unless I'm missing something) On Wed, Feb 4, 2015 at 10:11 PM, Ian Clelland iclell...@chromium.org wrote: 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
So, I know that XWalk is the only production-ready WebView right now, but what would other third party providers need to implement/change for their webviews to work? Also, I'm not clear how the embedded CordovaWebView use case would work in this scenario. If we delete the LinearLayout, what do we attach our view for the default use case? On Thu Feb 19 2015 at 10:39:59 AM Andrew Grieve agri...@chromium.org wrote: I've finished playing with third-party plugins. If anyone else wants to have fun with them, use --thirdpartyplugins in createmobilespec.js, and then find the manual test for them. TLDR - most compiled/worked fine. Two that interacted with Views a lot had lots of compile errors, but in the end I don't think there's a good way to fix them on our end. I've also taken some time to try and eliminate copy paste between AndroidWebView and XWalkWebView. I'd love to get some feedback on the changes (and hopefully get them in). More info /w PRs here: https://issues.apache.org/jira/browse/CB-8510 Another thing that came out of looking at these plugins is that they add in their own Layout, or have logic to handle various parent layout. So... I think we'd be fine (and should) delete our top-level LinearLayout. Plugins and embedders can easily add in layouts if they want. Still waiting on a tools release for 3.7.1. Still need to update platform docs for 4.0.0 But... I think that's it! (unless I'm missing something) On Wed, Feb 4, 2015 at 10:11 PM, Ian Clelland iclell...@chromium.org wrote: 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
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 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
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? - 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? - *LinearLayoutSoftKeyboardDetect - delete it!* It's apparently already gone on Master. - 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? - 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) 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? 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 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
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-Android 4.0.0 Release
What are the test cases don't work for Crosswalk? I'd like to do whatever I can to help. -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 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: [DISCUSS] Cordova-Android 4.0.0 Release
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 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
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-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-Android 4.0.0 Release
for using geolocation and
interrupts
autotests running.
// That's why we have to pending that for
Windows
Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
navigator.geolocation.
getCurrentPosition(function
(p)
{
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: 30 // 5 minutes maximum
age of
cached
position
});
});
org.apache.cordova.geolocation.tests.tests watchPosition
method
success callback geolocation.spec.8 should be called with a
position
object
• Expected true to be false
it(geolocation.spec.8 should be called with a
Position
object, function (done) {
// this test asks for using geolocation and
interrupts
autotests running.
// That's why we have to pending that for
Windows
Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
successWatch = navigator.geolocation.
watchPosition(
function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: (5 * 60 * 1000) // 5
minutes
maximum
age of cached position
});
});
-Original Message-
From: Josh Bavari [mailto:jbav...@gmail.com]
Sent: Wednesday, January 28, 2015 8:30 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team,
I work for Ionic and I've had some involvement with the Cordova
project
since last year. At Ionic, we've released a Crosswalk build
using
Cordova
Android 4.0 so we can use the cordova crosswalk engine for the
ionic
platform.
I've been working with Ian and Andrew on this to gather more
understanding
and to get some help along the way. I must say, excellent work,
everyone.
As such, we've accumulated quite a bit of users who are
actively
using
Cordova Android 4.0. Currently, we've had over 10k test trials
with
it,
and
I'm happy to say, mostly it's been smooth.
What I've done is made a fork to adjust a few small things,
but for
the
most part, we're using 4.0.
I'd love to provide any more feedback that you'd wish.
Thanks again for the awesome work.
On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com
wrote:
Hey
So, it's finally here. I want to see us work more on
Pluggable
Webviews, and adding the API, but I think it's time that we
released
what we've been working on for almost a year to our users.
I know
that the API isn't exactly the most awesome we can make it,
but it
works, and I'd rather have it out at 80% than it sitting for
a few
more
months in limbo.
Are there any major blocking tasks that would prevent a vote
thread
that anyone knows about, or should we start firing up a
release?
I
don't think we're going to make our January date, but the
first
week
of February isn't that terrible.
Thoughts?
Joe
--
Clear thoughts produce clear results.
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
)
{
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: 30 // 5 minutes maximum age
of
cached
position
});
});
org.apache.cordova.geolocation.tests.tests watchPosition
method
success callback geolocation.spec.8 should be called with a
position
object
• Expected true to be false
it(geolocation.spec.8 should be called with a
Position
object, function (done) {
// this test asks for using geolocation and
interrupts
autotests running.
// That's why we have to pending that for
Windows
Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
successWatch = navigator.geolocation.
watchPosition(
function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: (5 * 60 * 1000) // 5 minutes
maximum
age of cached position
});
});
-Original Message-
From: Josh Bavari [mailto:jbav...@gmail.com]
Sent: Wednesday, January 28, 2015 8:30 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team,
I work for Ionic and I've had some involvement with the Cordova
project
since last year. At Ionic, we've released a Crosswalk build
using
Cordova
Android 4.0 so we can use the cordova crosswalk engine for the
ionic
platform.
I've been working with Ian and Andrew on this to gather more
understanding
and to get some help along the way. I must say, excellent work,
everyone.
As such, we've accumulated quite a bit of users who are actively
using
Cordova Android 4.0. Currently, we've had over 10k test trials
with
it,
and
I'm happy to say, mostly it's been smooth.
What I've done is made a fork to adjust a few small things, but
for
the
most part, we're using 4.0.
I'd love to provide any more feedback that you'd wish.
Thanks again for the awesome work.
On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com
wrote:
Hey
So, it's finally here. I want to see us work more on
Pluggable
Webviews, and adding the API, but I think it's time that we
released
what we've been working on for almost a year to our users. I
know
that the API isn't exactly the most awesome we can make it,
but it
works, and I'd rather have it out at 80% than it sitting for
a few
more
months in limbo.
Are there any major blocking tasks that would prevent a vote
thread
that anyone knows about, or should we start firing up a
release?
I
don't think we're going to make our January date, but the
first
week
of February isn't that terrible.
Thoughts?
Joe
--
Clear thoughts produce clear results.
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
watchPosition
method
success callback geolocation.spec.8 should be called with a
position
object
• Expected true to be false
it(geolocation.spec.8 should be called with a
Position
object, function (done) {
// this test asks for using geolocation and
interrupts
autotests running.
// That's why we have to pending that for Windows
Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
successWatch = navigator.geolocation.
watchPosition(
function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: (5 * 60 * 1000) // 5 minutes
maximum
age of cached position
});
});
-Original Message-
From: Josh Bavari [mailto:jbav...@gmail.com]
Sent: Wednesday, January 28, 2015 8:30 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team,
I work for Ionic and I've had some involvement with the Cordova
project
since last year. At Ionic, we've released a Crosswalk build using
Cordova
Android 4.0 so we can use the cordova crosswalk engine for the
ionic
platform.
I've been working with Ian and Andrew on this to gather more
understanding
and to get some help along the way. I must say, excellent work,
everyone.
As such, we've accumulated quite a bit of users who are actively
using
Cordova Android 4.0. Currently, we've had over 10k test trials
with
it,
and
I'm happy to say, mostly it's been smooth.
What I've done is made a fork to adjust a few small things, but
for
the
most part, we're using 4.0.
I'd love to provide any more feedback that you'd wish.
Thanks again for the awesome work.
On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com
wrote:
Hey
So, it's finally here. I want to see us work more on Pluggable
Webviews, and adding the API, but I think it's time that we
released
what we've been working on for almost a year to our users. I
know
that the API isn't exactly the most awesome we can make it,
but it
works, and I'd rather have it out at 80% than it sitting for a
few
more
months in limbo.
Are there any major blocking tasks that would prevent a vote
thread
that anyone knows about, or should we start firing up a
release?
I
don't think we're going to make our January date, but the first
week
of February isn't that terrible.
Thoughts?
Joe
--
Clear thoughts produce clear results.
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: (5 * 60 * 1000) // 5 minutes
maximum
age of cached position
});
});
-Original Message-
From: Josh Bavari [mailto:jbav...@gmail.com]
Sent: Wednesday, January 28, 2015 8:30 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team,
I work for Ionic and I've had some involvement with the Cordova
project
since last year. At Ionic, we've released a Crosswalk build using
Cordova
Android 4.0 so we can use the cordova crosswalk engine for the ionic
platform.
I've been working with Ian and Andrew on this to gather more
understanding
and to get some help along the way. I must say, excellent work,
everyone.
As such, we've accumulated quite a bit of users who are actively
using
Cordova Android 4.0. Currently, we've had over 10k test trials with
it,
and
I'm happy to say, mostly it's been smooth.
What I've done is made a fork to adjust a few small things, but for
the
most part, we're using 4.0.
I'd love to provide any more feedback that you'd wish.
Thanks again for the awesome work.
On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com
wrote:
Hey
So, it's finally here. I want to see us work more on Pluggable
Webviews, and adding the API, but I think it's time that we
released
what we've been working on for almost a year to our users. I know
that the API isn't exactly the most awesome we can make it, but it
works, and I'd rather have it out at 80% than it sitting for a few
more
months in limbo.
Are there any major blocking tasks that would prevent a vote
thread
that anyone knows about, or should we start firing up a release?
I
don't think we're going to make our January date, but the first
week
of February isn't that terrible.
Thoughts?
Joe
--
Clear thoughts produce clear results.
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
) {
// this test asks for using geolocation and
interrupts
autotests running.
// That's why we have to pending that for Windows
Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
successWatch = navigator.geolocation.
watchPosition(
function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: (5 * 60 * 1000) // 5 minutes
maximum
age of cached position
});
});
-Original Message-
From: Josh Bavari [mailto:jbav...@gmail.com]
Sent: Wednesday, January 28, 2015 8:30 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team,
I work for Ionic and I've had some involvement with the Cordova
project
since last year. At Ionic, we've released a Crosswalk build using
Cordova
Android 4.0 so we can use the cordova crosswalk engine for the
ionic
platform.
I've been working with Ian and Andrew on this to gather more
understanding
and to get some help along the way. I must say, excellent work,
everyone.
As such, we've accumulated quite a bit of users who are actively
using
Cordova Android 4.0. Currently, we've had over 10k test trials
with
it,
and
I'm happy to say, mostly it's been smooth.
What I've done is made a fork to adjust a few small things, but
for
the
most part, we're using 4.0.
I'd love to provide any more feedback that you'd wish.
Thanks again for the awesome work.
On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com
wrote:
Hey
So, it's finally here. I want to see us work more on Pluggable
Webviews, and adding the API, but I think it's time that we
released
what we've been working on for almost a year to our users. I
know
that the API isn't exactly the most awesome we can make it, but
it
works, and I'd rather have it out at 80% than it sitting for a
few
more
months in limbo.
Are there any major blocking tasks that would prevent a vote
thread
that anyone knows about, or should we start firing up a release?
I
don't think we're going to make our January date, but the first
week
of February isn't that terrible.
Thoughts?
Joe
--
Clear thoughts produce clear results.
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
RE: [DISCUSS] Cordova-Android 4.0.0 Release
';
var downloadFail = function (error) {
expect(error.http_status).toBe(401);
expect(error.http_status).not.toBe(404, Ensure +
fileURL + is in the white list);
done();
};
transfer.download(fileURL, localFilePath,
unexpectedCallbacks.httpWin, downloadFail);
});
org.apache.cordova.geolocation.tests.tests getCurrentPosition method success
callback geolocation.spec.6 should be called with a position object
• Expected true to be false
it(geolocation.spec.6 should be called with a Position object,
function (done) {
// this test asks for using geolocation and interrupts
autotests running.
// That's why we have to pending that for Windows Store 8.0/8.1
apps
if (isWindowsStore) {
pending();
}
navigator.geolocation.getCurrentPosition(function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: 30 // 5 minutes maximum age of cached
position
});
});
org.apache.cordova.geolocation.tests.tests watchPosition method success
callback geolocation.spec.8 should be called with a position object
• Expected true to be false
it(geolocation.spec.8 should be called with a Position object,
function (done) {
// this test asks for using geolocation and interrupts
autotests running.
// That's why we have to pending that for Windows Store 8.0/8.1
apps
if (isWindowsStore) {
pending();
}
successWatch = navigator.geolocation.watchPosition(
function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: (5 * 60 * 1000) // 5 minutes maximum age of
cached position
});
});
-Original Message-
From: Josh Bavari [mailto:jbav...@gmail.com]
Sent: Wednesday, January 28, 2015 8:30 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team,
I work for Ionic and I've had some involvement with the Cordova project since
last year. At Ionic, we've released a Crosswalk build using Cordova Android 4.0
so we can use the cordova crosswalk engine for the ionic platform.
I've been working with Ian and Andrew on this to gather more understanding and
to get some help along the way. I must say, excellent work, everyone.
As such, we've accumulated quite a bit of users who are actively using Cordova
Android 4.0. Currently, we've had over 10k test trials with it, and I'm happy
to say, mostly it's been smooth.
What I've done is made a fork to adjust a few small things, but for the most
part, we're using 4.0.
I'd love to provide any more feedback that you'd wish.
Thanks again for the awesome work.
On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com wrote:
Hey
So, it's finally here. I want to see us work more on Pluggable
Webviews, and adding the API, but I think it's time that we released
what we've been working on for almost a year to our users. I know
that the API isn't exactly the most awesome we can make it, but it
works, and I'd rather have it out at 80% than it sitting for a few more
months in limbo.
Are there any major blocking tasks that would prevent a vote thread
that anyone knows about, or should we start firing up a release? I
don't think we're going to make our January date, but the first week
of February isn't that terrible.
Thoughts?
Joe
--
Clear thoughts produce clear results.
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
: (5 * 60 * 1000) // 5 minutes maximum age of cached position }); }); -Original Message- From: Josh Bavari [mailto:jbav...@gmail.com] Sent: Wednesday, January 28, 2015 8:30 AM To: dev@cordova.apache.org Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release Joe and team, I work for Ionic and I've had some involvement with the Cordova project since last year. At Ionic, we've released a Crosswalk build using Cordova Android 4.0 so we can use the cordova crosswalk engine for the ionic platform. I've been working with Ian and Andrew on this to gather more understanding and to get some help along the way. I must say, excellent work, everyone. As such, we've accumulated quite a bit of users who are actively using Cordova Android 4.0. Currently, we've had over 10k test trials with it, and I'm happy to say, mostly it's been smooth. What I've done is made a fork to adjust a few small things, but for the most part, we're using 4.0. I'd love to provide any more feedback that you'd wish. Thanks again for the awesome work. On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com wrote: Hey So, it's finally here. I want to see us work more on Pluggable Webviews, and adding the API, but I think it's time that we released what we've been working on for almost a year to our users. I know that the API isn't exactly the most awesome we can make it, but it works, and I'd rather have it out at 80% than it sitting for a few more months in limbo. Are there any major blocking tasks that would prevent a vote thread that anyone knows about, or should we start firing up a release? I don't think we're going to make our January date, but the first week of February isn't that terrible. Thoughts? Joe -- Clear thoughts produce clear results. Josh Bavari Application Developer Phone: 405-509-9448 Cell: 405-812-0496 Email: jbav...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
();
}
successWatch = navigator.geolocation.watchPosition(
function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: (5 * 60 * 1000) // 5 minutes
maximum
age of cached position
});
});
-Original Message-
From: Josh Bavari [mailto:jbav...@gmail.com]
Sent: Wednesday, January 28, 2015 8:30 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team,
I work for Ionic and I've had some involvement with the Cordova
project
since last year. At Ionic, we've released a Crosswalk build using
Cordova
Android 4.0 so we can use the cordova crosswalk engine for the
ionic
platform.
I've been working with Ian and Andrew on this to gather more
understanding
and to get some help along the way. I must say, excellent work,
everyone.
As such, we've accumulated quite a bit of users who are actively
using
Cordova Android 4.0. Currently, we've had over 10k test trials with
it,
and
I'm happy to say, mostly it's been smooth.
What I've done is made a fork to adjust a few small things, but for
the
most part, we're using 4.0.
I'd love to provide any more feedback that you'd wish.
Thanks again for the awesome work.
On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com
wrote:
Hey
So, it's finally here. I want to see us work more on Pluggable
Webviews, and adding the API, but I think it's time that we
released
what we've been working on for almost a year to our users. I
know
that the API isn't exactly the most awesome we can make it, but
it
works, and I'd rather have it out at 80% than it sitting for a
few
more
months in limbo.
Are there any major blocking tasks that would prevent a vote
thread
that anyone knows about, or should we start firing up a
release? I
don't think we're going to make our January date, but the first
week
of February isn't that terrible.
Thoughts?
Joe
--
Clear thoughts produce clear results.
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team, I work for Ionic and I've had some involvement with the Cordova project since last year. At Ionic, we've released a Crosswalk build using Cordova Android 4.0 so we can use the cordova crosswalk engine for the ionic platform. I've been working with Ian and Andrew on this to gather more understanding and to get some help along the way. I must say, excellent work, everyone. As such, we've accumulated quite a bit of users who are actively using Cordova Android 4.0. Currently, we've had over 10k test trials with it, and I'm happy to say, mostly it's been smooth. What I've done is made a fork to adjust a few small things, but for the most part, we're using 4.0. I'd love to provide any more feedback that you'd wish. Thanks again for the awesome work. On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com wrote: Hey So, it's finally here. I want to see us work more on Pluggable Webviews, and adding the API, but I think it's time that we released what we've been working on for almost a year to our users. I know that the API isn't exactly the most awesome we can make it, but it works, and I'd rather have it out at 80% than it sitting for a few more months in limbo. Are there any major blocking tasks that would prevent a vote thread that anyone knows about, or should we start firing up a release? I don't think we're going to make our January date, but the first week of February isn't that terrible. Thoughts? Joe -- Clear thoughts produce clear results. Josh Bavari Application Developer Phone: 405-509-9448 Cell: 405-812-0496 Email: jbav...@gmail.com
Re: [DISCUSS] Cordova-Android 4.0.0 Release
)
• Expected `` to be null
describe('FileReader', function () {
it(file.spec.81 should have correct methods, function ()
{
var reader = new FileReader();
expect(reader).toBeDefined();
expect(typeof
reader.readAsBinaryString).toBe('function');
expect(typeof reader.readAsDataURL).toBe('function');
expect(typeof reader.readAsText).toBe('function');
expect(typeof reader.readAsArrayBuffer).
toBe('function');
expect(typeof reader.abort).toBe('function');
test below fails
'' !== null
expect(reader.result).toBe(null);
});
});
org.apache.cordova.file.tests.tests file api parent references
file.spec.111 (couldn’t find a fire issue):
• root.getFile succeeds, it is expected to fail.
var fileName = traverse.file.uri;
// create a new file entry
createFile(fileName, function (entry) {
// lookup file system entry
root.getFile('../' + fileName, {
create : false
}, succeed.bind(null, done,
root.getFile('../+fileName+ ')- Unexpected success callback, it
should
not traverse abvoe the root directory),
function (error) { //.
org.apache.cordova.file-transfer.tests.tests FileTransfer methods
download filetransfer.spec.6 should get 401 status on http basic auth
failure
• Expected null to be 401
it('filetransfer.spec.6 should get 401 status on http
basic auth failure', function (done) {
// NOTE:
// using server without credentials
var fileURL = SERVER + '/download_basic_auth';
var downloadFail = function (error) {
expect(error.http_status).toBe(401);
expect(error.http_status).not.toBe(404,
Ensure
+ fileURL + is in the white list);
done();
};
transfer.download(fileURL, localFilePath,
unexpectedCallbacks.httpWin, downloadFail);
});
org.apache.cordova.geolocation.tests.tests getCurrentPosition
method
success callback geolocation.spec.6 should be called with a position
object
• Expected true to be false
it(geolocation.spec.6 should be called with a Position
object, function (done) {
// this test asks for using geolocation and interrupts
autotests running.
// That's why we have to pending that for Windows Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
navigator.geolocation.getCurrentPosition(function (p)
{
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: 30 // 5 minutes maximum age of
cached
position
});
});
org.apache.cordova.geolocation.tests.tests watchPosition method
success callback geolocation.spec.8 should be called with a position
object
• Expected true to be false
it(geolocation.spec.8 should be called with a Position
object, function (done) {
// this test asks for using geolocation and interrupts
autotests running.
// That's why we have to pending that for Windows Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
successWatch = navigator.geolocation.watchPosition(
function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: (5 * 60 * 1000) // 5 minutes
maximum
age of cached position
});
});
-Original Message-
From: Josh Bavari [mailto:jbav...@gmail.com]
Sent: Wednesday, January 28, 2015 8:30 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team,
I work for Ionic and I've had some involvement with the Cordova project
since last year. At Ionic, we've released a Crosswalk build using
Cordova
Android 4.0 so we can use the cordova crosswalk engine for the ionic
platform
Re: [DISCUSS] Cordova-Android 4.0.0 Release
success callback, it should
not traverse abvoe the root directory),
function (error) { //.
org.apache.cordova.file-transfer.tests.tests FileTransfer methods
download filetransfer.spec.6 should get 401 status on http basic auth
failure
• Expected null to be 401
it('filetransfer.spec.6 should get 401 status on http
basic auth failure', function (done) {
// NOTE:
// using server without credentials
var fileURL = SERVER + '/download_basic_auth';
var downloadFail = function (error) {
expect(error.http_status).toBe(401);
expect(error.http_status).not.toBe(404, Ensure
+ fileURL + is in the white list);
done();
};
transfer.download(fileURL, localFilePath,
unexpectedCallbacks.httpWin, downloadFail);
});
org.apache.cordova.geolocation.tests.tests getCurrentPosition method
success callback geolocation.spec.6 should be called with a position object
• Expected true to be false
it(geolocation.spec.6 should be called with a Position
object, function (done) {
// this test asks for using geolocation and interrupts
autotests running.
// That's why we have to pending that for Windows Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
navigator.geolocation.getCurrentPosition(function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: 30 // 5 minutes maximum age of cached
position
});
});
org.apache.cordova.geolocation.tests.tests watchPosition method
success callback geolocation.spec.8 should be called with a position object
• Expected true to be false
it(geolocation.spec.8 should be called with a Position
object, function (done) {
// this test asks for using geolocation and interrupts
autotests running.
// That's why we have to pending that for Windows Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
successWatch = navigator.geolocation.watchPosition(
function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: (5 * 60 * 1000) // 5 minutes maximum
age of cached position
});
});
-Original Message-
From: Josh Bavari [mailto:jbav...@gmail.com]
Sent: Wednesday, January 28, 2015 8:30 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team,
I work for Ionic and I've had some involvement with the Cordova project
since last year. At Ionic, we've released a Crosswalk build using Cordova
Android 4.0 so we can use the cordova crosswalk engine for the ionic
platform.
I've been working with Ian and Andrew on this to gather more understanding
and to get some help along the way. I must say, excellent work, everyone.
As such, we've accumulated quite a bit of users who are actively using
Cordova Android 4.0. Currently, we've had over 10k test trials with it, and
I'm happy to say, mostly it's been smooth.
What I've done is made a fork to adjust a few small things, but for the
most part, we're using 4.0.
I'd love to provide any more feedback that you'd wish.
Thanks again for the awesome work.
On Wed, Jan 28, 2015 at 9:21 AM, Joe Bowser bows...@gmail.com wrote:
Hey
So, it's finally here. I want to see us work more on Pluggable
Webviews, and adding the API, but I think it's time that we released
what we've been working on for almost a year to our users. I know
that the API isn't exactly the most awesome we can make it, but it
works, and I'd rather have it out at 80% than it sitting for a few more
months in limbo.
Are there any major blocking tasks that would prevent a vote thread
that anyone knows about, or should we start firing up a release? I
don't think we're going to make our January date, but the first week
of February isn't that terrible.
Thoughts?
Joe
--
Clear thoughts produce clear results.
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e
Re: [DISCUSS] Cordova-Android 4.0.0 Release
() {
it(file.spec.81 should have correct methods, function () {
var reader = new FileReader();
expect(reader).toBeDefined();
expect(typeof
reader.readAsBinaryString).toBe('function');
expect(typeof reader.readAsDataURL).toBe('function');
expect(typeof reader.readAsText).toBe('function');
expect(typeof reader.readAsArrayBuffer).toBe('function');
expect(typeof reader.abort).toBe('function');
test below fails
'' !== null
expect(reader.result).toBe(null);
});
});
org.apache.cordova.file.tests.tests file api parent references
file.spec.111 (couldn’t find a fire issue):
• root.getFile succeeds, it is expected to fail.
var fileName = traverse.file.uri;
// create a new file entry
createFile(fileName, function (entry) {
// lookup file system entry
root.getFile('../' + fileName, {
create : false
}, succeed.bind(null, done,
root.getFile('../+fileName+ ')- Unexpected success callback, it should
not traverse abvoe the root directory),
function (error) { //.
org.apache.cordova.file-transfer.tests.tests FileTransfer methods
download filetransfer.spec.6 should get 401 status on http basic auth
failure
• Expected null to be 401
it('filetransfer.spec.6 should get 401 status on http
basic auth failure', function (done) {
// NOTE:
// using server without credentials
var fileURL = SERVER + '/download_basic_auth';
var downloadFail = function (error) {
expect(error.http_status).toBe(401);
expect(error.http_status).not.toBe(404, Ensure
+ fileURL + is in the white list);
done();
};
transfer.download(fileURL, localFilePath,
unexpectedCallbacks.httpWin, downloadFail);
});
org.apache.cordova.geolocation.tests.tests getCurrentPosition method
success callback geolocation.spec.6 should be called with a position
object
• Expected true to be false
it(geolocation.spec.6 should be called with a Position
object, function (done) {
// this test asks for using geolocation and interrupts
autotests running.
// That's why we have to pending that for Windows Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
navigator.geolocation.getCurrentPosition(function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: 30 // 5 minutes maximum age of cached
position
});
});
org.apache.cordova.geolocation.tests.tests watchPosition method
success callback geolocation.spec.8 should be called with a position
object
• Expected true to be false
it(geolocation.spec.8 should be called with a Position
object, function (done) {
// this test asks for using geolocation and interrupts
autotests running.
// That's why we have to pending that for Windows Store
8.0/8.1 apps
if (isWindowsStore) {
pending();
}
successWatch = navigator.geolocation.watchPosition(
function (p) {
expect(p.coords).toBeDefined();
expect(p.timestamp).toBeDefined();
done();
},
fail.bind(null, done),
{
maximumAge: (5 * 60 * 1000) // 5 minutes maximum
age of cached position
});
});
-Original Message-
From: Josh Bavari [mailto:jbav...@gmail.com]
Sent: Wednesday, January 28, 2015 8:30 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
Joe and team,
I work for Ionic and I've had some involvement with the Cordova project
since last year. At Ionic, we've released a Crosswalk build using Cordova
Android 4.0 so we can use the cordova crosswalk engine for the ionic
platform.
I've been working with Ian and Andrew on this to gather more
understanding
and to get some help along the way. I must say, excellent work, everyone.
As such, we've accumulated quite a bit of users who
RE: [DISCUSS] Cordova-Android 4.0.0 Release
Just give some data point, running mobile spec I'm getting:
- 11 failures in 4.4.2
- 6 failures in 4.0.4
Ideally we should bring those numbers to 0 to ensure a stable release.
-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com]
Sent: Wednesday, January 28, 2015 10:45 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
On Wed Jan 28 2015 at 10:38:07 AM Andrew Grieve agri...@chromium.org
wrote:
- 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)
This literally came out of nowhere. Why are you trying so hard to
remove
the embedded view use case? What if someone is implementing an activity that
inherits from another activity like MapActivity? This API change came without
any discussion.
All of this can be done in a few days, but I'd also like to see the dust
settle a bit before going forward with 4.0.0 release. E.g. At least
wait until we do a blog post for 3.7.0 (are you doing this?), and have
done a tools release that updates the pinned version to 3.7.0
If someone else wants to do the blog post on that, that's fine. And I agree
that there should be a tools release with 3.7.0 pinned, even though
3.7.0 is really just a technicality so we can get 4.0.0 out IMO.
On Wed, Jan 28, 2015 at 12:52 PM, Joe Bowser bows...@gmail.com wrote:
Reminder: failures with plugins are not blockers. I've run into
that contact issue numerous times when testing with my personal
device. I recommend making sure that your contacts are completely
clean so that you don't get these weird results.
The file failures have been happening for quite a while, and those
are
not
blockers for the platform release either. Do these failures happen
on a platform other than ICS?
On Wed, Jan 28, 2015, 9:06 AM Murat Sutunc mura...@microsoft.com
wrote:
I’ve ran the mobile-spec tests on android 4.0.3 with 4.0.x and
there
are
some failures. I’ve searched the jira for issues but wasn’t able
to
find
any. Has anyone else ran into these issues before?
org.apache.cordova.contacts.tests.tests Contacts
(navigator.contacts)
Round trip Contact tests (creating + save + delete + find).
Contacts.spec.24 Creating, saving, finding a contact should work,
after which we should not be able to find it, and we should not be
able to
delete
it again.
• Expected 2 to be 1
• Expected 1 to be 0
it(contacts.spec.24 Creating, saving, finding a contact
should
work, removing it should work, after which we should not be able
to
find
it, and we should not be able to delete it again., function (done) {
// Save method is not supported on Windows platform
if (isWindows) {
pending();
return;
}
if (isWindowsPhone8) {
done();
return;
}
gContactObj = new Contact();
gContactObj.name = new ContactName();
gContactObj.name.familyName = DeleteMe;
gContactObj.save(function(c_obj) {
var findWin = function(cs) {
expect(cs.length).toBe(1);
// update to have proper saved id
gContactObj = cs[0];
gContactObj.remove(function() {
var findWinAgain = function(seas) {
expect(seas.length).toBe(0);
gContactObj.remove(function() {
throw(success callback called
after non-existent Contact object called remove(). Test failed.);
}, function(e) {
expect(e.code).toBe(ContactErr
or.UNKNOWN_ERROR);
done();
});
};
var findFailAgain = function(e) {
throw(find error callback invoked
after delete, test failed.);
};
var obj = new ContactFindOptions();
obj.filter=DeleteMe;
obj.multiple=true;
navigator.contacts.find([displayName,
name,
phoneNumbers, emails], findWinAgain, findFailAgain, obj);
}, function(e) {
throw(Newly created contact's remove
function
invoked error callback. Test failed.);
});
};
var findFail = fail
Re: [DISCUSS] Cordova-Android 4.0.0 Release
I can't remember a single release that had zero failures in mobile-spec, so
I don't know why we are so intent on doing this now.
On Wed Jan 28 2015 at 10:50:54 AM Murat Sutunc mura...@microsoft.com
wrote:
Just give some data point, running mobile spec I'm getting:
- 11 failures in 4.4.2
- 6 failures in 4.0.4
Ideally we should bring those numbers to 0 to ensure a stable release.
-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com]
Sent: Wednesday, January 28, 2015 10:45 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
On Wed Jan 28 2015 at 10:38:07 AM Andrew Grieve agri...@chromium.org
wrote:
- 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)
This literally came out of nowhere. Why are you trying so hard to
remove
the embedded view use case? What if someone is implementing an activity
that inherits from another activity like MapActivity? This API change came
without any discussion.
All of this can be done in a few days, but I'd also like to see the dust
settle a bit before going forward with 4.0.0 release. E.g. At least
wait until we do a blog post for 3.7.0 (are you doing this?), and have
done a tools release that updates the pinned version to 3.7.0
If someone else wants to do the blog post on that, that's fine. And I
agree that there should be a tools release with 3.7.0 pinned, even though
3.7.0 is really just a technicality so we can get 4.0.0 out IMO.
On Wed, Jan 28, 2015 at 12:52 PM, Joe Bowser bows...@gmail.com wrote:
Reminder: failures with plugins are not blockers. I've run into
that contact issue numerous times when testing with my personal
device. I recommend making sure that your contacts are completely
clean so that you don't get these weird results.
The file failures have been happening for quite a while, and those
are
not
blockers for the platform release either. Do these failures happen
on a platform other than ICS?
On Wed, Jan 28, 2015, 9:06 AM Murat Sutunc mura...@microsoft.com
wrote:
I’ve ran the mobile-spec tests on android 4.0.3 with 4.0.x and
there
are
some failures. I’ve searched the jira for issues but wasn’t able
to
find
any. Has anyone else ran into these issues before?
org.apache.cordova.contacts.tests.tests Contacts
(navigator.contacts)
Round trip Contact tests (creating + save + delete + find).
Contacts.spec.24 Creating, saving, finding a contact should work,
after which we should not be able to find it, and we should not be
able to
delete
it again.
• Expected 2 to be 1
• Expected 1 to be 0
it(contacts.spec.24 Creating, saving, finding a contact
should
work, removing it should work, after which we should not be able
to
find
it, and we should not be able to delete it again., function (done) {
// Save method is not supported on Windows platform
if (isWindows) {
pending();
return;
}
if (isWindowsPhone8) {
done();
return;
}
gContactObj = new Contact();
gContactObj.name = new ContactName();
gContactObj.name.familyName = DeleteMe;
gContactObj.save(function(c_obj) {
var findWin = function(cs) {
expect(cs.length).toBe(1);
// update to have proper saved id
gContactObj = cs[0];
gContactObj.remove(function() {
var findWinAgain = function(seas) {
expect(seas.length).toBe(0);
gContactObj.remove(function() {
throw(success callback called
after non-existent Contact object called remove(). Test failed.);
}, function(e) {
expect(e.code).toBe(ContactErr
or.UNKNOWN_ERROR);
done();
});
};
var findFailAgain = function(e) {
throw(find error callback invoked
after delete, test failed.);
};
var obj = new ContactFindOptions();
obj.filter=DeleteMe;
obj.multiple=true;
navigator.contacts.find([displayName,
name,
phoneNumbers, emails
