Re: android: create: An error occured, Deleting project... on mac
./create icsdemo edu.metrostate.icsdemo icsdemo Thank you. From: Kerri Shotts To: dev@cordova.apache.org; "xinumik...@yahoo.com" Sent: Sunday, November 4, 2012 9:05 PM Subject: Re: android: create: An error occured, Deleting project... on mac What are you typing, exactly, to run the create script? _~Kerri Shotts, photoKandy Studios LLC Wanna be our neighbor? Our Facebook page & Twitter feed. On Nov 4, 2012, at 6:51 PM, "xinumik...@yahoo.com" wrote: Just downloaded it today. 2.2.0 I believe. >-Mike > > > >- Original Message - >From: Kerri Shotts >To: "dev@cordova.apache.org" >Cc: >Sent: Sunday, November 4, 2012 6:17 PM >Subject: Re: android: create: An error occured, Deleting project... on mac > >PhoneGap version? > >__ >Kerri Shotts >photoKandy Studios LLC > >📱 Phone: +1 (312) 380-1035 >🌐 Web: http://photokandy.com > >Twitter: @photokandy > > >On Nov 4, 2012, at 15:22, "xinumik...@yahoo.com" wrote: > > >Hello, >>I have seen a couple replies to this, but I still can't get it. >> >>I am trying to use create, on Macintosh, to do an Android project. >> >>My path includes: android-sdk-macosx and android-sdk-macosx/tools >> >>Anybody doing this on a mac? >> >>Thank you, >> Mike >> >
[jira] [Reopened] (CB-1794) `cordova` command line script(s) don't work with paths with spaces in them
[
https://issues.apache.org/jira/browse/CB-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anis Kadri reopened CB-1794:
> `cordova` command line script(s) don't work with paths with spaces in them
> --
>
> Key: CB-1794
> URL: https://issues.apache.org/jira/browse/CB-1794
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.1.0
> Environment: Mac OS X 10.7.5
>Reporter: Filip Maj
>Assignee: Anis Kadri
> Fix For: 2.3.0
>
>
> I run the following:
> {code}
> ./bin/create "foo bar"
> cd foo\ bar
> ./cordova/debug
> {code}
> I get:
> {code}
> bash: /Users/fil/src/incubator-cordova-android/foo: No such file or
> directory
> {code}
> I believe the patch is to change the line:
> {{cd PROJECT_PATH}}
> .. in the {{debug}} and {{cordova}} scripts to:
> {{cd "PROJECT_PATH"}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1809) `create` script should print out meaningful error messages
[
https://issues.apache.org/jira/browse/CB-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anis Kadri resolved CB-1809.
Resolution: Fixed
> `create` script should print out meaningful error messages
> --
>
> Key: CB-1809
> URL: https://issues.apache.org/jira/browse/CB-1809
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.1.0, 2.2.0
> Environment: Mac OS X 10.7.5
>Reporter: Filip Maj
>Assignee: Anis Kadri
>
> I've been seeing people have issues with the {{./bin/create}} script.
> Helping them out on IRC is tough as the generic error message always received
> is:
> "There has been an error. Deleting project..."
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1794) `cordova` command line script(s) don't work with paths with spaces in them
[
https://issues.apache.org/jira/browse/CB-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anis Kadri resolved CB-1794.
Resolution: Fixed
Hopefully this will help a bit more. Will output which command failed with
which status code on error.
> `cordova` command line script(s) don't work with paths with spaces in them
> --
>
> Key: CB-1794
> URL: https://issues.apache.org/jira/browse/CB-1794
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.1.0
> Environment: Mac OS X 10.7.5
>Reporter: Filip Maj
>Assignee: Anis Kadri
> Fix For: 2.3.0
>
>
> I run the following:
> {code}
> ./bin/create "foo bar"
> cd foo\ bar
> ./cordova/debug
> {code}
> I get:
> {code}
> bash: /Users/fil/src/incubator-cordova-android/foo: No such file or
> directory
> {code}
> I believe the patch is to change the line:
> {{cd PROJECT_PATH}}
> .. in the {{debug}} and {{cordova}} scripts to:
> {{cd "PROJECT_PATH"}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-1794) `cordova` command line script(s) don't work with paths with spaces in them
[
https://issues.apache.org/jira/browse/CB-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anis Kadri updated CB-1794:
---
Comment: was deleted
(was: Hopefully this will help a bit more. Will output which command failed
with which status code on error.)
> `cordova` command line script(s) don't work with paths with spaces in them
> --
>
> Key: CB-1794
> URL: https://issues.apache.org/jira/browse/CB-1794
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.1.0
> Environment: Mac OS X 10.7.5
>Reporter: Filip Maj
>Assignee: Anis Kadri
> Fix For: 2.3.0
>
>
> I run the following:
> {code}
> ./bin/create "foo bar"
> cd foo\ bar
> ./cordova/debug
> {code}
> I get:
> {code}
> bash: /Users/fil/src/incubator-cordova-android/foo: No such file or
> directory
> {code}
> I believe the patch is to change the line:
> {{cd PROJECT_PATH}}
> .. in the {{debug}} and {{cordova}} scripts to:
> {{cd "PROJECT_PATH"}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1809) `create` script should print out meaningful error messages
[
https://issues.apache.org/jira/browse/CB-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491119#comment-13491119
]
Anis Kadri commented on CB-1809:
Hopefully this will help a bit more. Will output which command failed with
which status code on error.
> `create` script should print out meaningful error messages
> --
>
> Key: CB-1809
> URL: https://issues.apache.org/jira/browse/CB-1809
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.1.0, 2.2.0
> Environment: Mac OS X 10.7.5
>Reporter: Filip Maj
>Assignee: Anis Kadri
>
> I've been seeing people have issues with the {{./bin/create}} script.
> Helping them out on IRC is tough as the generic error message always received
> is:
> "There has been an error. Deleting project..."
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1506) Implement InAppBrowser feature
[
https://issues.apache.org/jira/browse/CB-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1349#comment-1349
]
Jesse MacFadyen commented on CB-1506:
-
I have some open questions about the wiki defined 'spec'
1. window.open('http://random-url.com', '_self'); // loads in InAppBrowser
- so even though the random-url is not whitelisted, it is permitted to load
within the application, inside the InAppBrowser. This is currently not trivial
on iOS.
2. How can I open a whitelisted url in the native browser? ie. mobile safari
- there is no clear path to targeting ALL 3 possibilities or a)the app page, b)
the InAppBrowser, c) the system browser ( for a whitelisted URL )
- it makes sense that you cannot open a file:// url in the system browser + you
cannot open a non-whitelisted url in the app.
> Implement InAppBrowser feature
> --
>
> Key: CB-1506
> URL: https://issues.apache.org/jira/browse/CB-1506
> Project: Apache Cordova
> Issue Type: New Feature
> Components: Android, iOS
>Affects Versions: Master
>Reporter: Shazron Abdullah
> Fix For: 2.3.0
>
>
> See: http://wiki.apache.org/cordova/InAppBrowser
> Tentatively set for 2.3.0 to get the ball rolling, and only for iOS and
> Android. Not sure what other platforms this should apply to, if so, add a
> sub-task.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 2.3.0 major new features
It would be great to see both of those land in 2.3.0! On Mon, Nov 5, 2012 at 4:38 PM, Brian LeRoux wrote: > +yeaaa > > On Monday, November 5, 2012, Shazron wrote: > > > I'd like to implement InAppBrowser in 2.3.0? > > https://issues.apache.org/jira/browse/CB-1506 > > > > Also I'd like to migrate the Cordova.plist to config.xml for iOS: > > https://issues.apache.org/jira/browse/CB-1108 > > >
Re: 2.3.0 major new features
+yeaaa On Monday, November 5, 2012, Shazron wrote: > I'd like to implement InAppBrowser in 2.3.0? > https://issues.apache.org/jira/browse/CB-1506 > > Also I'd like to migrate the Cordova.plist to config.xml for iOS: > https://issues.apache.org/jira/browse/CB-1108 >
Re: Whitelist defaults
I confirm that Android also uses config.xml. On Mon, Nov 5, 2012 at 4:22 PM, Shazron wrote: > I would think all unsupported devices for the whitelist feature remain > unsupported (and is documented as such: > > http://docs.phonegap.com/en/2.2.0/guide_whitelist_index.md.html#Domain%20Whitelist%20Guide > ) > > > On Mon, Nov 5, 2012 at 4:14 PM, Jesse wrote: > > > Does this mean that whitelists should be added to Bada, Symbian, > > WebOS, Windows Phone, and Windows 8? > > > > Also, while we are discussing it, wouldn't it be good to have all > > platforms have a consistent way of defining access-permissions ? > > > > Android:: res/xml/cordova.xml > > Blackberry:: www/config.xml > > iOS:: Cordova.plist > > Tizen:: config.xml > > > > > > > > > > > > On Mon, Nov 5, 2012 at 3:58 PM, Shazron wrote: > > > What Anis said last is what I meant. Since BB and Android have this > > > behaviour already this doesn't impact those platforms as much. Will > wait > > > for comments until tomorrow then I will add some JIRA task(s). > > > > > > > > > On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI > wrote: > > > > > >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux wrote: > > >> > > >> > Why would we require a new property? We're just talking about adding > > * as > > >> > the default property. > > >> > > > >> > > >> I believe this applied only if we did a debug/release mode strategy. > > Adding > > >> (*) as default doesn't require a new property from what I understand. > > >> > > >> > > >> > > > >> > (Also, Jesse, I have talked to many Cordova devs whom have expressed > > >> > frustration with our default.) > > >> > > > >> > I feel we have consensus enough to document and add this default. > > >> > > > >> > > > >> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron wrote: > > >> > > > >> > > Well it's all or nothing. There is no "dev" mode with respect to > the > > >> > plist > > >> > > itself as it is right now, unless we want to add yet another plist > > >> > > property. > > >> > > > > >> > > > > >> > > On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI > > >> wrote: > > >> > > > > >> > > > I guess the consensus is to whitelist everything (*) all the > time. > > >> > > > > > >> > > > My opinion is that there should be some dev mode where (*) is > set > > and > > >> > > then > > >> > > > a release mode where you'd specify your hosts. > > >> > > > > > >> > > > > > >> > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron > > wrote: > > >> > > > > > >> > > > > We've had the discussion. So what is the decision/consensus? > > Leave > > >> as > > >> > > is, > > >> > > > > or add "*" to default settings for all, with a warning in the > > >> console > > >> > > > log? > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser < > bows...@gmail.com> > > >> > wrote: > > >> > > > > > > >> > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron > > > >> > wrote: > > >> > > > > > > Echoing Anis here. The easiest use case is for corporate > use > > >> > > > > (internal), > > >> > > > > > > where any connections are restricted to a certain domain > for > > >> > > paranoid > > >> > > > > IT > > >> > > > > > > types. > > >> > > > > > > > > >> > > > > > > I can see the case of us allowing everything _by default_ > > >> though > > >> > > (eg > > >> > > > > > adding > > >> > > > > > > the '*'), which really should have been the default so as > > to be > > >> > > > > > "backwards > > >> > > > > > > compatible" with how it was before the whitelist came in. > > The > > >> > > system > > >> > > > > > could > > >> > > > > > > detect this sole wildcard entry, and print out a warning > in > > the > > >> > > > console > > >> > > > > > > log, as well as the documentation of course pointing this > > out > > >> -- > > >> > > the > > >> > > > > > latter > > >> > > > > > > which we should have done in the first place. > > >> > > > > > > > >> > > > > > OK, that sounds cool, but does that mean that in six months, > > >> we're > > >> > > > > > going to deprecate this behaviour and get more aggressive > with > > >> the > > >> > > > > > whitelist? > > >> > > > > > > > >> > > > > > BTW: In the event that the whitelist isn't found based on > the > > >> code > > >> > > > > > that I'm looking at here, Android should block everything > and > > >> fire > > >> > > > > > default web intents. If it's not doing this, that's a bug! > > When > > >> we > > >> > > > > > refer to defaults, are we referring to the config.xml that > > we're > > >> > > > > > circulating? > > >> > > > > > > > >> > > > > > Also, how are we testing this whitelisting feature? I can > tell > > >> you > > >> > > > > > that doing it in JS alone wouldn't be enough. > > >> > > > > > > > >> > > > > > Joe > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > -- > > @purplecabbage > > risingj.com > > >
Re: Whitelist defaults
I would think all unsupported devices for the whitelist feature remain unsupported (and is documented as such: http://docs.phonegap.com/en/2.2.0/guide_whitelist_index.md.html#Domain%20Whitelist%20Guide ) On Mon, Nov 5, 2012 at 4:14 PM, Jesse wrote: > Does this mean that whitelists should be added to Bada, Symbian, > WebOS, Windows Phone, and Windows 8? > > Also, while we are discussing it, wouldn't it be good to have all > platforms have a consistent way of defining access-permissions ? > > Android:: res/xml/cordova.xml > Blackberry:: www/config.xml > iOS:: Cordova.plist > Tizen:: config.xml > > > > > > On Mon, Nov 5, 2012 at 3:58 PM, Shazron wrote: > > What Anis said last is what I meant. Since BB and Android have this > > behaviour already this doesn't impact those platforms as much. Will wait > > for comments until tomorrow then I will add some JIRA task(s). > > > > > > On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI wrote: > > > >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux wrote: > >> > >> > Why would we require a new property? We're just talking about adding > * as > >> > the default property. > >> > > >> > >> I believe this applied only if we did a debug/release mode strategy. > Adding > >> (*) as default doesn't require a new property from what I understand. > >> > >> > >> > > >> > (Also, Jesse, I have talked to many Cordova devs whom have expressed > >> > frustration with our default.) > >> > > >> > I feel we have consensus enough to document and add this default. > >> > > >> > > >> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron wrote: > >> > > >> > > Well it's all or nothing. There is no "dev" mode with respect to the > >> > plist > >> > > itself as it is right now, unless we want to add yet another plist > >> > > property. > >> > > > >> > > > >> > > On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI > >> wrote: > >> > > > >> > > > I guess the consensus is to whitelist everything (*) all the time. > >> > > > > >> > > > My opinion is that there should be some dev mode where (*) is set > and > >> > > then > >> > > > a release mode where you'd specify your hosts. > >> > > > > >> > > > > >> > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron > wrote: > >> > > > > >> > > > > We've had the discussion. So what is the decision/consensus? > Leave > >> as > >> > > is, > >> > > > > or add "*" to default settings for all, with a warning in the > >> console > >> > > > log? > >> > > > > > >> > > > > > >> > > > > > >> > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser > >> > wrote: > >> > > > > > >> > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron > >> > wrote: > >> > > > > > > Echoing Anis here. The easiest use case is for corporate use > >> > > > > (internal), > >> > > > > > > where any connections are restricted to a certain domain for > >> > > paranoid > >> > > > > IT > >> > > > > > > types. > >> > > > > > > > >> > > > > > > I can see the case of us allowing everything _by default_ > >> though > >> > > (eg > >> > > > > > adding > >> > > > > > > the '*'), which really should have been the default so as > to be > >> > > > > > "backwards > >> > > > > > > compatible" with how it was before the whitelist came in. > The > >> > > system > >> > > > > > could > >> > > > > > > detect this sole wildcard entry, and print out a warning in > the > >> > > > console > >> > > > > > > log, as well as the documentation of course pointing this > out > >> -- > >> > > the > >> > > > > > latter > >> > > > > > > which we should have done in the first place. > >> > > > > > > >> > > > > > OK, that sounds cool, but does that mean that in six months, > >> we're > >> > > > > > going to deprecate this behaviour and get more aggressive with > >> the > >> > > > > > whitelist? > >> > > > > > > >> > > > > > BTW: In the event that the whitelist isn't found based on the > >> code > >> > > > > > that I'm looking at here, Android should block everything and > >> fire > >> > > > > > default web intents. If it's not doing this, that's a bug! > When > >> we > >> > > > > > refer to defaults, are we referring to the config.xml that > we're > >> > > > > > circulating? > >> > > > > > > >> > > > > > Also, how are we testing this whitelisting feature? I can tell > >> you > >> > > > > > that doing it in JS alone wouldn't be enough. > >> > > > > > > >> > > > > > Joe > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > > > -- > @purplecabbage > risingj.com >
[jira] [Commented] (CB-1108) Migrate config.xml to the W3C spec
[ https://issues.apache.org/jira/browse/CB-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491080#comment-13491080 ] Shazron Abdullah commented on CB-1108: -- Not sure for iOS if we support config.xml we have to "deprecate" use of Cordova.plist (which means supporting both for a while) or it's a clean break. > Migrate config.xml to the W3C spec > -- > > Key: CB-1108 > URL: https://issues.apache.org/jira/browse/CB-1108 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Bada, BlackBerry, iOS, webOS, WP7 >Affects Versions: 2.0.0 >Reporter: Joe Bowser >Assignee: Joe Bowser > Fix For: 2.3.0 > > > In 2.0.0, we decided that config.xml should exist in some form. > Unfortunately, that form has nothing to do with the W3C version. We should > try to move towards the W3C version wherever possible. Android was the only > one to actually have a config.xml added, mostly because creating this file > was trivial. > If this is not technically possible, the xml file should be changed back to > cordova.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Whitelist defaults
I mentioned this in another thread -- I'd like to migrate Cordova.plist to config.xml so we can be consistent there. I believe Android has already moved to config.xml already. On Mon, Nov 5, 2012 at 4:14 PM, Jesse wrote: > Does this mean that whitelists should be added to Bada, Symbian, > WebOS, Windows Phone, and Windows 8? > > Also, while we are discussing it, wouldn't it be good to have all > platforms have a consistent way of defining access-permissions ? > > Android:: res/xml/cordova.xml > Blackberry:: www/config.xml > iOS:: Cordova.plist > Tizen:: config.xml > > > > > > On Mon, Nov 5, 2012 at 3:58 PM, Shazron wrote: > > What Anis said last is what I meant. Since BB and Android have this > > behaviour already this doesn't impact those platforms as much. Will wait > > for comments until tomorrow then I will add some JIRA task(s). > > > > > > On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI wrote: > > > >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux wrote: > >> > >> > Why would we require a new property? We're just talking about adding > * as > >> > the default property. > >> > > >> > >> I believe this applied only if we did a debug/release mode strategy. > Adding > >> (*) as default doesn't require a new property from what I understand. > >> > >> > >> > > >> > (Also, Jesse, I have talked to many Cordova devs whom have expressed > >> > frustration with our default.) > >> > > >> > I feel we have consensus enough to document and add this default. > >> > > >> > > >> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron wrote: > >> > > >> > > Well it's all or nothing. There is no "dev" mode with respect to the > >> > plist > >> > > itself as it is right now, unless we want to add yet another plist > >> > > property. > >> > > > >> > > > >> > > On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI > >> wrote: > >> > > > >> > > > I guess the consensus is to whitelist everything (*) all the time. > >> > > > > >> > > > My opinion is that there should be some dev mode where (*) is set > and > >> > > then > >> > > > a release mode where you'd specify your hosts. > >> > > > > >> > > > > >> > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron > wrote: > >> > > > > >> > > > > We've had the discussion. So what is the decision/consensus? > Leave > >> as > >> > > is, > >> > > > > or add "*" to default settings for all, with a warning in the > >> console > >> > > > log? > >> > > > > > >> > > > > > >> > > > > > >> > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser > >> > wrote: > >> > > > > > >> > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron > >> > wrote: > >> > > > > > > Echoing Anis here. The easiest use case is for corporate use > >> > > > > (internal), > >> > > > > > > where any connections are restricted to a certain domain for > >> > > paranoid > >> > > > > IT > >> > > > > > > types. > >> > > > > > > > >> > > > > > > I can see the case of us allowing everything _by default_ > >> though > >> > > (eg > >> > > > > > adding > >> > > > > > > the '*'), which really should have been the default so as > to be > >> > > > > > "backwards > >> > > > > > > compatible" with how it was before the whitelist came in. > The > >> > > system > >> > > > > > could > >> > > > > > > detect this sole wildcard entry, and print out a warning in > the > >> > > > console > >> > > > > > > log, as well as the documentation of course pointing this > out > >> -- > >> > > the > >> > > > > > latter > >> > > > > > > which we should have done in the first place. > >> > > > > > > >> > > > > > OK, that sounds cool, but does that mean that in six months, > >> we're > >> > > > > > going to deprecate this behaviour and get more aggressive with > >> the > >> > > > > > whitelist? > >> > > > > > > >> > > > > > BTW: In the event that the whitelist isn't found based on the > >> code > >> > > > > > that I'm looking at here, Android should block everything and > >> fire > >> > > > > > default web intents. If it's not doing this, that's a bug! > When > >> we > >> > > > > > refer to defaults, are we referring to the config.xml that > we're > >> > > > > > circulating? > >> > > > > > > >> > > > > > Also, how are we testing this whitelisting feature? I can tell > >> you > >> > > > > > that doing it in JS alone wouldn't be enough. > >> > > > > > > >> > > > > > Joe > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > > > -- > @purplecabbage > risingj.com >
2.3.0 major new features
I'd like to implement InAppBrowser in 2.3.0? https://issues.apache.org/jira/browse/CB-1506 Also I'd like to migrate the Cordova.plist to config.xml for iOS: https://issues.apache.org/jira/browse/CB-1108
Re: Whitelist defaults
Does this mean that whitelists should be added to Bada, Symbian, WebOS, Windows Phone, and Windows 8? Also, while we are discussing it, wouldn't it be good to have all platforms have a consistent way of defining access-permissions ? Android:: res/xml/cordova.xml Blackberry:: www/config.xml iOS:: Cordova.plist Tizen:: config.xml On Mon, Nov 5, 2012 at 3:58 PM, Shazron wrote: > What Anis said last is what I meant. Since BB and Android have this > behaviour already this doesn't impact those platforms as much. Will wait > for comments until tomorrow then I will add some JIRA task(s). > > > On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI wrote: > >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux wrote: >> >> > Why would we require a new property? We're just talking about adding * as >> > the default property. >> > >> >> I believe this applied only if we did a debug/release mode strategy. Adding >> (*) as default doesn't require a new property from what I understand. >> >> >> > >> > (Also, Jesse, I have talked to many Cordova devs whom have expressed >> > frustration with our default.) >> > >> > I feel we have consensus enough to document and add this default. >> > >> > >> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron wrote: >> > >> > > Well it's all or nothing. There is no "dev" mode with respect to the >> > plist >> > > itself as it is right now, unless we want to add yet another plist >> > > property. >> > > >> > > >> > > On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI >> wrote: >> > > >> > > > I guess the consensus is to whitelist everything (*) all the time. >> > > > >> > > > My opinion is that there should be some dev mode where (*) is set and >> > > then >> > > > a release mode where you'd specify your hosts. >> > > > >> > > > >> > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron wrote: >> > > > >> > > > > We've had the discussion. So what is the decision/consensus? Leave >> as >> > > is, >> > > > > or add "*" to default settings for all, with a warning in the >> console >> > > > log? >> > > > > >> > > > > >> > > > > >> > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser >> > wrote: >> > > > > >> > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron >> > wrote: >> > > > > > > Echoing Anis here. The easiest use case is for corporate use >> > > > > (internal), >> > > > > > > where any connections are restricted to a certain domain for >> > > paranoid >> > > > > IT >> > > > > > > types. >> > > > > > > >> > > > > > > I can see the case of us allowing everything _by default_ >> though >> > > (eg >> > > > > > adding >> > > > > > > the '*'), which really should have been the default so as to be >> > > > > > "backwards >> > > > > > > compatible" with how it was before the whitelist came in. The >> > > system >> > > > > > could >> > > > > > > detect this sole wildcard entry, and print out a warning in the >> > > > console >> > > > > > > log, as well as the documentation of course pointing this out >> -- >> > > the >> > > > > > latter >> > > > > > > which we should have done in the first place. >> > > > > > >> > > > > > OK, that sounds cool, but does that mean that in six months, >> we're >> > > > > > going to deprecate this behaviour and get more aggressive with >> the >> > > > > > whitelist? >> > > > > > >> > > > > > BTW: In the event that the whitelist isn't found based on the >> code >> > > > > > that I'm looking at here, Android should block everything and >> fire >> > > > > > default web intents. If it's not doing this, that's a bug! When >> we >> > > > > > refer to defaults, are we referring to the config.xml that we're >> > > > > > circulating? >> > > > > > >> > > > > > Also, how are we testing this whitelisting feature? I can tell >> you >> > > > > > that doing it in JS alone wouldn't be enough. >> > > > > > >> > > > > > Joe >> > > > > > >> > > > > >> > > > >> > > >> > >> -- @purplecabbage risingj.com
Re: Whitelist defaults
What Anis said last is what I meant. Since BB and Android have this behaviour already this doesn't impact those platforms as much. Will wait for comments until tomorrow then I will add some JIRA task(s). On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI wrote: > On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux wrote: > > > Why would we require a new property? We're just talking about adding * as > > the default property. > > > > I believe this applied only if we did a debug/release mode strategy. Adding > (*) as default doesn't require a new property from what I understand. > > > > > > (Also, Jesse, I have talked to many Cordova devs whom have expressed > > frustration with our default.) > > > > I feel we have consensus enough to document and add this default. > > > > > > On Mon, Nov 5, 2012 at 3:26 PM, Shazron wrote: > > > > > Well it's all or nothing. There is no "dev" mode with respect to the > > plist > > > itself as it is right now, unless we want to add yet another plist > > > property. > > > > > > > > > On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI > wrote: > > > > > > > I guess the consensus is to whitelist everything (*) all the time. > > > > > > > > My opinion is that there should be some dev mode where (*) is set and > > > then > > > > a release mode where you'd specify your hosts. > > > > > > > > > > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron wrote: > > > > > > > > > We've had the discussion. So what is the decision/consensus? Leave > as > > > is, > > > > > or add "*" to default settings for all, with a warning in the > console > > > > log? > > > > > > > > > > > > > > > > > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser > > wrote: > > > > > > > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron > > wrote: > > > > > > > Echoing Anis here. The easiest use case is for corporate use > > > > > (internal), > > > > > > > where any connections are restricted to a certain domain for > > > paranoid > > > > > IT > > > > > > > types. > > > > > > > > > > > > > > I can see the case of us allowing everything _by default_ > though > > > (eg > > > > > > adding > > > > > > > the '*'), which really should have been the default so as to be > > > > > > "backwards > > > > > > > compatible" with how it was before the whitelist came in. The > > > system > > > > > > could > > > > > > > detect this sole wildcard entry, and print out a warning in the > > > > console > > > > > > > log, as well as the documentation of course pointing this out > -- > > > the > > > > > > latter > > > > > > > which we should have done in the first place. > > > > > > > > > > > > OK, that sounds cool, but does that mean that in six months, > we're > > > > > > going to deprecate this behaviour and get more aggressive with > the > > > > > > whitelist? > > > > > > > > > > > > BTW: In the event that the whitelist isn't found based on the > code > > > > > > that I'm looking at here, Android should block everything and > fire > > > > > > default web intents. If it's not doing this, that's a bug! When > we > > > > > > refer to defaults, are we referring to the config.xml that we're > > > > > > circulating? > > > > > > > > > > > > Also, how are we testing this whitelisting feature? I can tell > you > > > > > > that doing it in JS alone wouldn't be enough. > > > > > > > > > > > > Joe > > > > > > > > > > > > > > > > > > > > >
Re: Whitelist defaults
On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux wrote: > Why would we require a new property? We're just talking about adding * as > the default property. > I believe this applied only if we did a debug/release mode strategy. Adding (*) as default doesn't require a new property from what I understand. > > (Also, Jesse, I have talked to many Cordova devs whom have expressed > frustration with our default.) > > I feel we have consensus enough to document and add this default. > > > On Mon, Nov 5, 2012 at 3:26 PM, Shazron wrote: > > > Well it's all or nothing. There is no "dev" mode with respect to the > plist > > itself as it is right now, unless we want to add yet another plist > > property. > > > > > > On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI wrote: > > > > > I guess the consensus is to whitelist everything (*) all the time. > > > > > > My opinion is that there should be some dev mode where (*) is set and > > then > > > a release mode where you'd specify your hosts. > > > > > > > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron wrote: > > > > > > > We've had the discussion. So what is the decision/consensus? Leave as > > is, > > > > or add "*" to default settings for all, with a warning in the console > > > log? > > > > > > > > > > > > > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser > wrote: > > > > > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron > wrote: > > > > > > Echoing Anis here. The easiest use case is for corporate use > > > > (internal), > > > > > > where any connections are restricted to a certain domain for > > paranoid > > > > IT > > > > > > types. > > > > > > > > > > > > I can see the case of us allowing everything _by default_ though > > (eg > > > > > adding > > > > > > the '*'), which really should have been the default so as to be > > > > > "backwards > > > > > > compatible" with how it was before the whitelist came in. The > > system > > > > > could > > > > > > detect this sole wildcard entry, and print out a warning in the > > > console > > > > > > log, as well as the documentation of course pointing this out -- > > the > > > > > latter > > > > > > which we should have done in the first place. > > > > > > > > > > OK, that sounds cool, but does that mean that in six months, we're > > > > > going to deprecate this behaviour and get more aggressive with the > > > > > whitelist? > > > > > > > > > > BTW: In the event that the whitelist isn't found based on the code > > > > > that I'm looking at here, Android should block everything and fire > > > > > default web intents. If it's not doing this, that's a bug! When we > > > > > refer to defaults, are we referring to the config.xml that we're > > > > > circulating? > > > > > > > > > > Also, how are we testing this whitelisting feature? I can tell you > > > > > that doing it in JS alone wouldn't be enough. > > > > > > > > > > Joe > > > > > > > > > > > > > > >
Re: Whitelist defaults
Why would we require a new property? We're just talking about adding * as the default property. (Also, Jesse, I have talked to many Cordova devs whom have expressed frustration with our default.) I feel we have consensus enough to document and add this default. On Mon, Nov 5, 2012 at 3:26 PM, Shazron wrote: > Well it's all or nothing. There is no "dev" mode with respect to the plist > itself as it is right now, unless we want to add yet another plist > property. > > > On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI wrote: > > > I guess the consensus is to whitelist everything (*) all the time. > > > > My opinion is that there should be some dev mode where (*) is set and > then > > a release mode where you'd specify your hosts. > > > > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron wrote: > > > > > We've had the discussion. So what is the decision/consensus? Leave as > is, > > > or add "*" to default settings for all, with a warning in the console > > log? > > > > > > > > > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser wrote: > > > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron wrote: > > > > > Echoing Anis here. The easiest use case is for corporate use > > > (internal), > > > > > where any connections are restricted to a certain domain for > paranoid > > > IT > > > > > types. > > > > > > > > > > I can see the case of us allowing everything _by default_ though > (eg > > > > adding > > > > > the '*'), which really should have been the default so as to be > > > > "backwards > > > > > compatible" with how it was before the whitelist came in. The > system > > > > could > > > > > detect this sole wildcard entry, and print out a warning in the > > console > > > > > log, as well as the documentation of course pointing this out -- > the > > > > latter > > > > > which we should have done in the first place. > > > > > > > > OK, that sounds cool, but does that mean that in six months, we're > > > > going to deprecate this behaviour and get more aggressive with the > > > > whitelist? > > > > > > > > BTW: In the event that the whitelist isn't found based on the code > > > > that I'm looking at here, Android should block everything and fire > > > > default web intents. If it's not doing this, that's a bug! When we > > > > refer to defaults, are we referring to the config.xml that we're > > > > circulating? > > > > > > > > Also, how are we testing this whitelisting feature? I can tell you > > > > that doing it in JS alone wouldn't be enough. > > > > > > > > Joe > > > > > > > > > >
Re: Whitelist defaults
In our customizations of our Cordova app, that's exactly what we did. We created a Cordova-Debug.plist and Cordova-Release.plist, and synced them back to Cordova.plist as a Build Phase step. I don't know that it's the default behavior the Cordova community would want for template apps, but it is doable anyway. On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI wrote: > I guess the consensus is to whitelist everything (*) all the time. > > My opinion is that there should be some dev mode where (*) is set and then > a release mode where you'd specify your hosts. > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron wrote: > > > We've had the discussion. So what is the decision/consensus? Leave as is, > > or add "*" to default settings for all, with a warning in the console > log? > > > > > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser wrote: > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron wrote: > > > > Echoing Anis here. The easiest use case is for corporate use > > (internal), > > > > where any connections are restricted to a certain domain for paranoid > > IT > > > > types. > > > > > > > > I can see the case of us allowing everything _by default_ though (eg > > > adding > > > > the '*'), which really should have been the default so as to be > > > "backwards > > > > compatible" with how it was before the whitelist came in. The system > > > could > > > > detect this sole wildcard entry, and print out a warning in the > console > > > > log, as well as the documentation of course pointing this out -- the > > > latter > > > > which we should have done in the first place. > > > > > > OK, that sounds cool, but does that mean that in six months, we're > > > going to deprecate this behaviour and get more aggressive with the > > > whitelist? > > > > > > BTW: In the event that the whitelist isn't found based on the code > > > that I'm looking at here, Android should block everything and fire > > > default web intents. If it's not doing this, that's a bug! When we > > > refer to defaults, are we referring to the config.xml that we're > > > circulating? > > > > > > Also, how are we testing this whitelisting feature? I can tell you > > > that doing it in JS alone wouldn't be enough. > > > > > > Joe > > > > > >
Re: Whitelist defaults
I guess make it "all" then. That's what I conclude from our discussion. As long as the feature is there, people can make the adequate decisions. I believe we should add this to the getting started guide (the whitelist docs are not enough to draw attention). On Mon, Nov 5, 2012 at 3:26 PM, Shazron wrote: > Well it's all or nothing. There is no "dev" mode with respect to the plist > itself as it is right now, unless we want to add yet another plist > property. > > > On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI wrote: > > > I guess the consensus is to whitelist everything (*) all the time. > > > > My opinion is that there should be some dev mode where (*) is set and > then > > a release mode where you'd specify your hosts. > > > > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron wrote: > > > > > We've had the discussion. So what is the decision/consensus? Leave as > is, > > > or add "*" to default settings for all, with a warning in the console > > log? > > > > > > > > > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser wrote: > > > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron wrote: > > > > > Echoing Anis here. The easiest use case is for corporate use > > > (internal), > > > > > where any connections are restricted to a certain domain for > paranoid > > > IT > > > > > types. > > > > > > > > > > I can see the case of us allowing everything _by default_ though > (eg > > > > adding > > > > > the '*'), which really should have been the default so as to be > > > > "backwards > > > > > compatible" with how it was before the whitelist came in. The > system > > > > could > > > > > detect this sole wildcard entry, and print out a warning in the > > console > > > > > log, as well as the documentation of course pointing this out -- > the > > > > latter > > > > > which we should have done in the first place. > > > > > > > > OK, that sounds cool, but does that mean that in six months, we're > > > > going to deprecate this behaviour and get more aggressive with the > > > > whitelist? > > > > > > > > BTW: In the event that the whitelist isn't found based on the code > > > > that I'm looking at here, Android should block everything and fire > > > > default web intents. If it's not doing this, that's a bug! When we > > > > refer to defaults, are we referring to the config.xml that we're > > > > circulating? > > > > > > > > Also, how are we testing this whitelisting feature? I can tell you > > > > that doing it in JS alone wouldn't be enough. > > > > > > > > Joe > > > > > > > > > >
Re: Whitelist defaults
Well it's all or nothing. There is no "dev" mode with respect to the plist itself as it is right now, unless we want to add yet another plist property. On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI wrote: > I guess the consensus is to whitelist everything (*) all the time. > > My opinion is that there should be some dev mode where (*) is set and then > a release mode where you'd specify your hosts. > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron wrote: > > > We've had the discussion. So what is the decision/consensus? Leave as is, > > or add "*" to default settings for all, with a warning in the console > log? > > > > > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser wrote: > > > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron wrote: > > > > Echoing Anis here. The easiest use case is for corporate use > > (internal), > > > > where any connections are restricted to a certain domain for paranoid > > IT > > > > types. > > > > > > > > I can see the case of us allowing everything _by default_ though (eg > > > adding > > > > the '*'), which really should have been the default so as to be > > > "backwards > > > > compatible" with how it was before the whitelist came in. The system > > > could > > > > detect this sole wildcard entry, and print out a warning in the > console > > > > log, as well as the documentation of course pointing this out -- the > > > latter > > > > which we should have done in the first place. > > > > > > OK, that sounds cool, but does that mean that in six months, we're > > > going to deprecate this behaviour and get more aggressive with the > > > whitelist? > > > > > > BTW: In the event that the whitelist isn't found based on the code > > > that I'm looking at here, Android should block everything and fire > > > default web intents. If it's not doing this, that's a bug! When we > > > refer to defaults, are we referring to the config.xml that we're > > > circulating? > > > > > > Also, how are we testing this whitelisting feature? I can tell you > > > that doing it in JS alone wouldn't be enough. > > > > > > Joe > > > > > >
Re: Whitelist defaults
I have relaxed my position, as I can work around whatever the choice is. It might be prudent to ask our users though. On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI wrote: > I guess the consensus is to whitelist everything (*) all the time. > > My opinion is that there should be some dev mode where (*) is set and then > a release mode where you'd specify your hosts. > > > On Mon, Nov 5, 2012 at 3:11 PM, Shazron wrote: > >> We've had the discussion. So what is the decision/consensus? Leave as is, >> or add "*" to default settings for all, with a warning in the console log? >> >> >> >> On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser wrote: >> >> > On Fri, Nov 2, 2012 at 10:59 AM, Shazron wrote: >> > > Echoing Anis here. The easiest use case is for corporate use >> (internal), >> > > where any connections are restricted to a certain domain for paranoid >> IT >> > > types. >> > > >> > > I can see the case of us allowing everything _by default_ though (eg >> > adding >> > > the '*'), which really should have been the default so as to be >> > "backwards >> > > compatible" with how it was before the whitelist came in. The system >> > could >> > > detect this sole wildcard entry, and print out a warning in the console >> > > log, as well as the documentation of course pointing this out -- the >> > latter >> > > which we should have done in the first place. >> > >> > OK, that sounds cool, but does that mean that in six months, we're >> > going to deprecate this behaviour and get more aggressive with the >> > whitelist? >> > >> > BTW: In the event that the whitelist isn't found based on the code >> > that I'm looking at here, Android should block everything and fire >> > default web intents. If it's not doing this, that's a bug! When we >> > refer to defaults, are we referring to the config.xml that we're >> > circulating? >> > >> > Also, how are we testing this whitelisting feature? I can tell you >> > that doing it in JS alone wouldn't be enough. >> > >> > Joe >> > >> -- @purplecabbage risingj.com
Re: Whitelist defaults
I guess the consensus is to whitelist everything (*) all the time. My opinion is that there should be some dev mode where (*) is set and then a release mode where you'd specify your hosts. On Mon, Nov 5, 2012 at 3:11 PM, Shazron wrote: > We've had the discussion. So what is the decision/consensus? Leave as is, > or add "*" to default settings for all, with a warning in the console log? > > > > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser wrote: > > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron wrote: > > > Echoing Anis here. The easiest use case is for corporate use > (internal), > > > where any connections are restricted to a certain domain for paranoid > IT > > > types. > > > > > > I can see the case of us allowing everything _by default_ though (eg > > adding > > > the '*'), which really should have been the default so as to be > > "backwards > > > compatible" with how it was before the whitelist came in. The system > > could > > > detect this sole wildcard entry, and print out a warning in the console > > > log, as well as the documentation of course pointing this out -- the > > latter > > > which we should have done in the first place. > > > > OK, that sounds cool, but does that mean that in six months, we're > > going to deprecate this behaviour and get more aggressive with the > > whitelist? > > > > BTW: In the event that the whitelist isn't found based on the code > > that I'm looking at here, Android should block everything and fire > > default web intents. If it's not doing this, that's a bug! When we > > refer to defaults, are we referring to the config.xml that we're > > circulating? > > > > Also, how are we testing this whitelisting feature? I can tell you > > that doing it in JS alone wouldn't be enough. > > > > Joe > > >
Re: Whitelist defaults
We've had the discussion. So what is the decision/consensus? Leave as is, or add "*" to default settings for all, with a warning in the console log? On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser wrote: > On Fri, Nov 2, 2012 at 10:59 AM, Shazron wrote: > > Echoing Anis here. The easiest use case is for corporate use (internal), > > where any connections are restricted to a certain domain for paranoid IT > > types. > > > > I can see the case of us allowing everything _by default_ though (eg > adding > > the '*'), which really should have been the default so as to be > "backwards > > compatible" with how it was before the whitelist came in. The system > could > > detect this sole wildcard entry, and print out a warning in the console > > log, as well as the documentation of course pointing this out -- the > latter > > which we should have done in the first place. > > OK, that sounds cool, but does that mean that in six months, we're > going to deprecate this behaviour and get more aggressive with the > whitelist? > > BTW: In the event that the whitelist isn't found based on the code > that I'm looking at here, Android should block everything and fire > default web intents. If it's not doing this, that's a bug! When we > refer to defaults, are we referring to the config.xml that we're > circulating? > > Also, how are we testing this whitelisting feature? I can tell you > that doing it in JS alone wouldn't be enough. > > Joe >
RE: 2.2.0rc2 Monday?
I was able to merge in pull request 40 properly with the preserved commit history, but had troubles cherry picking the changes for pull request 37 - so I just updated that file manually and committed the change. > From: markus.leutwy...@hp.com > To: dev@cordova.apache.org > Subject: RE: 2.2.0rc2 Monday? > Date: Thu, 1 Nov 2012 14:14:37 + > > Hi Herm, > > Since i included a locally built version of cordova.webos.js with the webOS > Phonegap distribution tagged with 2.2.0, the cordova-js repo is now out of > sync with that, as two of my pull-requests are still open there ... > https://github.com/apache/incubator-cordova-js/pull/40 and 37 > > Markus > > -Original Message- > From: Herm Wong [mailto:kingoftheo...@hotmail.com] > Sent: Mittwoch, 31. Oktober 2012 21:34 > To: dev@cordova.apache.org > Subject: RE: 2.2.0rc2 Monday? > > Markus, your fork of the repo was a bit out of date. I was able to cherry > pick your commits but lost your commit history when doing the merge. > I verified and tested that your changes are in the apache repo. > > > From: shaz...@gmail.com > > Date: Wed, 31 Oct 2012 01:40:33 -0700 > > Subject: Re: 2.2.0rc2 Monday? > > To: dev@cordova.apache.org > > > > Instructions: > > https://git-wip-us.apache.org/ > > > > Projects: > > https://git-wip-us.apache.org/repos/asf > > > > On Wed, Oct 31, 2012 at 1:35 AM, Shazron wrote: > > > Something's wrong with the Apache repo sync to Github. The canonical > > > repo is at > > > https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-webos.gi > > > t;a=summary > > > > > > On Wed, Oct 31, 2012 at 1:27 AM, Leutwyler, Markus > > > wrote: > > >> Thanks ... shouldn't I see the merged changes in > > >> https://github.com/apache/incubator-cordova-webos? > > >> > > >> Markus > > >> > > >> -Original Message- > > >> From: Herm Wong [mailto:kingoftheo...@hotmail.com] > > >> Sent: Dienstag, 30. Oktober 2012 23:13 > > >> To: dev@cordova.apache.org > > >> Subject: RE: 2.2.0rc2 Monday? > > >> > > >> The changes have been merged. > > >> > > >>> From: markus.leutwy...@hp.com > > >>> To: dev@cordova.apache.org > > >>> Subject: RE: 2.2.0rc2 Monday? > > >>> Date: Tue, 30 Oct 2012 11:59:55 + > > >>> > > >>> Here is the pull request > > >>> > > >>> https://github.com/apache/incubator-cordova-webos/pull/3 > > >>> > > >>> Markus > > >>> > > >>> -Original Message- > > >>> From: Herm Wong [mailto:kingoftheo...@hotmail.com] > > >>> Sent: Montag, 29. Oktober 2012 18:50 > > >>> To: dev@cordova.apache.org > > >>> Subject: RE: 2.2.0rc2 Monday? > > >>> > > >>> Go for it. > > >>> > > >>> > From: markus.leutwy...@hp.com > > >>> > To: dev@cordova.apache.org > > >>> > Subject: RE: 2.2.0rc2 Monday? > > >>> > Date: Mon, 29 Oct 2012 08:37:49 + > > >>> > > > >>> > Any reason the webOS Part of 2.2.0rc2 doesn't include the updated > > >>> > cordova-js for webOS? Should I go ahead an include cordova-js, update > > >>> > the Makefile etc.? > > >>> > > > >>> > Markus > > >>> > > > >>> > -Original Message- > > >>> > From: Herm Wong [mailto:kingoftheo...@hotmail.com] > > >>> > Sent: Samstag, 27. Oktober 2012 00:49 > > >>> > To: dev@cordova.apache.org > > >>> > Subject: RE: 2.2.0rc2 Monday? > > >>> > > > >>> > updated the issue tracker. > > >>> > everything was merged and tested a couple of days ago. > > >>> > > > >>> > > From: f...@adobe.com > > >>> > > To: dev@cordova.apache.org > > >>> > > Date: Fri, 26 Oct 2012 13:42:20 -0700 > > >>> > > Subject: Re: 2.2.0rc2 Monday? > > >>> > > > > >>> > > How is webos tagged but the Javascript not updated? Im > > >>> > > assuming the issue was not resolved? comeon people! > > >>> > > > > >>> > > On 10/26/12 1:40 PM, "Steven Gill" wrote: > > >>> > > > > >>> > > >WP7 & docs haven't been tagged yet. > > >>> > > > > > >>> > > >-Steve > > >>> > > > > > >>> > > >On Fri, Oct 26, 2012 at 1:38 PM, Filip Maj wrote: > > >>> > > > > > >>> > > >> All the tasks are done. Steve did you make the release? > > >>> > > >> Let's make some noise about it. > > >>> > > >> > > >>> > > >> On 10/26/12 1:14 PM, "Andrew Grieve" > > >>> > > >> wrote: > > >>> > > >> > > >>> > > >> >Okay, Simon, Bryce and I worked through the (final?) issue > > >>> > > >> >they were seeing with CB-1745. > > >>> > > >> > > > >>> > > >> >I've re-tagged the JS and Android again. Let's get this > > >>> > > >> >release > > >>> > > >>rolling! > > >>> > > >> > > > >>> > > >> > > > >>> > > >> >On Fri, Oct 26, 2012 at 1:37 PM, Gord Tanner > > >>> > > >> > > > >>> > > >>wrote: > > >>> > > >> > > > >>> > > >> >> thanks :) > > >>> > > >> >> > > >>> > > >> >> Teach a man to fish! > > >>> > > >> >> > > >>> > > >> >> retagged blackberry > > >>> > > >> >> > > >>> > > >> >> On Fri, Oct 26, 2012 at 1:14 PM, Andrew Grieve > > >>> > > >> >> > > >>> > > >> >> wrote: > > >>> > > >> >> > > >>> > > >> >> > FYI - the problem I was facing was not knowing the git > > >>> > > >> >> > foo for > > >>> > > >>pushing > > >>> > > >> >> > tags. To re-tag: >
[jira] [Assigned] (CB-1794) `cordova` command line script(s) don't work with paths with spaces in them
[
https://issues.apache.org/jira/browse/CB-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser reassigned CB-1794:
--
Assignee: Anis Kadri (was: Joe Bowser)
Can you explain what is going on here? This script just appears to call itself.
> `cordova` command line script(s) don't work with paths with spaces in them
> --
>
> Key: CB-1794
> URL: https://issues.apache.org/jira/browse/CB-1794
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.1.0
> Environment: Mac OS X 10.7.5
>Reporter: Filip Maj
>Assignee: Anis Kadri
> Fix For: 2.3.0
>
>
> I run the following:
> {code}
> ./bin/create "foo bar"
> cd foo\ bar
> ./cordova/debug
> {code}
> I get:
> {code}
> bash: /Users/fil/src/incubator-cordova-android/foo: No such file or
> directory
> {code}
> I believe the patch is to change the line:
> {{cd PROJECT_PATH}}
> .. in the {{debug}} and {{cordova}} scripts to:
> {{cd "PROJECT_PATH"}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CB-1796) camera.getPicture: the photo file is corrupted.
[ https://issues.apache.org/jira/browse/CB-1796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser reassigned CB-1796: -- Assignee: Simon MacDonald (was: Joe Bowser) I can't reproduce on my Galaxy Nexus. AFAIK we no longer write to the gallery with camera.getPicture. > camera.getPicture: the photo file is corrupted. > --- > > Key: CB-1796 > URL: https://issues.apache.org/jira/browse/CB-1796 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.0.0 > Environment: Tested on Nexus 7 and Samsung Galaxy >Reporter: Julien Bier >Assignee: Simon MacDonald > > The picture saved in the Camera folder is corrupted: the file size is equal > to 0kb. > The file can not be read from Windows. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490988#comment-13490988 ] Joe Bowser commented on CB-1811: Yes and no. There are a few primary builds of the browser based on what device tree they're based on. All Samsung devices should have the same build, and since I tested it on Samsung, I would be tempted to say that I can't reproduce it. Nexus devices are based on AOSP. HTC and other Qualcomm based-devices are based on the CodeAurora Android tree. Motorola and other OMAP based devices are based on the OMAP Android tree. Samsung Exynos based devices are based on their own special Android tree. Intel Atom based Android devices have their own tree. In addition, certain other manufacturers will also have other special trees, such as the LG Optimus 3D, which has its own webkit that slows down input and output from the WebKit bridge. This drives me up the wall, since I can't just tell people to root their devices and run CyanogenMod (yet another Android tree, based off AOSP). > Previously hidden select dropdowns crashing the webview when focused upon > - > > Key: CB-1811 > URL: https://issues.apache.org/jira/browse/CB-1811 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.1.0, 2.2.0 > Environment: Samsung Galaxy S3 (Android 4.0.4) >Reporter: Adam >Assignee: Joe Bowser >Priority: Minor > Labels: bug, crash > > I have a div panel that is hidden when a page is first shown. Inside the div > are a few html dropdowns (select tags). When I make the div visible (via > javascript) and focus into one of the dropdowns, I get the following logcat > error: > 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x > (code=1) > Then, the app just crashes and the webview disappears. I confirmed that this > happens when the parent div is initially invisible (display:none). If the div > is visible at first, all works fine, even if the div is hidden subsequently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490974#comment-13490974 ] Adam edited comment on CB-1811 at 11/5/12 10:06 PM: - Thanks, Joe. Just out of curiosity, does every Android device/vendor/model have a different implementation of the native browser? was (Author: drogon): Thanks, Joe. Just out of curiosity, does every Android device/vendor have a different implementation of the native browser? > Previously hidden select dropdowns crashing the webview when focused upon > - > > Key: CB-1811 > URL: https://issues.apache.org/jira/browse/CB-1811 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.1.0, 2.2.0 > Environment: Samsung Galaxy S3 (Android 4.0.4) >Reporter: Adam >Assignee: Joe Bowser >Priority: Minor > Labels: bug, crash > > I have a div panel that is hidden when a page is first shown. Inside the div > are a few html dropdowns (select tags). When I make the div visible (via > javascript) and focus into one of the dropdowns, I get the following logcat > error: > 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x > (code=1) > Then, the app just crashes and the webview disappears. I confirmed that this > happens when the parent div is initially invisible (display:none). If the div > is visible at first, all works fine, even if the div is hidden subsequently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490974#comment-13490974 ] Adam commented on CB-1811: --- Thanks, Joe. Just out of curiosity, does every device/vendor have a different implementation of the native browser? > Previously hidden select dropdowns crashing the webview when focused upon > - > > Key: CB-1811 > URL: https://issues.apache.org/jira/browse/CB-1811 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.1.0, 2.2.0 > Environment: Samsung Galaxy S3 (Android 4.0.4) >Reporter: Adam >Assignee: Joe Bowser >Priority: Minor > Labels: bug, crash > > I have a div panel that is hidden when a page is first shown. Inside the div > are a few html dropdowns (select tags). When I make the div visible (via > javascript) and focus into one of the dropdowns, I get the following logcat > error: > 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x > (code=1) > Then, the app just crashes and the webview disappears. I confirmed that this > happens when the parent div is initially invisible (display:none). If the div > is visible at first, all works fine, even if the div is hidden subsequently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490974#comment-13490974 ] Adam edited comment on CB-1811 at 11/5/12 10:06 PM: - Thanks, Joe. Just out of curiosity, does every Android device/vendor have a different implementation of the native browser? was (Author: drogon): Thanks, Joe. Just out of curiosity, does every device/vendor have a different implementation of the native browser? > Previously hidden select dropdowns crashing the webview when focused upon > - > > Key: CB-1811 > URL: https://issues.apache.org/jira/browse/CB-1811 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.1.0, 2.2.0 > Environment: Samsung Galaxy S3 (Android 4.0.4) >Reporter: Adam >Assignee: Joe Bowser >Priority: Minor > Labels: bug, crash > > I have a div panel that is hidden when a page is first shown. Inside the div > are a few html dropdowns (select tags). When I make the div visible (via > javascript) and focus into one of the dropdowns, I get the following logcat > error: > 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x > (code=1) > Then, the app just crashes and the webview disappears. I confirmed that this > happens when the parent div is initially invisible (display:none). If the div > is visible at first, all works fine, even if the div is hidden subsequently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-1805) Whitelist guide points to incorrect file for Android instructions
[
https://issues.apache.org/jira/browse/CB-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser updated CB-1805:
---
Fix Version/s: 2.3.0
> Whitelist guide points to incorrect file for Android instructions
> -
>
> Key: CB-1805
> URL: https://issues.apache.org/jira/browse/CB-1805
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Docs
>Affects Versions: 2.1.0
>Reporter: Filip Maj
>Assignee: Joe Bowser
> Fix For: 2.3.0
>
>
> The line:
> The whitelisting rules are found in res/xml/cordova.xml
> should point to {{res/xml/config.xml}} instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1805) Whitelist guide points to incorrect file for Android instructions
[
https://issues.apache.org/jira/browse/CB-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490957#comment-13490957
]
Joe Bowser commented on CB-1805:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-docs.git;a=commit;h=8ba0943c1a990bcfccd4e1833104eed8c545a688
> Whitelist guide points to incorrect file for Android instructions
> -
>
> Key: CB-1805
> URL: https://issues.apache.org/jira/browse/CB-1805
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Docs
>Affects Versions: 2.1.0
>Reporter: Filip Maj
>Assignee: Joe Bowser
> Fix For: 2.3.0
>
>
> The line:
> The whitelisting rules are found in res/xml/cordova.xml
> should point to {{res/xml/config.xml}} instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1805) Whitelist guide points to incorrect file for Android instructions
[
https://issues.apache.org/jira/browse/CB-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser resolved CB-1805.
Resolution: Fixed
Docs have been updated, see the commit.
> Whitelist guide points to incorrect file for Android instructions
> -
>
> Key: CB-1805
> URL: https://issues.apache.org/jira/browse/CB-1805
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Docs
>Affects Versions: 2.1.0
>Reporter: Filip Maj
>Assignee: Joe Bowser
> Fix For: 2.3.0
>
>
> The line:
> The whitelisting rules are found in res/xml/cordova.xml
> should point to {{res/xml/config.xml}} instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490950#comment-13490950 ] Joe Bowser edited comment on CB-1811 at 11/5/12 9:36 PM: - Lowering priority due to it being only one single model of phone. was (Author: bowserj): Lowering priority. > Previously hidden select dropdowns crashing the webview when focused upon > - > > Key: CB-1811 > URL: https://issues.apache.org/jira/browse/CB-1811 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.1.0, 2.2.0 > Environment: Samsung Galaxy S3 (Android 4.0.4) >Reporter: Adam >Assignee: Joe Bowser >Priority: Minor > Labels: bug, crash > > I have a div panel that is hidden when a page is first shown. Inside the div > are a few html dropdowns (select tags). When I make the div visible (via > javascript) and focus into one of the dropdowns, I get the following logcat > error: > 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x > (code=1) > Then, the app just crashes and the webview disappears. I confirmed that this > happens when the parent div is initially invisible (display:none). If the div > is visible at first, all works fine, even if the div is hidden subsequently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser updated CB-1811: --- Priority: Minor (was: Major) Lowering priority. > Previously hidden select dropdowns crashing the webview when focused upon > - > > Key: CB-1811 > URL: https://issues.apache.org/jira/browse/CB-1811 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.1.0, 2.2.0 > Environment: Samsung Galaxy S3 (Android 4.0.4) >Reporter: Adam >Assignee: Joe Bowser >Priority: Minor > Labels: bug, crash > > I have a div panel that is hidden when a page is first shown. Inside the div > are a few html dropdowns (select tags). When I make the div visible (via > javascript) and focus into one of the dropdowns, I get the following logcat > error: > 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x > (code=1) > Then, the app just crashes and the webview disappears. I confirmed that this > happens when the parent div is initially invisible (display:none). If the div > is visible at first, all works fine, even if the div is hidden subsequently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CB-1809) `create` script should print out meaningful error messages
[
https://issues.apache.org/jira/browse/CB-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser reassigned CB-1809:
--
Assignee: Anis Kadri (was: Joe Bowser)
> `create` script should print out meaningful error messages
> --
>
> Key: CB-1809
> URL: https://issues.apache.org/jira/browse/CB-1809
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.1.0, 2.2.0
> Environment: Mac OS X 10.7.5
>Reporter: Filip Maj
>Assignee: Anis Kadri
>
> I've been seeing people have issues with the {{./bin/create}} script.
> Helping them out on IRC is tough as the generic error message always received
> is:
> "There has been an error. Deleting project..."
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
plan for handling updated device OS versions?
I'm seeing rumors on the web that iOS 6.1 is in the works from Apple and there is a beta that recently opened. Is there any sort of target for handling new device OS versions in Cordova? For example: - Cordova should support a new device OS in the next Cordova version 4-6 weeks after the OS becomes generally available or - through the participation of betas with the device vendor, and careful release scheduling, Cordova should support a new device OS on day 1 that a new OS becomes generally available or - (something else entirely, since these are just examples) The goal here would be to: - provide some general direction to consumers and set realistic expectations. - provide specific direction to the Cordova development community, and give us a target to shoot for. - be consistent in our approach across all the OS vendors (assuming that is desired). Has there been previous discussion on this topic? If not, what are your ideas on this? -- Marcel Kinard
Re: [Android] CordovaWebView is broken
On Mon, Nov 5, 2012 at 9:22 AM, Joe Bowser wrote: > Hey > > I know that this kind of seems like a step back, but perhaps we should > start with the refactor of DroidGap into CordovaActivity. The main > obstacle that we have right now with the CordovaWebView is the fact that we > have to implement everything in CordovaInterface. While we can't get rid > of this, we could create a helper activity that implements this by moving > the current methods from DroidGap into that. Then we can make DroidGap > simply an activity that creates the view and optional. > > Due to the nature of Java, anyone combining other custom activites (i.e. > MapActivity) will still have to implement the CordovaInterface, but this > should further lower the barrier for many people who want to mix > CordovaWebView with Android UI controls, namely the menu bar (in fact, this > is the only UI control that I think anyone would want to add). > > Thoughts? > +1 > > > > On Mon, Nov 5, 2012 at 9:10 AM, Andrew Grieve > wrote: > > > Aah, I didn't realize that CordovaInterface was meant to be implemented > > other than by DroidGap. Sorry about that. Weird that projects would even > > compile without having the new method though. > > > > Once the tests are fixed up, we should definitely add running them to the > > list of release steps. > > > > > > On Fri, Nov 2, 2012 at 4:27 PM, Joe Bowser wrote: > > > > > Nevermindit's kinda bad but it's not minor release bad. > > > > > > Basically, adding the thread pool method requirement to the > > > CordovaInterface is what broke this. For some reason when you don't > > have a > > > thread pool, Cordova silently fails instead of dumping core all over > the > > > place. Is it possible that we can get plugins to get the thread pool > > from > > > elsewhere, or does it have to be in the Activity? > > > > > > > > > > > > > > > On Fri, Nov 2, 2012 at 1:08 PM, Joe Bowser wrote: > > > > > > > Hey > > > > > > > > I just started fixing up our broken JUnit Tests, and I discovered > that > > > the > > > > recent refactors broke the CordovaWebView standalone component. This > > > means > > > > that anyone who is using the CordovaWebView as a standalone component > > > > should probably not upgrade to 2.2.0 and that we'll have to issue a > > 2.2.1 > > > > release to address this issue. > > > > > > > > It seems that for some reason deviceready is no longer firing. I > think > > > > this may have to do with the recent changes to plugins as well as the > > > > addition of a thread pool. I'm going to commit the fixes to the > tests > > > > today, but you can recreate the issue by pulling down this debug > repo, > > > > putting it in Eclipse and making it use Cordova as a library. > > > > > > > > https://github.com/infil00p/CordovaActionView/tree/debug_version > > > > > > > > Also, you can debug this using the default activity on the test > > project, > > > > although the test project still needs a lot of cleaning to be done. > > > > > > > > It sucks that we missed this, but we really need to make sure we > don't > > > > break the tests when we do a refactor. > > > > > > > > I'll add more details to the bug soon. This harsh sucks, because I > > don't > > > > think this will be an easy fix. :( > > > > > > > > Joe > > > > > > > > > >
[jira] [Created] (CB-1812) Example use of deviceready in docs is incorrect
Filip Maj created CB-1812:
-
Summary: Example use of deviceready in docs is incorrect
Key: CB-1812
URL: https://issues.apache.org/jira/browse/CB-1812
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 2.2.0
Reporter: Filip Maj
Assignee: Michael Brooks
This came from someone who submitted a pull req via GitHub to the PhoneGap
project: https://github.com/phonegap/phonegap/pull/17
Essentially the full example first waits for {{body onload}} before attaching
to deviceready. We can eliminate that and directly attach to {{deviceready}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: iOS: Why does the cordova.js filename change?
> I'm thinking we only update: > > CordovaLib/cordova.ios.js with the latest from cordova-js > > > > I think we could do this without the explicit step. > > Ok. > > Then for a release, run a script/Makefile target to update: > > 1. CordovaLibAppTests/www/cordova.ios.js > > > For this, we can add a copy step to the build phases to copy the file in > from CordovaLib on each build > > Not feeling too hot for this, we used to have build phases in the project file. Caused some problems with upgrades and stuff, and was too "hidden" for people to know what is going on. But this was for a regular project not CordovaLibAppTests, so I guess its okay for this case. > > 2. bin/templates/project/www with the versioned .js > > > For this, we can have the create script just grab the .js file from > CordovaLib instead of from the templates directory. That can work.
[jira] [Commented] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490876#comment-13490876 ] Joe Bowser commented on CB-1811: Tested it on the Samsung Galaxy S2 with 4.0.4 and HTC One X with 4.0.3. This is confined to the Samsung Galaxy S3. > Previously hidden select dropdowns crashing the webview when focused upon > - > > Key: CB-1811 > URL: https://issues.apache.org/jira/browse/CB-1811 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.1.0, 2.2.0 > Environment: Samsung Galaxy S3 (Android 4.0.4) >Reporter: Adam >Assignee: Joe Bowser > Labels: bug, crash > > I have a div panel that is hidden when a page is first shown. Inside the div > are a few html dropdowns (select tags). When I make the div visible (via > javascript) and focus into one of the dropdowns, I get the following logcat > error: > 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x > (code=1) > Then, the app just crashes and the webview disappears. I confirmed that this > happens when the parent div is initially invisible (display:none). If the div > is visible at first, all works fine, even if the div is hidden subsequently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490872#comment-13490872 ] Joe Bowser commented on CB-1811: Works on my Nexus 7 Stock, which means that this is looking more Samsung based. I'm going to grab the HTC One X and the Samsung Galaxy S2 to test next. > Previously hidden select dropdowns crashing the webview when focused upon > - > > Key: CB-1811 > URL: https://issues.apache.org/jira/browse/CB-1811 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.1.0, 2.2.0 > Environment: Samsung Galaxy S3 (Android 4.0.4) >Reporter: Adam >Assignee: Joe Bowser > Labels: bug, crash > > I have a div panel that is hidden when a page is first shown. Inside the div > are a few html dropdowns (select tags). When I make the div visible (via > javascript) and focus into one of the dropdowns, I get the following logcat > error: > 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x > (code=1) > Then, the app just crashes and the webview disappears. I confirmed that this > happens when the parent div is initially invisible (display:none). If the div > is visible at first, all works fine, even if the div is hidden subsequently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1811) Previously hidden select dropdowns crashing the webview when focused upon
[ https://issues.apache.org/jira/browse/CB-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490867#comment-13490867 ] Joe Bowser commented on CB-1811: This is what happens when I test it on my Galaxy Nexus running CM 10-M2: 11-05 11:50:01.482: E/webcoreglue(27789): Should not happen: no rect-based-test nodes found The select does work though, which makes me want to blame Samsung. More testing will be required. > Previously hidden select dropdowns crashing the webview when focused upon > - > > Key: CB-1811 > URL: https://issues.apache.org/jira/browse/CB-1811 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.1.0, 2.2.0 > Environment: Samsung Galaxy S3 (Android 4.0.4) >Reporter: Adam >Assignee: Joe Bowser > Labels: bug, crash > > I have a div panel that is hidden when a page is first shown. Inside the div > are a few html dropdowns (select tags). When I make the div visible (via > javascript) and focus into one of the dropdowns, I get the following logcat > error: > 11-04 03:58:49.136: A/libc(18437): Fatal signal 11 (SIGSEGV) at 0x > (code=1) > Then, the app just crashes and the webview disappears. I confirmed that this > happens when the parent div is initially invisible (display:none). If the div > is visible at first, all works fine, even if the div is hidden subsequently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1801) Inflation Error preventing CordovaTest to run
[ https://issues.apache.org/jira/browse/CB-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser resolved CB-1801. Resolution: Fixed CordovaTest now runs and succeeds! > Inflation Error preventing CordovaTest to run > - > > Key: CB-1801 > URL: https://issues.apache.org/jira/browse/CB-1801 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.2.0 >Reporter: Joe Bowser >Assignee: Joe Bowser > Fix For: 2.3.0 > > > The CordovaTest, which tests the CordovaWebView component is failing because > of an inflate error when running the unit test. This halts all the unit > tests from executing. This should be fixed, because while this doesn't > manifest itself in Cordova yet, it could break apps using CordovaWebView as a > component. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1810) CordovaWebView does not work as a component without providing it a ThreadPool
[ https://issues.apache.org/jira/browse/CB-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490846#comment-13490846 ] Joe Bowser commented on CB-1810: [~handyface]: http://stackoverflow.com/questions/13194537/android-phonegap-2-1-2-2-upgrade-error/13238948#13238948 > CordovaWebView does not work as a component without providing it a ThreadPool > - > > Key: CB-1810 > URL: https://issues.apache.org/jira/browse/CB-1810 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.2.0 >Reporter: Joe Bowser >Assignee: Joe Bowser >Priority: Blocker > Fix For: 2.3.0 > > > Apparently CordovaWebView no longer works as a stand-alone component. We may > have to release a 2.2.1 because of this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Windows desktop 8: duplicate out-of-date cordova.windows8.js?
I'm looking at the 2.2.0 snapshot on git-wip-us.apache.org in incubator-cordova-windows.git/windows8. There is a cordova-2.0.0.js file at the top of the tree (incubator-cordova-windows.git/windows) and a mostly similar file at framework/Template-Cordova/js/cordova.windows8.js. The former has a commented timestamp of Wed Oct 31 2012 17:52:48 GMT-0700 and commit hash of 0bdb8350ff1ca401c0a806721511f2a65383b4d3, and the latter has a commented timestamp of Tue Oct 16 2012 20:44:50 GMT-0700 and commit hash of 40ef5295c0427d9de77f43e0b1904d4761f75330. When I look at the history for incubator-cordova-js.git, I see a commit hash ending in 5330 on Oct 16. Is the latter file an old duplicate of the newer former? Should the latter file be updated or deleted? -- Marcel Kinard
[jira] [Resolved] (CB-1749) Switch BlackBerry 10 Battery to use navigator.webkitBattery
[ https://issues.apache.org/jira/browse/CB-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gord resolved CB-1749. -- Resolution: Fixed fixed with: https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commit;h=3ae88d12133e4de8ec15fec6c6cc83d2ab8719d8 > Switch BlackBerry 10 Battery to use navigator.webkitBattery > --- > > Key: CB-1749 > URL: https://issues.apache.org/jira/browse/CB-1749 > Project: Apache Cordova > Issue Type: Bug > Components: BlackBerry, CordovaJS >Reporter: Gord >Assignee: Gord > Fix For: 2.3.0 > > > The current way we handle battery events in cordova.js for BlackBerry 10 is > going to be obsoleted in favour of navigator.webkitBattery support already in > the browser. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Android] Can everyone run the tests?
Sorry, wrong thread. Obviously. The command line version of the unit tests is on the Wiki. On Mon, Nov 5, 2012 at 9:43 AM, Joe Bowser wrote: > I did send an e-mail about the cleaning of the tests with the wiki > article. Did everyone get it? > > > On Mon, Nov 5, 2012 at 9:21 AM, Andrew Grieve wrote: > >> Yes, thanks Joe for pushing on this. Testing will only make things better! >> >> Do you think it'd be feasible to create a script that would launch the >> tests? Eclipse is great when they fail, but to ensure they pass, command >> line is often nicer. The instructions on the wiki seem like they may be >> out >> of date? They reference phonegap, and they don't say what cordova target >> to >> build. >> >> >> On Fri, Nov 2, 2012 at 9:25 PM, Joe Bowser wrote: >> >> > If we still have JAR issues, that should be a blocker for the release. >> > Having these tests should be required now, since we have too many Java >> > bits that we can't break. I removed the old Selenium JAR a while ago. >> > >> > I would love it if we could get Selenium to work with CordovaWebView so >> > that we could click on HTML elements, but we should be able to automate >> the >> > Back Button and Menu Button bindings, as well as random key bindings. >> That >> > being said, we should be able to execute Javascript to do what we need >> > instead of testing touch and click events, which in theory should have >> been >> > tested as part of Android's CTS. (No idea if this ever happens). >> > >> > >> > On Fri, Nov 2, 2012 at 5:58 PM, Simon MacDonald >> > wrote: >> > >> > > That's great Joe. I was under the impression that the Android repo >> tests >> > > were still dependent on a jar we didn't have access to. I'll make sure >> > > running the tests is part of my regular process and "gasp" I will even >> > > write a few. >> > > >> > > Simon Mac Donald >> > > http://hi.im/simonmacdonald >> > > >> > > >> > > On Fri, Nov 2, 2012 at 4:38 PM, Joe Bowser wrote: >> > > >> > > > Hey >> > > > >> > > > After the last scare with CordovaWebView, I want to know if everyone >> > who >> > > > commits on Android can run the tests that are currently committed >> with >> > > > Android? You have to be able to do both things with the tests in >> > Eclipse: >> > > > >> > > > 1. Run the test as an Android Application >> > > > 2. Run the Android JUnit Tests >> > > > >> > > > There is a command-line method to do this, but honestly if you're >> > finding >> > > > failures here, you'll probably need Eclipse anyway to debug the Java >> > > code. >> > > > If you're super hardcore, I believe that this command is still in >> the >> > > wiki >> > > > here: >> > > > >> > > > http://wiki.apache.org/cordova/RunningTests >> > > > >> > > > Also, are other platforms doing testing outside of mobile-spec >> Jasmine >> > > > tests? What impact would this have on CI work? I'm pretty sure that >> > the >> > > > Android tests should be relatively simple. >> > > > >> > > > Joe >> > > > >> > > >> > >> > >
Re: [Android] Can everyone run the tests?
I did send an e-mail about the cleaning of the tests with the wiki article. Did everyone get it? On Mon, Nov 5, 2012 at 9:21 AM, Andrew Grieve wrote: > Yes, thanks Joe for pushing on this. Testing will only make things better! > > Do you think it'd be feasible to create a script that would launch the > tests? Eclipse is great when they fail, but to ensure they pass, command > line is often nicer. The instructions on the wiki seem like they may be out > of date? They reference phonegap, and they don't say what cordova target to > build. > > > On Fri, Nov 2, 2012 at 9:25 PM, Joe Bowser wrote: > > > If we still have JAR issues, that should be a blocker for the release. > > Having these tests should be required now, since we have too many Java > > bits that we can't break. I removed the old Selenium JAR a while ago. > > > > I would love it if we could get Selenium to work with CordovaWebView so > > that we could click on HTML elements, but we should be able to automate > the > > Back Button and Menu Button bindings, as well as random key bindings. > That > > being said, we should be able to execute Javascript to do what we need > > instead of testing touch and click events, which in theory should have > been > > tested as part of Android's CTS. (No idea if this ever happens). > > > > > > On Fri, Nov 2, 2012 at 5:58 PM, Simon MacDonald > > wrote: > > > > > That's great Joe. I was under the impression that the Android repo > tests > > > were still dependent on a jar we didn't have access to. I'll make sure > > > running the tests is part of my regular process and "gasp" I will even > > > write a few. > > > > > > Simon Mac Donald > > > http://hi.im/simonmacdonald > > > > > > > > > On Fri, Nov 2, 2012 at 4:38 PM, Joe Bowser wrote: > > > > > > > Hey > > > > > > > > After the last scare with CordovaWebView, I want to know if everyone > > who > > > > commits on Android can run the tests that are currently committed > with > > > > Android? You have to be able to do both things with the tests in > > Eclipse: > > > > > > > > 1. Run the test as an Android Application > > > > 2. Run the Android JUnit Tests > > > > > > > > There is a command-line method to do this, but honestly if you're > > finding > > > > failures here, you'll probably need Eclipse anyway to debug the Java > > > code. > > > > If you're super hardcore, I believe that this command is still in > the > > > wiki > > > > here: > > > > > > > > http://wiki.apache.org/cordova/RunningTests > > > > > > > > Also, are other platforms doing testing outside of mobile-spec > Jasmine > > > > tests? What impact would this have on CI work? I'm pretty sure that > > the > > > > Android tests should be relatively simple. > > > > > > > > Joe > > > > > > > > > >
Re: [Android] CordovaWebView is broken
Hey I know that this kind of seems like a step back, but perhaps we should start with the refactor of DroidGap into CordovaActivity. The main obstacle that we have right now with the CordovaWebView is the fact that we have to implement everything in CordovaInterface. While we can't get rid of this, we could create a helper activity that implements this by moving the current methods from DroidGap into that. Then we can make DroidGap simply an activity that creates the view and optional. Due to the nature of Java, anyone combining other custom activites (i.e. MapActivity) will still have to implement the CordovaInterface, but this should further lower the barrier for many people who want to mix CordovaWebView with Android UI controls, namely the menu bar (in fact, this is the only UI control that I think anyone would want to add). Thoughts? On Mon, Nov 5, 2012 at 9:10 AM, Andrew Grieve wrote: > Aah, I didn't realize that CordovaInterface was meant to be implemented > other than by DroidGap. Sorry about that. Weird that projects would even > compile without having the new method though. > > Once the tests are fixed up, we should definitely add running them to the > list of release steps. > > > On Fri, Nov 2, 2012 at 4:27 PM, Joe Bowser wrote: > > > Nevermindit's kinda bad but it's not minor release bad. > > > > Basically, adding the thread pool method requirement to the > > CordovaInterface is what broke this. For some reason when you don't > have a > > thread pool, Cordova silently fails instead of dumping core all over the > > place. Is it possible that we can get plugins to get the thread pool > from > > elsewhere, or does it have to be in the Activity? > > > > > > > > > > On Fri, Nov 2, 2012 at 1:08 PM, Joe Bowser wrote: > > > > > Hey > > > > > > I just started fixing up our broken JUnit Tests, and I discovered that > > the > > > recent refactors broke the CordovaWebView standalone component. This > > means > > > that anyone who is using the CordovaWebView as a standalone component > > > should probably not upgrade to 2.2.0 and that we'll have to issue a > 2.2.1 > > > release to address this issue. > > > > > > It seems that for some reason deviceready is no longer firing. I think > > > this may have to do with the recent changes to plugins as well as the > > > addition of a thread pool. I'm going to commit the fixes to the tests > > > today, but you can recreate the issue by pulling down this debug repo, > > > putting it in Eclipse and making it use Cordova as a library. > > > > > > https://github.com/infil00p/CordovaActionView/tree/debug_version > > > > > > Also, you can debug this using the default activity on the test > project, > > > although the test project still needs a lot of cleaning to be done. > > > > > > It sucks that we missed this, but we really need to make sure we don't > > > break the tests when we do a refactor. > > > > > > I'll add more details to the bug soon. This harsh sucks, because I > don't > > > think this will be an easy fix. :( > > > > > > Joe > > > > > >
Re: [Android] Can everyone run the tests?
Yes, thanks Joe for pushing on this. Testing will only make things better! Do you think it'd be feasible to create a script that would launch the tests? Eclipse is great when they fail, but to ensure they pass, command line is often nicer. The instructions on the wiki seem like they may be out of date? They reference phonegap, and they don't say what cordova target to build. On Fri, Nov 2, 2012 at 9:25 PM, Joe Bowser wrote: > If we still have JAR issues, that should be a blocker for the release. > Having these tests should be required now, since we have too many Java > bits that we can't break. I removed the old Selenium JAR a while ago. > > I would love it if we could get Selenium to work with CordovaWebView so > that we could click on HTML elements, but we should be able to automate the > Back Button and Menu Button bindings, as well as random key bindings. That > being said, we should be able to execute Javascript to do what we need > instead of testing touch and click events, which in theory should have been > tested as part of Android's CTS. (No idea if this ever happens). > > > On Fri, Nov 2, 2012 at 5:58 PM, Simon MacDonald > wrote: > > > That's great Joe. I was under the impression that the Android repo tests > > were still dependent on a jar we didn't have access to. I'll make sure > > running the tests is part of my regular process and "gasp" I will even > > write a few. > > > > Simon Mac Donald > > http://hi.im/simonmacdonald > > > > > > On Fri, Nov 2, 2012 at 4:38 PM, Joe Bowser wrote: > > > > > Hey > > > > > > After the last scare with CordovaWebView, I want to know if everyone > who > > > commits on Android can run the tests that are currently committed with > > > Android? You have to be able to do both things with the tests in > Eclipse: > > > > > > 1. Run the test as an Android Application > > > 2. Run the Android JUnit Tests > > > > > > There is a command-line method to do this, but honestly if you're > finding > > > failures here, you'll probably need Eclipse anyway to debug the Java > > code. > > > If you're super hardcore, I believe that this command is still in the > > wiki > > > here: > > > > > > http://wiki.apache.org/cordova/RunningTests > > > > > > Also, are other platforms doing testing outside of mobile-spec Jasmine > > > tests? What impact would this have on CI work? I'm pretty sure that > the > > > Android tests should be relatively simple. > > > > > > Joe > > > > > >
Updating Release + Test articles on the wiki
I think both our cutting releases [1] and our running tests [2] wiki articles need an audit. After last week's little scare with Android's CordovaWebView functionality, I'd like to see all platforms note down any special release/testing steps in these articles (compiling the "Starter" zip on WP7 comes to mind). Same as running the ./cordova/debug and ./cordova/emulate test scripts on Android. [1] http://wiki.apache.org/cordova/CuttingReleases [2] http://wiki.apache.org/cordova/RunningTests
Re: [Android] CordovaWebView is broken
>Once the tests are fixed up, we should definitely add running them to the >list of release steps. +1
Re: iOS: Why does the cordova.js filename change?
On Fri, Nov 2, 2012 at 6:20 PM, Shazron wrote: > Ok I found out its actually in two locations, it's in the > CordovaLibAppTests/www folder as well as the bin/template. > > Yeah having one location would be best -- we did have it not having the > version before though, with copying/updates based on the Makefile. > > I'm thinking we only update: > CordovaLib/cordova.ios.js with the latest from cordova-js > > I think we could do this without the explicit step. > Then for a release, run a script/Makefile target to update: > 1. CordovaLibAppTests/www/cordova.ios.js > For this, we can add a copy step to the build phases to copy the file in from CordovaLib on each build > 2. bin/templates/project/www with the versioned .js > For this, we can have the create script just grab the .js file from CordovaLib instead of from the templates directory. > > On Fri, Nov 2, 2012 at 2:49 PM, Andrew Grieve > wrote: > > > It actually does bother me a little bit too, to have the file name have a > > version in it when we're developing. > > > > I don't really care where we put the file so long as there is only one > copy > > of it and not multiple. > > > > > > On Wed, Oct 31, 2012 at 4:22 PM, Shazron wrote: > > > > > On iOS, the cordova.js used to (inertia really because of the legacy > > > location) be in the CordovaLib folder, and also the template. Since it > > > was redundant, we only put it in the default template in > > > bin/templates/project now. > > > > > > Even this is not ideal with respect to people upgrading and using it > > > as an embedded WebView -- to grab the new .js they have to create a > > > new project (or spelunk into the bin/templates folder). Ideally it > > > should be put back also into CordovaLib because the .js is tightly > > > coupled to a specific CordovaLib library and version, and for easy > > > discovery. Don't know what the ideal situation can be here. > > > > > > On Tue, Oct 30, 2012 at 5:34 PM, Kevin Hawkins < > khawk...@salesforce.com> > > > wrote: > > > > Hi all, > > > > > > > > Apologies if/that I've missed this discussion previously. I'm not > > clear > > > on why the cordova.js file name changes in the iOS repo, particularly > > given > > > the fact that great lengths seem to have been taken everywhere to be > > > agnostic about what the originating name is, opting to dynamically > update > > > the destination name in build scripts, template generation, etc.? > > > > > > > > Changing the originating file name with each new iteration/revision > of > > > Cordova makes it hard to follow its history on GitHub (though it's easy > > > enough locally with git log and --follow), and just generally seems > > > unnecessary. > > > > > > > > Thanks, > > > > Kevin > > > > > > > > > >
Re: [Android] CordovaWebView is broken
Aah, I didn't realize that CordovaInterface was meant to be implemented other than by DroidGap. Sorry about that. Weird that projects would even compile without having the new method though. Once the tests are fixed up, we should definitely add running them to the list of release steps. On Fri, Nov 2, 2012 at 4:27 PM, Joe Bowser wrote: > Nevermindit's kinda bad but it's not minor release bad. > > Basically, adding the thread pool method requirement to the > CordovaInterface is what broke this. For some reason when you don't have a > thread pool, Cordova silently fails instead of dumping core all over the > place. Is it possible that we can get plugins to get the thread pool from > elsewhere, or does it have to be in the Activity? > > > > > On Fri, Nov 2, 2012 at 1:08 PM, Joe Bowser wrote: > > > Hey > > > > I just started fixing up our broken JUnit Tests, and I discovered that > the > > recent refactors broke the CordovaWebView standalone component. This > means > > that anyone who is using the CordovaWebView as a standalone component > > should probably not upgrade to 2.2.0 and that we'll have to issue a 2.2.1 > > release to address this issue. > > > > It seems that for some reason deviceready is no longer firing. I think > > this may have to do with the recent changes to plugins as well as the > > addition of a thread pool. I'm going to commit the fixes to the tests > > today, but you can recreate the issue by pulling down this debug repo, > > putting it in Eclipse and making it use Cordova as a library. > > > > https://github.com/infil00p/CordovaActionView/tree/debug_version > > > > Also, you can debug this using the default activity on the test project, > > although the test project still needs a lot of cleaning to be done. > > > > It sucks that we missed this, but we really need to make sure we don't > > break the tests when we do a refactor. > > > > I'll add more details to the bug soon. This harsh sucks, because I don't > > think this will be an easy fix. :( > > > > Joe > > >
[jira] [Commented] (CB-1286) Cordova 2.1 callbacks stops working after sleep/wake with jQuery Mobile + Android Transformer Pad
[ https://issues.apache.org/jira/browse/CB-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490675#comment-13490675 ] Simon MacDonald commented on CB-1286: - Cool, thanks for the investigation. Have you created a separate issue for this bug? If not you should and include these findings. > Cordova 2.1 callbacks stops working after sleep/wake with jQuery Mobile + > Android Transformer Pad > - > > Key: CB-1286 > URL: https://issues.apache.org/jira/browse/CB-1286 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.0.0 > Environment: Android 4.0.3; Asus Transformer Pad, >Reporter: Walter Nicholls >Assignee: Joe Bowser > Fix For: 2.2.0 > > Attachments: TPadBug-debug.apk, TPadBug-src.zip > > > Using attached sample app, program works up until tablet goes to sleep. When > the tablet wakes up, callback no longer functions > Full thread of original problem report: > https://groups.google.com/forum/?fromgroups=#!topic/phonegap/ut3RqEgDx58 > I started with Cordova 2.0.0, then while investigating upgraded to > development code from github and struck an introduced, now fixed, problem. SO > I am now back to the original issue but with latest code (2.1 RC) > Steps to reproduce: > -- > 1. Install attached APK file (I also include source in separate zip (includes > cordova.jar file), and run program. > 2. Touch the "dialog" button > OBSERVED: Text says "mary had a little lamb..." ( result from plugin) > 3. Touch "Close" to return to front screen > 4. Wait for the tablet to go to sleep and disconnect from network etc - takes > about 5 minutes with my tablet as it is configured. (screen going dark is not > enough, it has to shut down into deep sleep) > 5. Wake the tablet and unlock screen > 6. Touch the "dialog" buitton again. > EXPECTED: Text "mary had a little lamb..." again > but OBSERVED: Text "if you are reading this something went wrong" > What seems to be happening > --- > The way the dialog works is that the "something wrong" message is the text in > the HTML file, but the page show functions calls a plugin to get the text to > show. This is all handled by jQuery Mobile with an ajax load. > Until the deep sleep point, everything works as expected, the plugin returns > a result which is placed in the queue, then the setTimeout()-based Javascript > side picks it up. > After deep sleep, the callback mechanism breaks, and although the plugin is > called and produces a result, this is never collected from Javascript. > I watch the log with the command : > adb logcat -v time | grep -E "Cordova|Callback|DroidGap|TPadBug" > So while it is working... > 8-28 14:15:32.180 D/DroidGap(29867): > onMessage(onPageFinished,file:///android_asset/www/index.html#/android_asset/www/index.html&ui-state=dialog) > 08-28 14:15:32.200 D/CordovaLog(29867): Dialog is about to call plugin > 08-28 14:15:32.200 D/CordovaLog(29867): > file:///android_asset/www/tpadbug2.js: Line 44 : Dialog is about to call > plugin > 08-28 14:15:32.200 D/TPadBugPlugin(29867): Enter plugin action:GetRandomText > 08-28 14:15:32.200 D/TPadBugPlugin(29867): Plugin successful > 08-28 14:15:32.200 D/TPadBugPlugin(29867): Plugin exiting > 08-28 14:15:32.250 D/CordovaLog(29867): Dialog has got results back from > plugin: 102 chars > 08-28 14:15:32.250 D/CordovaLog(29867): > file:///android_asset/www/tpadbug2.js: Line 47 : Dialog has got results back > from plugin: 102 chars > 08-28 14:15:35.770 D/Cordova (29867): > onPageFinished(file:///android_asset/www/index.html) > Note particular the "Dialog has got results back.." which shows the JS > callback working. > After a sleep/resume cycle: > 08-28 14:23:05.880 D/DroidGap(29867): > onMessage(onPageFinished,file:///android_asset/www/index.html#/android_asset/www/index.html&ui-state=dialog) > 08-28 14:23:05.900 D/CordovaLog(29867): Dialog is about to call plugin > 08-28 14:23:05.900 D/CordovaLog(29867): > file:///android_asset/www/tpadbug2.js: Line 44 : Dialog is about to call > plugin > 08-28 14:23:05.900 D/TPadBugPlugin(29867): Enter plugin action:GetRandomText > 08-28 14:23:05.900 D/TPadBugPlugin(29867): Plugin successful > 08-28 14:23:05.900 D/TPadBugPlugin(29867): Plugin exiting > .. and nothing more, no dialog handler. > (I did have a lot of console.log and Log.d calls as well, but these got lost > in some of the test and updating to latest code. Read Google Groups thread > for the agonizing detail). > Needless to say, this stops my app in its tracks. > I left an additional page for "test timeouts" which if you navigate to this, > it shows that callbacks are once again working, and then when yo
