[jira] [Commented] (CB-7499) Cordova dialogs should support BIDI text
[
https://issues.apache.org/jira/browse/CB-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14169876#comment-14169876
]
Mike Billau commented on CB-7499:
-
Thanks Andrew for checking this out.
Agree about the engine tag.
To answer your question, yes plugins should check the API level.
I see you've already pulled in a fix to do this check:
https://github.com/apache/cordova-plugin-dialogs/commit/4cfe290b2a3e8f0aafb71a1ff4fbee4b710c8749
Tested on 2.3.3, looks great. Thanks.
Cordova dialogs should support BIDI text
Key: CB-7499
URL: https://issues.apache.org/jira/browse/CB-7499
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Dialogs
Affects Versions: Master
Reporter: Mike Billau
Assignee: Mike Billau
Priority: Minor
Labels: bidirectional, globalization
Fix For: 3.7.0
Since API 19, Andorid has had the facilities to deal with bidirectional text,
however, current Cordova notification implementation does not correctly
handle bidirectional text in dialogs.
We can see this is the case by first setting the language to Hebrew and then
launching the following dialogs:
navigator.notification.confirm(Pure English !!!, function(){}, 7);
navigator.notification.confirm(עברית היא שפה מדוברת בIsrael !,
function(){}, 8);
Since we are in Hebrew, the base text direction will be RTL. This means that
when we see the second notification with the Hebrew text, it will be
right-justified. When we click and see the Pure English !!! notication,
because locale is RTL, we should expect to see: !!! Pure English and it
should be right-justified, however, we still see Pure English !!!, left
justified.
http://w3-03.ibm.com/globalization/page/publish/4353
Ideally you should be able to just add android:supportsRtl=true to the
manifest, however, this is doesn't seem to ne enough without setting the text
direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-7499) Cordova dialogs should support BIDI text
[
https://issues.apache.org/jira/browse/CB-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135355#comment-14135355
]
Mike Billau commented on CB-7499:
-
Hmmm, this plugin now depends on a specific version of Android (at least for
this feature to work) so maybe I need add in the engine tag to plugin.xml?
Cordova dialogs should support BIDI text
Key: CB-7499
URL: https://issues.apache.org/jira/browse/CB-7499
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Dialogs
Affects Versions: Master
Reporter: Mike Billau
Assignee: Mike Billau
Priority: Minor
Labels: bidirectional, globalization
Fix For: 3.7.0
Since API 19, Andorid has had the facilities to deal with bidirectional text,
however, current Cordova notification implementation does not correctly
handle bidirectional text in dialogs.
We can see this is the case by first setting the language to Hebrew and then
launching the following dialogs:
navigator.notification.confirm(Pure English !!!, function(){}, 7);
navigator.notification.confirm(עברית היא שפה מדוברת בIsrael !,
function(){}, 8);
Since we are in Hebrew, the base text direction will be RTL. This means that
when we see the second notification with the Hebrew text, it will be
right-justified. When we click and see the Pure English !!! notication,
because locale is RTL, we should expect to see: !!! Pure English and it
should be right-justified, however, we still see Pure English !!!, left
justified.
http://w3-03.ibm.com/globalization/page/publish/4353
Ideally you should be able to just add android:supportsRtl=true to the
manifest, however, this is doesn't seem to ne enough without setting the text
direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CB-6490) getLocaleName does not return consistent results depending on the platform
[ https://issues.apache.org/jira/browse/CB-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128814#comment-14128814 ] Mike Billau commented on CB-6490: - Android uses a dash. getLocaleName does not return consistent results depending on the platform -- Key: CB-6490 URL: https://issues.apache.org/jira/browse/CB-6490 Project: Apache Cordova Issue Type: Bug Components: Plugin Globalization, WP8 Environment: Windows Phone 8 Reporter: Pascale Dardailler Assignee: Jesse MacFadyen getLocaleName does not return consistent results depending on the platform. The documentation should be changed to state that it should return a BCP 47 representation of Unicode locale identifier (see http://www.unicode.org/reports/tr35/#Unicode_locale_identifier - section 3.3.1 BCP 47 tag conversion) to identify the culture of the user, and disambiguate the region as a place. Implementation should be changed accordingly. WindowsPhone 8 implementation is incorrect. Returning country code is not enough. It should use CultureInfo.CurrentCulture.Name. Android and iOS should use dashes instead of underscores. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CB-6490) getLocaleName does not return consistent results depending on the platform
[ https://issues.apache.org/jira/browse/CB-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-6490. - Resolution: Fixed Fix Version/s: 3.6.0 Assignee: Mike Billau (was: Jesse MacFadyen) getLocaleName does not return consistent results depending on the platform -- Key: CB-6490 URL: https://issues.apache.org/jira/browse/CB-6490 Project: Apache Cordova Issue Type: Bug Components: Plugin Globalization, WP8 Environment: Windows Phone 8 Reporter: Pascale Dardailler Assignee: Mike Billau Fix For: 3.6.0 getLocaleName does not return consistent results depending on the platform. The documentation should be changed to state that it should return a BCP 47 representation of Unicode locale identifier (see http://www.unicode.org/reports/tr35/#Unicode_locale_identifier - section 3.3.1 BCP 47 tag conversion) to identify the culture of the user, and disambiguate the region as a place. Implementation should be changed accordingly. WindowsPhone 8 implementation is incorrect. Returning country code is not enough. It should use CultureInfo.CurrentCulture.Name. Android and iOS should use dashes instead of underscores. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-4822) globalization.getLocaleName does not always return the real country setting
[ https://issues.apache.org/jira/browse/CB-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128886#comment-14128886 ] Mike Billau commented on CB-4822: - Android returns en-GB when I set the language to English (United Kingdom), so this looks right for Android. globalization.getLocaleName does not always return the real country setting --- Key: CB-4822 URL: https://issues.apache.org/jira/browse/CB-4822 Project: Apache Cordova Issue Type: Improvement Components: Plugin Globalization Affects Versions: 2.7.0 Reporter: Ingmar Bode Due to the documentation globalization.getLocaleName returns the locale identifier of the browser. Unfortunately on some devices (e.g. iOS) the browsers seem to return some kind of fake locale. For example, when I go in my iPhone's settings and set language: en and region: uk, globalization.getLocaleName returns en_US though I would expect en_UK. Is there any way you guys can make Cordova return the real region set in the phones settings - and not what the phone's browser thinks? Btw: We are using Telerik's Icenium. They are currently working with Cordova 2.7., so maybe this issue has already been improved/fixed in later Cordova versions? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CB-4822) globalization.getLocaleName does not always return the real country setting
[ https://issues.apache.org/jira/browse/CB-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-4822. - Resolution: Fixed globalization.getLocaleName does not always return the real country setting --- Key: CB-4822 URL: https://issues.apache.org/jira/browse/CB-4822 Project: Apache Cordova Issue Type: Improvement Components: Plugin Globalization Affects Versions: 2.7.0 Reporter: Ingmar Bode Due to the documentation globalization.getLocaleName returns the locale identifier of the browser. Unfortunately on some devices (e.g. iOS) the browsers seem to return some kind of fake locale. For example, when I go in my iPhone's settings and set language: en and region: uk, globalization.getLocaleName returns en_US though I would expect en_UK. Is there any way you guys can make Cordova return the real region set in the phones settings - and not what the phone's browser thinks? Btw: We are using Telerik's Icenium. They are currently working with Cordova 2.7., so maybe this issue has already been improved/fixed in later Cordova versions? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CB-7499) Cordova dialogs should support BIDI text
Mike Billau created CB-7499:
---
Summary: Cordova dialogs should support BIDI text
Key: CB-7499
URL: https://issues.apache.org/jira/browse/CB-7499
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Dialogs
Affects Versions: Master
Reporter: Mike Billau
Assignee: Mike Billau
Priority: Minor
Since API 19, Andorid has had the facilities to deal with bidirectional text,
however, current Cordova notification implementation does not correctly handle
bidirectional text in dialogs.
We can see this is the case by first setting the language to Hebrew and then
launching the following dialogs:
navigator.notification.confirm(Pure English !!!, function(){}, 7);
navigator.notification.confirm(עברית היא שפה מדוברת בIsrael !,
function(){}, 8);
Since we are in Hebrew, the base text direction will be RTL. This means that
when we see the second notification with the Hebrew text, it will be
right-justified. When we click and see the Pure English !!! notication,
because locale is RTL, we should expect to see: !!! Pure English and it
should be right-justified, however, we still see Pure English !!!, left
justified.
http://w3-03.ibm.com/globalization/page/publish/4353
Ideally you should be able to just add android:supportsRtl=true to the
manifest, however, this is doesn't seem to ne enough without setting the text
direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CB-677) Docs/Getting Started Guides
[ https://issues.apache.org/jira/browse/CB-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14095534#comment-14095534 ] Mike Billau commented on CB-677: [~adamcmiel] I think you should ask that question on the dev list. We have been having discussions about the docs and doc generation on and off for a while now. Docs/Getting Started Guides --- Key: CB-677 URL: https://issues.apache.org/jira/browse/CB-677 Project: Apache Cordova Issue Type: Improvement Components: Docs Affects Versions: Master Reporter: Andrew Trice Assignee: Michael Brooks Priority: Minor Fix For: Master I have gotten a lot of feedback from Adobe customers and developers at conferences on this... In general, the getting started guides are great at getting people's environments configured, but many end up wondering what do I do next. It would be great to have docs/guidance on next steps, including strategies to make your apps feel more like apps and less like the web, performance optimizations, and possibly case studies on how showcase apps were created. This JIRA issue is intended for tracking purposes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14029618#comment-14029618 ] Mike Billau commented on CB-5294: - I tested with Firefox and Chrome and both of them upload an image with the exact same filename as the one you select, so we are doing something different somewhere. At least the data gets transferred. File input element not opening file picker in Android 4.4 - Key: CB-5294 URL: https://issues.apache.org/jira/browse/CB-5294 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.1.0 Environment: Android 4.4.2, partially fixed in Android 4.4.3 Reporter: Paul Kane Assignee: Ian Clelland The file input field doesn't respond when clicked/tapped in Android 4.4. Works fine in previous Android versions. This is regardless of whether the Target Level is set to 18 or 19. To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only modification I made to the default (placeholder) index.html file was adding a form element with a single input type=file element inside. Clicking the Choose File button does nothing. No Logcat output or errors. Normally at this point a dialogue would open allowing me to select an image from the gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-5469) Document how to run npm without sudo
[ https://issues.apache.org/jira/browse/CB-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-5469. - Resolution: Fixed Resolved here: https://github.com/apache/cordova-docs/commit/7115ca4155e32ab49d7ebcecbe82f486056b76a6 Document how to run npm without sudo Key: CB-5469 URL: https://issues.apache.org/jira/browse/CB-5469 Project: Apache Cordova Issue Type: Bug Components: Docs Reporter: Mike Billau Assignee: Mike Billau Priority: Minor Fix For: 3.6.0 We ask users to install npm globally. Whether or not we are going to continue to suggest this is a different debate, but in the mean time we should talk about how they can set up npm to run without requiring sudo/Administrator. There is a wiki page here that talks about it: https://wiki.apache.org/cordova/npm_rc We need to build out this wiki page and then link to it in the docs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14019848#comment-14019848 ] Mike Billau commented on CB-5294: - Seems mostly fixed for me on Nexus 5 running 4.4.3. The button opens the file chooser dialog. No matter what source I select, the asset does seem to be uploaded. However, if you select from Recent or Images, the file will be renamed from something like IMG_234234.jpg -- image%3A24. If you select from Downloads, or Gallery, the image will be renamed from: IMG_23432423.jpg -- 24 File input element not opening file picker in Android 4.4 - Key: CB-5294 URL: https://issues.apache.org/jira/browse/CB-5294 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.1.0 Environment: Android 4.4.2, partially fixed in Android 4.4.3 Reporter: Paul Kane Assignee: Ian Clelland The file input field doesn't respond when clicked/tapped in Android 4.4. Works fine in previous Android versions. This is regardless of whether the Target Level is set to 18 or 19. To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only modification I made to the default (placeholder) index.html file was adding a form element with a single input type=file element inside. Clicking the Choose File button does nothing. No Logcat output or errors. Normally at this point a dialogue would open allowing me to select an image from the gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-5470) Document differences between CLI and shell workflows
[ https://issues.apache.org/jira/browse/CB-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-5470. - Resolution: Won't Fix I don't think we need to be per scribing a certain workflow over the other, which is what this would turn into. Document differences between CLI and shell workflows Key: CB-5470 URL: https://issues.apache.org/jira/browse/CB-5470 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: Master Reporter: Mike Billau Assignee: Mike Billau Priority: Minor Fix For: 3.6.0 After CB-5122, we have documented the two different workflows, the CLI and the shell scripts. However, we should further document the advantages and disadvantages to each workflow. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011109#comment-14011109 ] Mike Billau commented on CB-5398: - [~roy_lecare], I was unable to reproduce the error with your code on Cordova 3.5, Camera 0.2.9 What source were you using to select the picture from? Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau Fix For: 3.5.0 An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CB-5786) document security best practices
[ https://issues.apache.org/jira/browse/CB-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau closed CB-5786. --- Resolution: Fixed Fix Version/s: 3.5.0 Added the first draft. Thanks everybody for the help. https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=7e6d5b9bc51c5249f20f7c3f2493923d609c7418 Will continue to iterate on it as we go alone. document security best practices Key: CB-5786 URL: https://issues.apache.org/jira/browse/CB-5786 Project: Apache Cordova Issue Type: Improvement Components: Docs Reporter: Marcel Kinard Priority: Minor Fix For: 3.5.0 Would be nice if cordova-docs included a section on security in general. Potential content could include: - in general how does Cordova work - common areas where devs may shoot themselves in the foot - what the whitelist does and doesn't do - when to consider InAppBrowser -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-2179) Warn developers about including third-party content in their apps.
[ https://issues.apache.org/jira/browse/CB-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-2179. - Resolution: Fixed Warn developers about including third-party content in their apps. -- Key: CB-2179 URL: https://issues.apache.org/jira/browse/CB-2179 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 2.4.0, 2.5.0, 2.6.0 Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 3.5.0 We expose our native APIs to iframes as well as top-level content, so we should warn against using iframes for third-party code. Might make sense to change Domain Whitelist Guide - Security Whitelist Guide and then add a section to it about the dangers of embedding untrusted content. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-2179) Warn developers about including third-party content in their apps.
[ https://issues.apache.org/jira/browse/CB-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003838#comment-14003838 ] Mike Billau commented on CB-2179: - Added a new Security guide, documented that they should use InAppBrowser for any and all third party content and explained that otherwise, those third party pages will have access to the bridge. https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=7e6d5b9bc51c5249f20f7c3f2493923d609c7418 Warn developers about including third-party content in their apps. -- Key: CB-2179 URL: https://issues.apache.org/jira/browse/CB-2179 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 2.4.0, 2.5.0, 2.6.0 Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 3.5.0 We expose our native APIs to iframes as well as top-level content, so we should warn against using iframes for third-party code. Might make sense to change Domain Whitelist Guide - Security Whitelist Guide and then add a section to it about the dangers of embedding untrusted content. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-677) Docs/Getting Started Guides
[ https://issues.apache.org/jira/browse/CB-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13986549#comment-13986549 ] Mike Billau commented on CB-677: Ray has started working on this here: https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit# Looking awesome so far, thanks Ray! Docs/Getting Started Guides --- Key: CB-677 URL: https://issues.apache.org/jira/browse/CB-677 Project: Apache Cordova Issue Type: Improvement Components: Docs Affects Versions: Master Reporter: Andrew Trice Assignee: Michael Brooks Priority: Minor Fix For: Master I have gotten a lot of feedback from Adobe customers and developers at conferences on this... In general, the getting started guides are great at getting people's environments configured, but many end up wondering what do I do next. It would be great to have docs/guidance on next steps, including strategies to make your apps feel more like apps and less like the web, performance optimizations, and possibly case studies on how showcase apps were created. This JIRA issue is intended for tracking purposes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-4602) getPreferredLanguage platform inconsistencies
[
https://issues.apache.org/jira/browse/CB-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984437#comment-13984437
]
Mike Billau commented on CB-4602:
-
I made some changes to the implementation above. I found out that Java 7
implements a method called Locale#toLanguageTag(), so I followed that as much
as possible. I pushed up a new branch to the globalization plugin because there
are a few other changes that we are in the process of making, so we will just
commit to that branch and then bump the major version once.
https://github.com/apache/cordova-plugin-globalization/commit/baea8a295daebdb6cc2bfcdcb612d6c988a8e08a
Somehow git reverted some of the previous changes (changing new Long() to
Long.valueOf), so I'll figure out why and fix that.
getPreferredLanguage platform inconsistencies
-
Key: CB-4602
URL: https://issues.apache.org/jira/browse/CB-4602
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Globalization
Affects Versions: 2.6.0, 3.0.0
Environment: Android
Reporter: Jon Whitlock
Assignee: Mike Billau
Priority: Minor
In;
https://github.com/apache/cordova-docs/blob/master/docs/en/edge/cordova/globalization/globalization.getPreferredLanguage.md
Returns the language identifier string to the successCallback with a
properties object as a parameter. That object should have a value property
with a String value.
navigator.globalization.getPreferredLanguage(
function (language) {alert('language: ' + language.value + '\n');},
function () {alert('Error getting language\n');}
);
On Android the function doesn't seem to return an identifier as such, it
returns *a string describing the language localised to that language*, e.g.
English for English or 中文 for Japanese. Naturally this is less than ideal
for subsequent string operations, furthermore on that page Windows Phone 8
Quirks - Returns the ISO 639-1 two-letter code for the current language
which is an identifier, and also what I would expect (or an ISO 639-2 code,
as per http://www.loc.gov/standards/iso639-2/php/code_list.php)
Android seems to support 639-2
http://developer.android.com/reference/java/util/Locale.html#getISO3Language()
I have no idea what it returns on other platforms, but to keep client code
consistent I guess it would good if this could be normalised in the API.
Have tested this on v3.0 and 2.6, is the same.
As an aside, the locale is not really what I want here, as the user may be in
the US but have Japanese as their preferred language.
Thanks,
jon
(first go at using Jira, apols if I got something wrong!)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-4602) getPreferredLanguage platform inconsistencies
[
https://issues.apache.org/jira/browse/CB-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984618#comment-13984618
]
Mike Billau commented on CB-4602:
-
I'm not sure what the difference between getPreferredLanguage() and
getLocaleName() is. Should one return the BCP-47 language tag (en-US) while
the other return the actual text representation of the language (English)?
Based on some older docs:
http://cordova.apache.org/docs/en/3.1.0/cordova_globalization_globalization.md.html#globalization.getPreferredLanguage,
it seems like getPreferredLanguage should return the textual representation
while getLocaleName should return the language tag.
That means I should revert the changes to getPreferredLanguage and make them to
getLocaleName() instead. This also means that WP8 and iOS will have to change
their implementation of getPreferredLanguage since they both return tags and
not string representations.
getPreferredLanguage platform inconsistencies
-
Key: CB-4602
URL: https://issues.apache.org/jira/browse/CB-4602
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Globalization
Affects Versions: 2.6.0, 3.0.0
Environment: Android
Reporter: Jon Whitlock
Assignee: Mike Billau
Priority: Minor
In;
https://github.com/apache/cordova-docs/blob/master/docs/en/edge/cordova/globalization/globalization.getPreferredLanguage.md
Returns the language identifier string to the successCallback with a
properties object as a parameter. That object should have a value property
with a String value.
navigator.globalization.getPreferredLanguage(
function (language) {alert('language: ' + language.value + '\n');},
function () {alert('Error getting language\n');}
);
On Android the function doesn't seem to return an identifier as such, it
returns *a string describing the language localised to that language*, e.g.
English for English or 中文 for Japanese. Naturally this is less than ideal
for subsequent string operations, furthermore on that page Windows Phone 8
Quirks - Returns the ISO 639-1 two-letter code for the current language
which is an identifier, and also what I would expect (or an ISO 639-2 code,
as per http://www.loc.gov/standards/iso639-2/php/code_list.php)
Android seems to support 639-2
http://developer.android.com/reference/java/util/Locale.html#getISO3Language()
I have no idea what it returns on other platforms, but to keep client code
consistent I guess it would good if this could be normalised in the API.
Have tested this on v3.0 and 2.6, is the same.
As an aside, the locale is not really what I want here, as the user may be in
the US but have Japanese as their preferred language.
Thanks,
jon
(first go at using Jira, apols if I got something wrong!)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-4602) getPreferredLanguage platform inconsistencies
[
https://issues.apache.org/jira/browse/CB-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979803#comment-13979803
]
Mike Billau commented on CB-4602:
-
According to http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html,
the Locale object implements identifiers interchangeable with BCP 47. This
means that for Android, we can simply return `Locale.getDefault()` and it
should be BCP47 compliant. I tried this:
locale = SIMPLIFIED_CHINESE, getDefault = zh_CN
locale = CHINESE, getDefault = zh
locale = TAIWAN, getDefault = zh_TW
locale= English, getDefault = en_US
These results match up with what [~pdardailler] mentioned above, execpt for the
underscore instead of the dash. I'm not sure why CHINESE locale only returned
zh. There also might be issues since according to
http://developer.android.com/reference/java/util/Locale.html, Java uses
several deprecated two-letter codes. The Hebrew (he) language code is
rewritten as iw, Indonesian (id) as in, and Yiddish (yi) as ji. This
rewriting happens even if you construct your own Locale object, not just for
instances returned by the various lookup methods.
Finally, since this is changing the return value of an API, we should probably
create a new method, like getPreferredLanguageCode() or something, instead of
just changing getPreferredLanguage().
getPreferredLanguage platform inconsistencies
-
Key: CB-4602
URL: https://issues.apache.org/jira/browse/CB-4602
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Globalization
Affects Versions: 2.6.0, 3.0.0
Environment: Android
Reporter: Jon Whitlock
Assignee: Martin Gonzalez
Priority: Minor
In;
https://github.com/apache/cordova-docs/blob/master/docs/en/edge/cordova/globalization/globalization.getPreferredLanguage.md
Returns the language identifier string to the successCallback with a
properties object as a parameter. That object should have a value property
with a String value.
navigator.globalization.getPreferredLanguage(
function (language) {alert('language: ' + language.value + '\n');},
function () {alert('Error getting language\n');}
);
On Android the function doesn't seem to return an identifier as such, it
returns *a string describing the language localised to that language*, e.g.
English for English or 中文 for Japanese. Naturally this is less than ideal
for subsequent string operations, furthermore on that page Windows Phone 8
Quirks - Returns the ISO 639-1 two-letter code for the current language
which is an identifier, and also what I would expect (or an ISO 639-2 code,
as per http://www.loc.gov/standards/iso639-2/php/code_list.php)
Android seems to support 639-2
http://developer.android.com/reference/java/util/Locale.html#getISO3Language()
I have no idea what it returns on other platforms, but to keep client code
consistent I guess it would good if this could be normalised in the API.
Have tested this on v3.0 and 2.6, is the same.
As an aside, the locale is not really what I want here, as the user may be in
the US but have Japanese as their preferred language.
Thanks,
jon
(first go at using Jira, apols if I got something wrong!)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6466) WP8 filetransfer.download() should auto mkdir missing folders
Mike Billau created CB-6466: --- Summary: WP8 filetransfer.download() should auto mkdir missing folders Key: CB-6466 URL: https://issues.apache.org/jira/browse/CB-6466 Project: Apache Cordova Issue Type: Bug Components: Plugin File Transfer, WP8 Affects Versions: 3.4.0 Reporter: Mike Billau Assignee: Jesse MacFadyen Windows Phone 8 implementation of FileTransfer.download() does not automatically create any missing directories when saving a file. The iOS and Android implementations do. If target = /foo/bar.jpg and /foo/ doesn't exist, WP8 should create it to bring the platform in line with iOS and Android. This mail thread shows that we've decided that FileTransfer should be slightly more than a thin wrapper on the File plugin (which has an API.) http://markmail.org/message/cxy66pe23oyguoal -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-4096) Android - Unify Whitelist Implemenations
[ https://issues.apache.org/jira/browse/CB-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13941840#comment-13941840 ] Mike Billau commented on CB-4096: - [~iclelland], yes that was the thread I was reading but somehow missed Andrew's argument against using subdomains attribute. Fail. I didn't realize that the attribute was never documented, I assumed that since it was in the instructions for setting up mobile-spec that it'd be in the Whitelist guide, but the only mention of it in the official docs seems to be under the Blackberry section. In light of this I agree, we should axe the subdomains=true attribute. Since it hasn't been documented, I think it's fine to completely take it out instead of belatedly deprecating. I'll withdrawal my pull request -- thanks a lot for the comments anyway. Android - Unify Whitelist Implemenations Key: CB-4096 URL: https://issues.apache.org/jira/browse/CB-4096 Project: Apache Cordova Issue Type: Sub-task Components: Android Affects Versions: 3.0.0 Reporter: Andrew Grieve Assignee: Ian Clelland Fix For: 3.1.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6311) Document developer-centeric CLI commands
Mike Billau created CB-6311: --- Summary: Document developer-centeric CLI commands Key: CB-6311 URL: https://issues.apache.org/jira/browse/CB-6311 Project: Apache Cordova Issue Type: Bug Components: CLI, Docs Affects Versions: 3.4.0 Reporter: Mike Billau Assignee: Mike Billau Priority: Minor There are a few CLI commands and parameters that are only useful for cordova developers and are thus not documented on our main docs site. It would be nice to document this information in the Cordova wiki. Some topics: Platform-specific preferences: http://markmail.org/thread/7kalpsmw7rcvsbo7 Creating myProject/.cordova/config.json to specify where the platforms should be installed from: https://github.com/apache/cordova-mobile-spec/blob/master/createmobilespec.sh#L57 Parameters in create, like --link-to: https://github.com/apache/cordova-mobile-spec/blob/master/createmobilespec.sh#L43 I'm sure there are others out there... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-4096) Android - Unify Whitelist Implemenations
[
https://issues.apache.org/jira/browse/CB-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13940696#comment-13940696
]
Mike Billau commented on CB-4096:
-
[~iclelland], what are the plans for the 'subdomains=true' flag? There was
nothing in the ML thread. The android code still parses out this attribute from
the XML and passes the flag around to all of the whitelist methods, it just
never utilizes it. It seems trivial to add code in
https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/Whitelist.java#L139
like this:
{code}
if( subdomains ){
if( scheme == null) scheme = ;
String sub = scheme + *. + host; // generate *.host subdomain
addWhiteListEntry(sub, false);
}
{code}
This would ensure back-compatibility for anyone still using the subdomains
flag. I think we might as well use this since so much of the code still passes
around the subdomain flag. We could add a deprecation notice here.
Android - Unify Whitelist Implemenations
Key: CB-4096
URL: https://issues.apache.org/jira/browse/CB-4096
Project: Apache Cordova
Issue Type: Sub-task
Components: Android
Affects Versions: 3.0.0
Reporter: Andrew Grieve
Assignee: Ian Clelland
Fix For: 3.1.0
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-4096) Android - Unify Whitelist Implemenations
[ https://issues.apache.org/jira/browse/CB-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13940819#comment-13940819 ] Mike Billau commented on CB-4096: - https://github.com/apache/cordova-android/pull/95 I can merge this in myself if nobody comments in the next few days. Android - Unify Whitelist Implemenations Key: CB-4096 URL: https://issues.apache.org/jira/browse/CB-4096 Project: Apache Cordova Issue Type: Sub-task Components: Android Affects Versions: 3.0.0 Reporter: Andrew Grieve Assignee: Ian Clelland Fix For: 3.1.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CB-5175) Fix core plugins that incorrectly run on main thread
[ https://issues.apache.org/jira/browse/CB-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau reassigned CB-5175: --- Assignee: Mike Billau Fix core plugins that incorrectly run on main thread Key: CB-5175 URL: https://issues.apache.org/jira/browse/CB-5175 Project: Apache Cordova Issue Type: Bug Components: Docs, Plugin Device Orientation, Plugin File, Plugin Media Reporter: Mike Billau Assignee: Mike Billau Priority: Minor After CB-4133 we are able to detect and log when a plugin incorrectly does work on the UI thread instead of a worker thread. We should go back and verify that all of our plugins follow this practice - eat your own dogfood type of thing. We know there are problems with: Android: file, compass iOS: media Docs: Need to verify plugin author guide is still valid -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5175) Fix core plugins that incorrectly run on main thread
[ https://issues.apache.org/jira/browse/CB-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13913522#comment-13913522 ] Mike Billau commented on CB-5175: - Started working on this, I'm just planning on going down the list of plugins as they appear in mobile spec. If somebody can give this a spot check, I'd appreciate it: https://github.com/mbillau/cordova-plugin-device-motion/commit/1cb25b6a8f7ca2e6bd0e5bb23d8838db3df0719c Fix core plugins that incorrectly run on main thread Key: CB-5175 URL: https://issues.apache.org/jira/browse/CB-5175 Project: Apache Cordova Issue Type: Bug Components: Docs, Plugin Device Orientation, Plugin File, Plugin Media Reporter: Mike Billau Assignee: Mike Billau Priority: Minor After CB-4133 we are able to detect and log when a plugin incorrectly does work on the UI thread instead of a worker thread. We should go back and verify that all of our plugins follow this practice - eat your own dogfood type of thing. We know there are problems with: Android: file, compass iOS: media Docs: Need to verify plugin author guide is still valid -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13901804#comment-13901804 ] Mike Billau commented on CB-5398: - Thanks for looking at this! I've been testing the update and it all seems good, I can access images from any source now, no matter what I set the destination_type to. I did see that sometimes pulling an image from Drive with data_url will cause the app to quit with an Out Of Memory error, even when the same image can be opened with destination_type=file_uri. I can't reproduce this reliably though, I think it might be the known issue of the Camera app shutting down. Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau Fix For: 3.5.0 An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CB-5202) Android Video Capture crashes app on 4.3
[ https://issues.apache.org/jira/browse/CB-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau closed CB-5202. --- Resolution: Fixed Fix Version/s: 3.5.0 Android Video Capture crashes app on 4.3 Key: CB-5202 URL: https://issues.apache.org/jira/browse/CB-5202 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Media Capture Affects Versions: 3.0.0 Environment: Android 4.3 Reporter: Tom Saunders Assignee: Andrew Grieve Fix For: 3.5.0 Using the cordova video capture plugin crashes the application when returning from the capture video intent. No data is returned. This is a known issue with Android 4.3, the workaround is to explicitly specify a location for saving the video Relevant stackoverflows: http://stackoverflow.com/questions/18472953/video-capture-in-android-4-3-using-camera-app-intent http://stackoverflow.com/questions/18120775/android-android-provider-mediastore-action-video-capture-return-null-onactivityr -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5202) Android Video Capture crashes app on 4.3
[ https://issues.apache.org/jira/browse/CB-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13899338#comment-13899338 ] Mike Billau commented on CB-5202: - New PR: https://github.com/apache/cordova-plugin-media-capture/pull/13 [~emmam] I don't have a i9250, would be interested to know if the above pull request fixes your issue as well. Android Video Capture crashes app on 4.3 Key: CB-5202 URL: https://issues.apache.org/jira/browse/CB-5202 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Media Capture Affects Versions: 3.0.0 Environment: Android 4.3 Reporter: Tom Saunders Assignee: Andrew Grieve Using the cordova video capture plugin crashes the application when returning from the capture video intent. No data is returned. This is a known issue with Android 4.3, the workaround is to explicitly specify a location for saving the video Relevant stackoverflows: http://stackoverflow.com/questions/18472953/video-capture-in-android-4-3-using-camera-app-intent http://stackoverflow.com/questions/18120775/android-android-provider-mediastore-action-video-capture-return-null-onactivityr -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13898217#comment-13898217 ] Mike Billau commented on CB-5294: - I've added a note to the Platform Upgrade Guide about this bug (it's kinda weird, we don't list Android platform-wide quirks anywhere so the Upgrade Guide seemed like a decent enough place to stick it.) Lets keep this ticket open so that every Android update we can check to see if this has been resolved, and if so, remove the quirk. File input element not opening file picker in Android 4.4 - Key: CB-5294 URL: https://issues.apache.org/jira/browse/CB-5294 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.1.0 Environment: Android 4.4 (emulator and Nexus 5) Reporter: Paul Kane Assignee: Joe Bowser The file input field doesn't respond when clicked/tapped in Android 4.4. Works fine in previous Android versions. This is regardless of whether the Target Level is set to 18 or 19. To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only modification I made to the default (placeholder) index.html file was adding a form element with a single input type=file element inside. Clicking the Choose File button does nothing. No Logcat output or errors. Normally at this point a dialogue would open allowing me to select an image from the gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5202) Android Video Capture crashes app on 4.3
[ https://issues.apache.org/jira/browse/CB-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886908#comment-13886908 ] Mike Billau commented on CB-5202: - I implemented a stripped down version of the pull request and it works great to fix the issue with 4.3. https://github.com/mbillau/cordova-plugin-media-capture/commit/8edfa3aea2906cd904ebc881cc822c14b8186411 Should I make a PR? If the original fix is from lubogospod do we first have to make sure he or she has signed the CLA? Android Video Capture crashes app on 4.3 Key: CB-5202 URL: https://issues.apache.org/jira/browse/CB-5202 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Media Capture Affects Versions: 3.0.0 Environment: Android 4.3 Reporter: Tom Saunders Assignee: Andrew Grieve Using the cordova video capture plugin crashes the application when returning from the capture video intent. No data is returned. This is a known issue with Android 4.3, the workaround is to explicitly specify a location for saving the video Relevant stackoverflows: http://stackoverflow.com/questions/18472953/video-capture-in-android-4-3-using-camera-app-intent http://stackoverflow.com/questions/18120775/android-android-provider-mediastore-action-video-capture-return-null-onactivityr -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13873646#comment-13873646 ] Mike Billau commented on CB-5398: - I'm trying to figure out where in Android there is a URI encoding bug so that we can report it and have the problem fixed upstream. However, I'm starting to think maybe we need to make some changes to incorporate the new Storage Access Framework...more specifically, checking different ContentProviders. I was able to implement the solution here: http://stackoverflow.com/a/20559175/368762 and it seems to work well for accessing images from all of the providers except for Drive. The new way of doing things seems to craft the URI based on which provider the data came from instead of just assuming uri = intent.getData() will be valid. Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13871092#comment-13871092 ] Mike Billau commented on CB-5398: - [~bowserj], can you please explain how you were able to determine that the first URI has the READ permission passed back to it? I couldn't find a bug report for this on the Android tracker and would like to file it but I'm not sure if I understand enough to actually file a decent bug report. Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5232) Make android include CordovaLib as a library instead of a Jar
[ https://issues.apache.org/jira/browse/CB-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13851781#comment-13851781 ] Mike Billau commented on CB-5232: - Hey [~agrieve], after this change, when users import the project into Eclipse, they are now seeing HelloWorld and HelloWorld-CordovaLibs as options to import. Both need to be imported into Eclipse in order to resolve the Eclipse dependencies. We should add a note about this here: http://cordova.apache.org/docs/en/3.3.0/guide_platforms_android_index.md.html#Android%20Platform%20Guide I think that's the only place that needs the update. Make android include CordovaLib as a library instead of a Jar - Key: CB-5232 URL: https://issues.apache.org/jira/browse/CB-5232 Project: Apache Cordova Issue Type: Bug Components: Android Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Motivation: -Works better in IntelliJ -Faster project creation -Consistent with iOS approach -Allows users to step into framework code when debugging Proof of concept is checked in at cordova-android's libproject branch. Let's wait until the 3.2.0 branch is created before merging. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CB-5232) Make android include CordovaLib as a library instead of a Jar
[ https://issues.apache.org/jira/browse/CB-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13851823#comment-13851823 ] Mike Billau commented on CB-5232: - https://github.com/apache/cordova-docs/pull/166 Make android include CordovaLib as a library instead of a Jar - Key: CB-5232 URL: https://issues.apache.org/jira/browse/CB-5232 Project: Apache Cordova Issue Type: Bug Components: Android Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Motivation: -Works better in IntelliJ -Faster project creation -Consistent with iOS approach -Allows users to step into framework code when debugging Proof of concept is checked in at cordova-android's libproject branch. Let's wait until the 3.2.0 branch is created before merging. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CB-5665) Document the need for xcopy on path
Mike Billau created CB-5665: --- Summary: Document the need for xcopy on path Key: CB-5665 URL: https://issues.apache.org/jira/browse/CB-5665 Project: Apache Cordova Issue Type: Bug Components: Android, Docs Environment: Windows Reporter: Mike Billau Priority: Minor Fix For: 3.4.0 On Windows, you need to have xcopy on the path when trying to build Android, otherwise it will fail. I think this maybe started when we switched to q.js See: https://issues.apache.org/jira/browse/CB-4074 and http://stackoverflow.com/questions/20616893/an-error-occured-during-creation-of-android-sub-project/20640450 If it is necessary only when you use the CLI, we can just add a note in the CLI documentation. If it is necessary regardless of which workflow you use, then I think it should be in check_reqs with a log message on the terminal to Make sure xcopy is on your path. It's probably a Windows-specific thing, no? -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13850761#comment-13850761 ] Mike Billau commented on CB-5398: - Still broken in 4.4.2. Should we file a bug against Android since this is a URI encoding bug and pretty different than the one posted earlier in the thread? Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841314#comment-13841314 ] Mike Billau commented on CB-5398: - I'm going to add a note under Android Quirks for getPicture() documenting this quirk for 4.4 and linking out to the stackoverflow post above as possible solutions. Sound good? When we resolve this we can remove the quirk in the documentation. Thanks guys for looking at this. Sorry I don't have anything to add yet but want to do more investigation today. Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841440#comment-13841440 ] Mike Billau commented on CB-5398: - Pull request for the quick here: https://github.com/apache/cordova-docs/pull/163 Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839282#comment-13839282 ] Mike Billau commented on CB-5398: - I followed the suggestion here to force it to always open the Gallery app and that seemed to work as a temporary solution: http://stackoverflow.com/a/20177611/368762 [~agrieve], [~bowserj], what are the conditions for a ticket to be a blocker? This has workarounds but I don't think we should release a 3.3 to fix android 4.4 issues without resolving this. I didn't see CB-2432, thanks for pointing that out. Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5488) deviceready event not firing with jQuery Mobile
[ https://issues.apache.org/jira/browse/CB-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836674#comment-13836674 ] Mike Billau commented on CB-5488: - [~shazron], what order are the scripts tags in in the built application? I have seen this issue come up a few times on StackOverflow and iirc the problem always seems to be with putting jquery script tag first, before the cordova script. Do you have any idea why that would be? I will look into it this week - I don't think that the script tag order should matter, but if it does, we at least need to document it (and worst case, edit the shell scripts to make sure cordova tag is always first.) deviceready event not firing with jQuery Mobile --- Key: CB-5488 URL: https://issues.apache.org/jira/browse/CB-5488 Project: Apache Cordova Issue Type: Bug Affects Versions: 3.1.0 Reporter: Federico Kereki If you use PhoneGap + jQuery + jQuery Mobile, the deviceready event doesn't fire. Googling around, I found several similar reports, all pointing out that if jQuery Mobile isn't included, the event fires. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5469) Document how to run npm without sudo
Mike Billau created CB-5469: --- Summary: Document how to run npm without sudo Key: CB-5469 URL: https://issues.apache.org/jira/browse/CB-5469 Project: Apache Cordova Issue Type: Bug Components: Docs Reporter: Mike Billau Assignee: Mike Billau Priority: Minor Fix For: 3.2.0 We ask users to install npm globally. Whether or not we are going to continue to suggest this is a different debate, but in the mean time we should talk about how they can set up npm to run without requiring sudo/Administrator. There is a wiki page here that talks about it: https://wiki.apache.org/cordova/npm_rc We need to build out this wiki page and then link to it in the docs. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13830347#comment-13830347
]
Mike Billau commented on CB-5122:
-
I'm going to close this as it seems done after my first (painful) commit.
I opened up CB-5470 to track adding further details around the pros/cons of
each workflow. We haven't identified all of these issues yet so I'll go around
in the next few weeks and survey our developers and users and fill this
information out. It's not worth holding up this ticket though.
Thanks everyone who helped and contributed to the content!
Document supported workflows
Key: CB-5122
URL: https://issues.apache.org/jira/browse/CB-5122
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 3.1.0
Reporter: Mike Billau
Assignee: Mike Sierra
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin
scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide -- Development Paths section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it
clear that there are two distinct workflows, and that both are okay and
supported. It could list out some pros and cons of each workflow (I'm sure we
won't have any trouble finding those ;)). It should be prescriptive in that
users should be following one of the two workflows, but it shouldn't make any
statements about which is better.
{{The Command-line Interface guide}} -- The CLI workflow guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides -- (Platform) -- (Platform) Command-line tools}} -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these
guides and verify that they are up to date and include all of the lower level
command line tools and scripts. It should read like a tutorial in the same
way that the Command-line Interface guide does.
{{Using Plugman to Manage Plugins}} First, this guide needs to get exposed;
I can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2]
http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5427) InAppBrowser crashes without loadstop or loaderror on Android 4.4
[
https://issues.apache.org/jira/browse/CB-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13826667#comment-13826667
]
Mike Billau commented on CB-5427:
-
Originally I reported this while testing on an actual build on a new Nexus 5
phone.
I just installed the 4.4 ROM (NAKASI-KRT16o) on my Nexus 7 and am getting both
errors.
1) Sometimes you see Alert: Unexpected: browser closed without a loadstop or
loadstart error. I can reproduce it almost every time now by 1) open a page
in InAppBrowser, 2) hit back 3) open a page in CordovaWebView 4) see dialog.
Sometimes it will work fine but following this pattern triggers the error
pretty consistently on both of my devices.
If you dismiss the alert, the app seems fine, there isn't a nasty stack trace
or anything. This occurs on both Nexus 5 and Nexus 7, both running the latest
Android 4.4 (from Google.) It seems to happen slightly more consistently on
the Nexus 5 phone.
2) If you do not hit okay when the alert pops up and let it wait, eventually
you will get a {noformat}
11-19 11:38:41.867: E/CordovaWebView(7121): CordovaWebView: TIMEOUT
ERROR!{noformat}
error, a dialog about not being able to connect to the server, that nasty stack
trace above about the window leaked. The app will force quit (but still say
in the app list..?) and if you launch the app again (either from the launcher
or from the recently used/running apps screen) the webview will stay black and
nothing happens until you quit the app and restart. (Cordova seems present when
this black screen is here because you can see {noformat}11-19 11:43:23.997:
I/CordovaLog(7665): Found start page location: index.html
11-19 11:43:23.997: I/CordovaLog(7665): Changing log level to DEBUG(3)
11-19 11:43:24.007: D/CordovaActivity(7665): CordovaActivity.onCreate()
11-19 11:43:24.017: D/CordovaWebView(7665): CordovaWebView is running on device
made by: asus
11-19 11:43:24.027: D/JsMessageQueue(7665): Set native-JS mode to 2
11-19 11:43:24.027: D/CordovaActivity(7665): CordovaActivity.init()
11-19 11:43:24.037: D/CordovaWebView(7665):
loadUrl(file:///android_asset/www/index.html)
11-19 11:43:24.037: D/PluginManager(7665): init()
11-19 11:43:24.057: D/CordovaWebView(7665): loadUrlNow()
{noformat}
I think we can probably ignore this second error for now since it's hard to
tell if that is being caused by the first error or not.
InAppBrowser crashes without loadstop or loaderror on Android 4.4
-
Key: CB-5427
URL: https://issues.apache.org/jira/browse/CB-5427
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin InAppBrowser
Affects Versions: 3.2.0
Environment: Windows 7
Android 4.x
Reporter: Mike Billau
InAppBrowser on Android 4.4 sometimes fails when you click to open any page
on the CordovaWebView. An alert will pop up saying Unexpected: Browser
closed without a loadstop or loaderror. Closing the dialog will force quit
the application. I can't detect a pattern to reproduce the issue; what I do
is just keep running through the first few buttons under Local URL and White
Listed URL headings on the mobile spec page. Other people seem to be having
this issue too: https://groups.google.com/forum/#!topic/phonegap/e5_5unC2fYs
In logcat I'm seeing:
{noformat}
11-18 11:50:07.648: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={type:loadstop,url:http://www.google.com/}
11-18 11:50:07.648: I/chromium(6369): [INFO:CONSOLE(79)] IAB
event={type:loadstop,url:http://www.google.com/};, source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:07.928: W/UnimplementedWebViewApi(6369): Unimplemented WebView
method onKeyDown called from:
android.webkit.WebView.onKeyDown(WebView.java:2169)
11-18 11:50:07.968: W/InputEventReceiver(6369): Attempted to finish an input
event but the input event receiver has already been disposed.
11-18 11:50:07.998: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={type:exit}
11-18 11:50:07.998: I/chromium(6369): [INFO:CONSOLE(79)] IAB
event={type:exit}, source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:09.408: D/InAppBrowser(6369): target = _self
11-18 11:50:09.418: D/InAppBrowser(6369): in self
11-18 11:50:09.418: D/CordovaWebView(6369): loadUrl(http://www.apple.com/)
11-18 11:50:09.418: D/PluginManager(6369): init()
11-18 11:50:09.428: D/CordovaWebView(6369): loadUrlNow()
11-18 11:50:09.428: W/CordovaPlugin(6369): Attempted to send a second
callback for ID: InAppBrowser921848427
11-18 11:50:09.428: W/CordovaPlugin(6369): Result was:
11-18 11:50:09.488: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 :
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13826678#comment-13826678 ] Mike Billau commented on CB-5398: - 2012 Nexus 7 running KitKat installed from https://developers.google.com/android/nexus/images#nakasikrt16o Seeing the same thing as [~jcesarmobile] 1. everything works when destinationType = DATA_URL 2. With destinationType = FILE_URI, I can get images from Downloads, but any other file picker will return to the app but the image does not appear. 3. With destinationType = FILE_URI, I can successfully access any image if I go through the Gallery app first 4. I get the same logcat message (posted above) whenever it unsuccessfully returns to mobilespec after trying to get a picture from Recent, Drive, Images, or External Storage. Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13826937#comment-13826937 ] Mike Billau commented on CB-5294: - [~agrieve], it doesn't look like they are paying attention to the android issues list above. Are you seeing this getting more attention somewhere else? I'd just like to follow the progress. File input element not opening file picker in Android 4.4 - Key: CB-5294 URL: https://issues.apache.org/jira/browse/CB-5294 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.1.0 Environment: Android 4.4 (emulator and Nexus 5) Reporter: Paul Kane Assignee: Joe Bowser The file input field doesn't respond when clicked/tapped in Android 4.4. Works fine in previous Android versions. This is regardless of whether the Target Level is set to 18 or 19. To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only modification I made to the default (placeholder) index.html file was adding a form element with a single input type=file element inside. Clicking the Choose File button does nothing. No Logcat output or errors. Normally at this point a dialogue would open allowing me to select an image from the gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5427) InAppBrowser crashes without loadstop or loaderror on Android 4.4
Mike Billau created CB-5427:
---
Summary: InAppBrowser crashes without loadstop or loaderror on
Android 4.4
Key: CB-5427
URL: https://issues.apache.org/jira/browse/CB-5427
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin InAppBrowser
Affects Versions: 3.2.0
Environment: Windows 7
Android 4.4
Reporter: Mike Billau
InAppBrowser on Android 4.4 sometimes fails when you click to open any page on
the CordovaWebView. An alert will pop up saying Unexpected: Browser closed
without a loadstop or loaderror. Closing the dialog will force quit the
application. I can't detect a pattern to reproduce the issue; what I do is just
keep running through the first few buttons under Local URL and White Listed URL
headings on the mobile spec page. Other people seem to be having this issue
too: https://groups.google.com/forum/#!topic/phonegap/e5_5unC2fYs
In logcat I'm seeing:
{noformat}
11-18 11:50:07.648: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={type:loadstop,url:http://www.google.com/}
11-18 11:50:07.648: I/chromium(6369): [INFO:CONSOLE(79)] IAB
event={type:loadstop,url:http://www.google.com/};, source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:07.928: W/UnimplementedWebViewApi(6369): Unimplemented WebView
method onKeyDown called from:
android.webkit.WebView.onKeyDown(WebView.java:2169)
11-18 11:50:07.968: W/InputEventReceiver(6369): Attempted to finish an input
event but the input event receiver has already been disposed.
11-18 11:50:07.998: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={type:exit}
11-18 11:50:07.998: I/chromium(6369): [INFO:CONSOLE(79)] IAB
event={type:exit}, source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:09.408: D/InAppBrowser(6369): target = _self
11-18 11:50:09.418: D/InAppBrowser(6369): in self
11-18 11:50:09.418: D/CordovaWebView(6369): loadUrl(http://www.apple.com/)
11-18 11:50:09.418: D/PluginManager(6369): init()
11-18 11:50:09.428: D/CordovaWebView(6369): loadUrlNow()
11-18 11:50:09.428: W/CordovaPlugin(6369): Attempted to send a second callback
for ID: InAppBrowser921848427
11-18 11:50:09.428: W/CordovaPlugin(6369): Result was:
11-18 11:50:09.488: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={type:exit}
11-18 11:50:09.488: I/chromium(6369): [INFO:CONSOLE(79)] IAB
event={type:exit}, source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:09.508: D/dalvikvm(6369): GC_FOR_ALLOC freed 50K, 3% free
18380K/18836K, paused 8ms, total 8ms
11-18 11:50:09.508: I/dalvikvm-heap(6369): Grow heap (frag case) to 18.584MB
for 629776-byte allocation
11-18 11:50:09.528: D/dalvikvm(6369): GC_FOR_ALLOC freed 7K, 3% free
18988K/19452K, paused 12ms, total 12ms
11-18 11:50:09.578: D/dalvikvm(1108): GC_CONCURRENT freed 448K, 9% free
17309K/18816K, paused 2ms+1ms, total 23ms
11-18 11:50:09.638: D/dalvikvm(744): GC_CONCURRENT freed 2582K, 29% free
27397K/38100K, paused 3ms+4ms, total 76ms
11-18 11:50:29.428: E/CordovaWebView(6369): CordovaWebView: TIMEOUT ERROR!
11-18 11:50:29.428: D/CordovaWebViewClient(6369):
CordovaWebViewClient.onReceivedError: Error code=-6 Description=The connection
to the server was unsuccessful. URL=http://www.apple.com/
11-18 11:50:29.428: D/CordovaActivity(6369):
onMessage(onReceivedError,{errorCode:-6,url:http:\/\/www.apple.com\/,description:The
connection to the server was unsuccessful.})
11-18 11:50:29.458: D/SoftKeyboardDetect(6369): Ignore this event
11-18 11:50:29.558: D/CordovaWebViewClient(6369):
onPageFinished(http://www.apple.com/)
11-18 11:50:29.558: D/CordovaActivity(6369):
onMessage(onPageFinished,http://www.apple.com/)
11-18 11:50:56.078: D/audio_hw_primary(184): select_devices: out_snd_device(2:
speaker) in_snd_device(0: )
11-18 11:50:56.098: D/CordovaActivity(6369): Paused the application!
11-18 11:50:56.128: W/IInputConnectionWrapper(6369): showStatusIcon on inactive
InputConnection
11-18 11:50:56.598: D/CordovaActivity(6369): CordovaActivity.onDestroy()
11-18 11:50:56.598: D/CordovaWebView(6369): loadUrlNow()
11-18 11:50:56.678: E/WindowManager(6369): android.view.WindowLeaked: Activity
org.apache.mobilespec.mobilespec has leaked window
com.android.internal.policy.impl.PhoneWindow$DecorView{42686118 V.E.
R... 0,0-1080,638} that was originally added here
11-18 11:50:56.678: E/WindowManager(6369): at
android.view.ViewRootImpl.init(ViewRootImpl.java:346)
11-18 11:50:56.678: E/WindowManager(6369): at
android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:248)
11-18 11:50:56.678: E/WindowManager(6369): at
android.view.WindowManagerImpl.addView(WindowManagerImpl.java:69)
11-18 11:50:56.678: E/WindowManager(6369): at
[jira] [Updated] (CB-5427) InAppBrowser crashes without loadstop or loaderror on Android 4.4
[
https://issues.apache.org/jira/browse/CB-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5427:
Environment:
Windows 7
Android 4.x
was:
Windows 7
Android 4.4
InAppBrowser crashes without loadstop or loaderror on Android 4.4
-
Key: CB-5427
URL: https://issues.apache.org/jira/browse/CB-5427
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin InAppBrowser
Affects Versions: 3.2.0
Environment: Windows 7
Android 4.x
Reporter: Mike Billau
InAppBrowser on Android 4.4 sometimes fails when you click to open any page
on the CordovaWebView. An alert will pop up saying Unexpected: Browser
closed without a loadstop or loaderror. Closing the dialog will force quit
the application. I can't detect a pattern to reproduce the issue; what I do
is just keep running through the first few buttons under Local URL and White
Listed URL headings on the mobile spec page. Other people seem to be having
this issue too: https://groups.google.com/forum/#!topic/phonegap/e5_5unC2fYs
In logcat I'm seeing:
{noformat}
11-18 11:50:07.648: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={type:loadstop,url:http://www.google.com/}
11-18 11:50:07.648: I/chromium(6369): [INFO:CONSOLE(79)] IAB
event={type:loadstop,url:http://www.google.com/};, source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:07.928: W/UnimplementedWebViewApi(6369): Unimplemented WebView
method onKeyDown called from:
android.webkit.WebView.onKeyDown(WebView.java:2169)
11-18 11:50:07.968: W/InputEventReceiver(6369): Attempted to finish an input
event but the input event receiver has already been disposed.
11-18 11:50:07.998: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={type:exit}
11-18 11:50:07.998: I/chromium(6369): [INFO:CONSOLE(79)] IAB
event={type:exit}, source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:09.408: D/InAppBrowser(6369): target = _self
11-18 11:50:09.418: D/InAppBrowser(6369): in self
11-18 11:50:09.418: D/CordovaWebView(6369): loadUrl(http://www.apple.com/)
11-18 11:50:09.418: D/PluginManager(6369): init()
11-18 11:50:09.428: D/CordovaWebView(6369): loadUrlNow()
11-18 11:50:09.428: W/CordovaPlugin(6369): Attempted to send a second
callback for ID: InAppBrowser921848427
11-18 11:50:09.428: W/CordovaPlugin(6369): Result was:
11-18 11:50:09.488: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={type:exit}
11-18 11:50:09.488: I/chromium(6369): [INFO:CONSOLE(79)] IAB
event={type:exit}, source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:09.508: D/dalvikvm(6369): GC_FOR_ALLOC freed 50K, 3% free
18380K/18836K, paused 8ms, total 8ms
11-18 11:50:09.508: I/dalvikvm-heap(6369): Grow heap (frag case) to 18.584MB
for 629776-byte allocation
11-18 11:50:09.528: D/dalvikvm(6369): GC_FOR_ALLOC freed 7K, 3% free
18988K/19452K, paused 12ms, total 12ms
11-18 11:50:09.578: D/dalvikvm(1108): GC_CONCURRENT freed 448K, 9% free
17309K/18816K, paused 2ms+1ms, total 23ms
11-18 11:50:09.638: D/dalvikvm(744): GC_CONCURRENT freed 2582K, 29% free
27397K/38100K, paused 3ms+4ms, total 76ms
11-18 11:50:29.428: E/CordovaWebView(6369): CordovaWebView: TIMEOUT ERROR!
11-18 11:50:29.428: D/CordovaWebViewClient(6369):
CordovaWebViewClient.onReceivedError: Error code=-6 Description=The
connection to the server was unsuccessful. URL=http://www.apple.com/
11-18 11:50:29.428: D/CordovaActivity(6369):
onMessage(onReceivedError,{errorCode:-6,url:http:\/\/www.apple.com\/,description:The
connection to the server was unsuccessful.})
11-18 11:50:29.458: D/SoftKeyboardDetect(6369): Ignore this event
11-18 11:50:29.558: D/CordovaWebViewClient(6369):
onPageFinished(http://www.apple.com/)
11-18 11:50:29.558: D/CordovaActivity(6369):
onMessage(onPageFinished,http://www.apple.com/)
11-18 11:50:56.078: D/audio_hw_primary(184): select_devices:
out_snd_device(2: speaker) in_snd_device(0: )
11-18 11:50:56.098: D/CordovaActivity(6369): Paused the application!
11-18 11:50:56.128: W/IInputConnectionWrapper(6369): showStatusIcon on
inactive InputConnection
11-18 11:50:56.598: D/CordovaActivity(6369): CordovaActivity.onDestroy()
11-18 11:50:56.598: D/CordovaWebView(6369): loadUrlNow()
11-18 11:50:56.678: E/WindowManager(6369): android.view.WindowLeaked:
Activity org.apache.mobilespec.mobilespec has leaked window
com.android.internal.policy.impl.PhoneWindow$DecorView{42686118 V.E.
R... 0,0-1080,638} that was originally added here
11-18 11:50:56.678: E/WindowManager(6369):at
android.view.ViewRootImpl.init(ViewRootImpl.java:346)
[jira] [Updated] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau updated CB-5398: Affects Version/s: 3.2.0 Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau reassigned CB-5398: --- Assignee: Mike Billau Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5372) Notification.beep blocks app execution - doesn't use CordovaInterface.getThreadPool
[
https://issues.apache.org/jira/browse/CB-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823821#comment-13823821
]
Mike Billau commented on CB-5372:
-
I think that the beep has always blocked the UI...I think this is more of a
feature request and not a bug caused by not using a thread pool.
Notification.beep blocks app execution - doesn't use
CordovaInterface.getThreadPool
---
Key: CB-5372
URL: https://issues.apache.org/jira/browse/CB-5372
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 3.1.0
Reporter: Michael Schmidt
Priority: Blocker
Calling a simple beep notification for 5 seconds blocks the whole app for
this time
{quote}
navigator.notification.beep(5);
{quote}
Debug console output is as follows:
{quote}
11-13 12:07:09.845: W/PluginManager(14561): THREAD WARNING: exec() call to
Notification.beep blocked the main thread for 10507ms. Plugin should use
CordovaInterface.getThreadPool().
{quote}
App runs on Android 4.1
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[
https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13823835#comment-13823835
]
Mike Billau commented on CB-5398:
-
This exists on 3.x as well.
In the mean time a workaround is to go through the Gallery app.
So when it says Recent, Drive, Images, and Downloads, at the bottom of
that list will be Gallery. As far as I can tell this opens up the Gallery app
and then you can navigate through those folders and select any of the photos.
I'm getting this in LOGCAT:
{noformat}
11-15 12:16:24.017: D/CordovaActivity(7351): Incoming Result
11-15 12:16:24.017: D/CordovaActivity(7351): Request code = 50
11-15 12:16:24.017: D/CordovaActivity(7351): We have a callback to send this
result to
11-15 12:16:24.037: D/dalvikvm(7351): GC_FOR_ALLOC freed 34K, 3% free
16572K/17084K, paused 8ms, total 8ms
11-15 12:16:24.057: I/dalvikvm-heap(7351): Grow heap (frag case) to 46.700MB
for 31961104-byte allocation
11-15 12:16:24.067: D/dalvikvm(7351): GC_FOR_ALLOC freed 1K, 2% free
47783K/48300K, paused 9ms, total 9ms
11-15 12:16:24.227: E/DatabaseUtils(4667): Writing exception to parcel
11-15 12:16:24.227: E/DatabaseUtils(4667): java.lang.SecurityException:
Permission Denial: reading com.android.providers.media.MediaDocumentsProvider
uri content://com.android.providers.media.documents/document/image:59 from
pid=7351, uid=10083 requires android.permission.MANAGE_DOCUMENTS, or
grantUriPermission()
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.content.ContentProvider$Transport.enforceReadPermissionInner(ContentProvider.java:457)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:394)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.content.ContentProvider$Transport.enforceFilePermission(ContentProvider.java:387)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.content.ContentProvider$Transport.openTypedAssetFile(ContentProvider.java:339)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.content.ContentProviderNative.onTransact(ContentProviderNative.java:305)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.os.Binder.execTransact(Binder.java:404)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
dalvik.system.NativeStart.run(Native Method)
11-15 12:16:24.237: E/AndroidProtocolHandler(7351): Unable to open content URL:
content://com.android.providers.media.documents/document/image%3A59
11-15 12:16:24.247: D/dalvikvm(7351): GC_EXPLICIT freed 31233K, 4% free
16554K/17084K, paused 2ms+2ms, total 25ms
11-15 12:16:24.247: D/Whitelist(7351): Unlimited access to network resources
11-15 12:16:24.247: I/CordovaLog(7351): Found start page location: index.html
11-15 12:16:24.247: I/CordovaLog(7351): Changing log level to DEBUG(3)
11-15 12:16:24.247: D/CordovaActivity(7351): Resuming the App
11-15 12:16:24.247: D/CordovaActivity(7351): CB-3064: The errorUrl is null
11-15 12:16:24.247: D/CordovaLog(7351):
file:///android_asset/www/camera/index.html: Line 58 : URL:
content://com.android.providers.media.documents/document/image%3A59
11-15 12:16:24.247: I/chromium(7351): [INFO:CONSOLE(58)] URL:
content://com.android.providers.media.documents/document/image%3A59, source:
file:///android_asset/www/camera/index.html (58)
{noformat}
Looks like there is a new permission: MANAGE_DOCUMENTS:
http://developer.android.com/reference/android/Manifest.permission.html#MANAGE_DOCUMENTS
I tried to add {{android.permission.MANAGE_DOCUMENTS}} to the
AndroidManifest.xml but even after doing this, compiling with ADB and
installing, I'm still getting the above error and still unable to pick any
photos unless I go through the Gallery app first. I made sure to set
targetSDK=19 which is when this new permission was added.
[~bowserj] do you have any ideas on why Android wouldn't be picking up the new
permission? Is the problem in {{DatabaseUtils}} that I assume is some Android
app?
Pick image from Library or Photo album on android 4.4
-
Key: CB-5398
URL: https://issues.apache.org/jira/browse/CB-5398
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Camera
Affects Versions: 2.9.0, 3.2.0
Environment: android 4.4
Reporter: julio cesar
Assignee: Mike Billau
An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or
pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI.
Now android 4.4, when you select the above options, it opens an open from
dialog that let you choose from new places as Recent, Drive, Images
and Downloads (the names might not be the same as I use the device in
spanish and translated it).
If you choose any of them, you get an error, AndroidProtocolHandler,
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13824028#comment-13824028 ] Mike Billau commented on CB-5398: - On Android 4.4, with Cordova 3.x, it looks like the app just doesn't get the image. However, on Cordova 2.x, the app actually will force quit. Pick image from Library or Photo album on android 4.4 - Key: CB-5398 URL: https://issues.apache.org/jira/browse/CB-5398 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 2.9.0, 3.2.0 Environment: android 4.4 Reporter: julio cesar Assignee: Mike Billau An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. Now android 4.4, when you select the above options, it opens an open from dialog that let you choose from new places as Recent, Drive, Images and Downloads (the names might not be the same as I use the device in spanish and translated it). If you choose any of them, you get an error, AndroidProtocolHandler, unable to open content URL: the url here with a content://com.android.providers format. I've tested on phonegap 2.9 because this is the version I use, but I suppose it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5414) 2.x InAppBrowser localUrls fail on Android 4.4
Mike Billau created CB-5414: --- Summary: 2.x InAppBrowser localUrls fail on Android 4.4 Key: CB-5414 URL: https://issues.apache.org/jira/browse/CB-5414 Project: Apache Cordova Issue Type: Bug Components: Plugin InAppBrowser Affects Versions: 2.9.0, 2.6.0, 2.3.0 Reporter: Mike Billau Priority: Minor For Cordova 2.x stream, InAppBrowser is not able to open Local URL links on Android 4.4 I think that it has to do with: http://developer.android.com/guide/webapps/migrating.html#URLs Apparently this is not covered by Quirks Mode because setting targetSDK=18 or targetSDK=19 doesn't make a difference. Tested with 2.x mobile spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CB-5414) 2.x InAppBrowser localUrls fail on Android 4.4
[ https://issues.apache.org/jira/browse/CB-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau updated CB-5414: Affects Version/s: (was: 2.9.0) 2.x InAppBrowser localUrls fail on Android 4.4 --- Key: CB-5414 URL: https://issues.apache.org/jira/browse/CB-5414 Project: Apache Cordova Issue Type: Bug Components: Plugin InAppBrowser Affects Versions: 2.3.0, 2.6.0 Reporter: Mike Billau Priority: Minor For Cordova 2.x stream, InAppBrowser is not able to open Local URL links on Android 4.4 I think that it has to do with: http://developer.android.com/guide/webapps/migrating.html#URLs Apparently this is not covered by Quirks Mode because setting targetSDK=18 or targetSDK=19 doesn't make a difference. Tested with 2.x mobile spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5414) 2.x InAppBrowser localUrls fail on Android 4.4
[ https://issues.apache.org/jira/browse/CB-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13824058#comment-13824058 ] Mike Billau commented on CB-5414: - Just tested with the latest 2.9.1 and this works fine. 2.x InAppBrowser localUrls fail on Android 4.4 --- Key: CB-5414 URL: https://issues.apache.org/jira/browse/CB-5414 Project: Apache Cordova Issue Type: Bug Components: Plugin InAppBrowser Affects Versions: 2.3.0, 2.6.0 Reporter: Mike Billau Priority: Minor For Cordova 2.x stream, InAppBrowser is not able to open Local URL links on Android 4.4 I think that it has to do with: http://developer.android.com/guide/webapps/migrating.html#URLs Apparently this is not covered by Quirks Mode because setting targetSDK=18 or targetSDK=19 doesn't make a difference. Tested with 2.x mobile spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau updated CB-5294: Component/s: Plugin File Android File input element not opening file picker in Android 4.4 - Key: CB-5294 URL: https://issues.apache.org/jira/browse/CB-5294 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin File Affects Versions: 3.1.0 Environment: Android 4.4 (emulator and Nexus 5) Reporter: Paul Kane Assignee: Joe Bowser Priority: Blocker The file input field doesn't respond when clicked/tapped in Android 4.4. Works fine in previous Android versions. This is regardless of whether the Target Level is set to 18 or 19. To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only modification I made to the default (placeholder) index.html file was adding a form element with a single input type=file element inside. Clicking the Choose File button does nothing. No Logcat output or errors. Normally at this point a dialogue would open allowing me to select an image from the gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau updated CB-5294: Assignee: Joe Bowser File input element not opening file picker in Android 4.4 - Key: CB-5294 URL: https://issues.apache.org/jira/browse/CB-5294 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin File Affects Versions: 3.1.0 Environment: Android 4.4 (emulator and Nexus 5) Reporter: Paul Kane Assignee: Joe Bowser Priority: Blocker The file input field doesn't respond when clicked/tapped in Android 4.4. Works fine in previous Android versions. This is regardless of whether the Target Level is set to 18 or 19. To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only modification I made to the default (placeholder) index.html file was adding a form element with a single input type=file element inside. Clicking the Choose File button does nothing. No Logcat output or errors. Normally at this point a dialogue would open allowing me to select an image from the gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau updated CB-5294: Component/s: (was: Plugin File) File input element not opening file picker in Android 4.4 - Key: CB-5294 URL: https://issues.apache.org/jira/browse/CB-5294 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.1.0 Environment: Android 4.4 (emulator and Nexus 5) Reporter: Paul Kane Assignee: Joe Bowser Priority: Blocker The file input field doesn't respond when clicked/tapped in Android 4.4. Works fine in previous Android versions. This is regardless of whether the Target Level is set to 18 or 19. To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only modification I made to the default (placeholder) index.html file was adding a form element with a single input type=file element inside. Clicking the Choose File button does nothing. No Logcat output or errors. Normally at this point a dialogue would open allowing me to select an image from the gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5339) iOS progress indicator
Mike Billau created CB-5339: --- Summary: iOS progress indicator Key: CB-5339 URL: https://issues.apache.org/jira/browse/CB-5339 Project: Apache Cordova Issue Type: New Feature Components: Plugin Dialogs Environment: iOS Reporter: Mike Billau Priority: Minor iOS should have a progress indicator. Android has a hidden progress indicator API: https://github.com/apache/cordova-plugin-dialogs/blob/master/www/android/notification.js#L47 If we build one for iOS then we can expose both API's in the docs. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819099#comment-13819099
]
Mike Billau commented on CB-5122:
-
So far I see the #1 use case for the shell-tool workflow is when mixing
WebViews with native components, applicable only to Android iOS. No
decision; it's simply not possible with the CLI.
Agreed.
Other advantages of using the Android SDK are:
- easier logging (Eclipse's logcat is much nicer than adb logcat),
- easier debugging (you could attach Eclipse debugger to your app - we'd need
to write instructions on this),
- some people may have set up their SDK for web dev
- developing plugins
- if only making an Android app, it might be easier conceptually
I'm having trouble thinking of other uses and use cases for native platform dev
workflow. Maybe [~shazron] and [~bowserj] have comments since I'm pretty sure
they don't use the CLI.
I tried to set up a separate platform Installation and shell Development
guides for Android, but it resulted in a lot of redundant or fragmented
content, e.g., regarding emulator setup, connecting the device, etc. As an
alternative, I worked the info about shell tools into the existing
Installation content and renamed the result back to a single Platform
Guide. I think this approach is a much better way to clarify the overall
shell workflow, but let me know if you disagree. If not, we can use Android
for guidance fold in the shell-tool content for other platforms.
SGTM. Lemme know how I can help.
Document supported workflows
Key: CB-5122
URL: https://issues.apache.org/jira/browse/CB-5122
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 3.1.0
Reporter: Mike Billau
Assignee: Mike Sierra
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin
scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide -- Development Paths section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it
clear that there are two distinct workflows, and that both are okay and
supported. It could list out some pros and cons of each workflow (I'm sure we
won't have any trouble finding those ;)). It should be prescriptive in that
users should be following one of the two workflows, but it shouldn't make any
statements about which is better.
{{The Command-line Interface guide}} -- The CLI workflow guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides -- (Platform) -- (Platform) Command-line tools}} -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these
guides and verify that they are up to date and include all of the lower level
command line tools and scripts. It should read like a tutorial in the same
way that the Command-line Interface guide does.
{{Using Plugman to Manage Plugins}} First, this guide needs to get exposed;
I can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2]
http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CB-5300) Clarify steps and expectations for manual tests
Mike Billau created CB-5300: --- Summary: Clarify steps and expectations for manual tests Key: CB-5300 URL: https://issues.apache.org/jira/browse/CB-5300 Project: Apache Cordova Issue Type: Bug Components: mobile-spec, Plugin InAppBrowser, Plugin Media Capture Reporter: Mike Billau Priority: Minor Some of the manual test pages are pretty confusing and it's not clear what steps should be taken to perform the tests or what the expectations should be. Part of this content is explained on http://wiki.apache.org/cordova/RunningTests but this page is missing data for InAppBrowser and MediaCapture (and possibly others.) Additionally, this wiki page is not very well known. The manual tests should either link to this wiki page or the test pages should include these steps directly in their HTML. This may require a separate jira item. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813281#comment-13813281
]
Mike Billau commented on CB-5122:
-
Sure [~sierra] feel free. I'm going to take another pass over the Overview,
Plugman, and CLI sections tomorrow (found a few undocumented CLI commands) and
then hopefully we can mark those ones as finished. Then I can help you or find
another task - anything in particular you could use extra help on?
Document supported workflows
Key: CB-5122
URL: https://issues.apache.org/jira/browse/CB-5122
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 3.1.0
Reporter: Mike Billau
Assignee: Mike Sierra
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin
scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide -- Development Paths section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it
clear that there are two distinct workflows, and that both are okay and
supported. It could list out some pros and cons of each workflow (I'm sure we
won't have any trouble finding those ;)). It should be prescriptive in that
users should be following one of the two workflows, but it shouldn't make any
statements about which is better.
{{The Command-line Interface guide}} -- The CLI workflow guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides -- (Platform) -- (Platform) Command-line tools}} -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these
guides and verify that they are up to date and include all of the lower level
command line tools and scripts. It should read like a tutorial in the same
way that the Command-line Interface guide does.
{{Using Plugman to Manage Plugins}} First, this guide needs to get exposed;
I can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2]
http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-3962) document and implement editorial guidelines
[ https://issues.apache.org/jira/browse/CB-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13811205#comment-13811205 ] Mike Billau commented on CB-3962: - One trivial question I had - one or two spaces after a period? document and implement editorial guidelines --- Key: CB-3962 URL: https://issues.apache.org/jira/browse/CB-3962 Project: Apache Cordova Issue Type: Task Components: Docs Reporter: Mike Sierra Assignee: Mike Sierra Priority: Critical The top-level STYLESHEET.md file collects editorial guidelines to help standardize the doc. Keep updating to reflect any site-side conventions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CB-5034) Document plugin registry
[ https://issues.apache.org/jira/browse/CB-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau reassigned CB-5034: --- Assignee: Mike Sierra (was: Mike Billau) Document plugin registry Key: CB-5034 URL: https://issues.apache.org/jira/browse/CB-5034 Project: Apache Cordova Issue Type: Bug Components: Docs, Registry Affects Versions: Master Reporter: Mike Billau Assignee: Mike Sierra I can't find any reference to the plugin registry anywhere in our documentation. Am I looking in the wrong place or are we waiting for the web component to be more polished before announcing the registry? I think some places the registry should be mentioned: Plugman: readme.md CLI: cordova help command (CB-5031) readme.md docs: http://cordova.apache.org/docs/en/edge/guide_cli_index.md.html#The%20Command-line%20Interface (I think it's best to split the Add Platforms section into Add Platforms and Add Plugins, and in this new section talk about adding plugins, automatic plugin installation (plugin dependencies), and the registry) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809023#comment-13809023
]
Mike Billau commented on CB-5122:
-
Hi Mike, thanks. I've started the first pass here:
https://github.com/apache/cordova-docs/pull/140
The only summary I have of the trade-offs is that huge thread:
http://callback.markmail.org/thread/5nr7dgkquse4gdkl
I was just going to explain the differences in the workflows at first and
encourage people to learn about both. Maybe later we can add a pros/cons
table that we can expand on as we discover them...the only problem with this is
that one person's pro is another person's con!
Regarding merges information, I reread everything and actually I think you're
right, the merges section on the Guide is pretty complete - I might change the
heading to Customize Each Platform via /merges/ just to make it easier for
people trying to see what that folder is for. However I think that this
highlights a bigger issue: that the README.md files and the various Guides
sometimes have conflicting information. I wanted to create a new JIRA item to
collapse the readme.md's into the guides - what do you think about this?
Document supported workflows
Key: CB-5122
URL: https://issues.apache.org/jira/browse/CB-5122
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 3.1.0
Reporter: Mike Billau
Assignee: Mike Sierra
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin
scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide -- Development Paths section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it
clear that there are two distinct workflows, and that both are okay and
supported. It could list out some pros and cons of each workflow (I'm sure we
won't have any trouble finding those ;)). It should be prescriptive in that
users should be following one of the two workflows, but it shouldn't make any
statements about which is better.
{{The Command-line Interface guide}} -- The CLI workflow guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides -- (Platform) -- (Platform) Command-line tools}} -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these
guides and verify that they are up to date and include all of the lower level
command line tools and scripts. It should read like a tutorial in the same
way that the Command-line Interface guide does.
{{Using Plugman to Manage Plugins}} First, this guide needs to get exposed;
I can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2]
http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CB-3802) General Configuration Guide has incorrect config.xml
[
https://issues.apache.org/jira/browse/CB-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau resolved CB-3802.
-
Resolution: Fixed
I'm pretty sure this can be closed. I went through all of the API's and
verified the docs (for Android) had the correct XML and permissions:
https://issues.apache.org/jira/browse/CB-5005
General Configuration Guide has incorrect config.xml
Key: CB-3802
URL: https://issues.apache.org/jira/browse/CB-3802
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Reporter: Joe Bowser
Assignee: Michael Brooks
The XML format for plugins is wrong. I'm not sure how it works across
platfomrs, but for Android it should be:
{code}
feature name=FeatureName
param name=android-package value=android.class.name /
/feature
{code}
I'm guessing it's similar on iOS, but I want to make sure it's right, which
is why I'm creating the ticket instead of just editing it on the spot.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CB-4390) Android Command-line Tools Section is missing few commands
[ https://issues.apache.org/jira/browse/CB-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau reassigned CB-4390: --- Assignee: Mike Billau (was: Sharif Ahmed) Android Command-line Tools Section is missing few commands -- Key: CB-4390 URL: https://issues.apache.org/jira/browse/CB-4390 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 3.0.0 Reporter: Sharif Ahmed Assignee: Mike Billau Priority: Minor In the Android Command-line Tools Section the following commands documentation are missing: /bin/check_reqs /bin/update [path] /cordova/version The above are present in README but has not been update in the doc. Also, Cleaning font size is smaller than the rest. This also needs a fix. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-4890) Reference to plugins.xml should be config.xml
[
https://issues.apache.org/jira/browse/CB-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809455#comment-13809455
]
Mike Billau commented on CB-4890:
-
Man, somehow this change from plugins.xml to config.xml didn't get put into
edge, 3.1, or 3.0: https://github.com/apache/cordova-docs/pull/142 for this
plugin.
Reference to plugins.xml should be config.xml
-
Key: CB-4890
URL: https://issues.apache.org/jira/browse/CB-4890
Project: Apache Cordova
Issue Type: Improvement
Components: Docs
Affects Versions: 2.9.0
Reporter: Peter
Assignee: Michael Brooks
Priority: Trivial
The Capture API documentation for Android (see Permissions section) is
still referring to plugins.xml instead of config.xml
{quote}
Permissions
Android
app/res/xml/plugins.xml
{quote}
http://cordova.apache.org/docs/en/2.9.0/cordova_media_capture_capture.md.html#Capture
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13809643#comment-13809643
]
Mike Billau commented on CB-5122:
-
bq. Not sure I understand collapse, but if you mean simply copying the
README content into the doc (either one-time or dynamically), then I don't
agree.
The problem with the README.md files is that sometimes there will be duplicated
information in either the README or some guide, such as most of the
cordova-android README.md being duplicated in the Android Platform Guide, or
missing information, such as the registry commands and proxy settings for
cordova-cli being located only in the CLI's README.md.
bq. I suggest we get rid of Platform Guide instead feature a SoAndSo
Installation Guide, applicable to both CLI shell workflows...
I think that we definitely need to revamp the individual Platform Guides and
remove any workflow related information. It should just talk about how to
install the platform SDKs and anything else common to both workflows (getting
signing keys, etc.) It should say something like Now that you have installed
**Platform X** SDK, you can create an app using either _link to CLI guide_ or
_link to plugman guide_
bq. ...then a separate SoAndSo Development Guide detailing the actual shell
workflow, corresponding to the current Command-line Utilities page
If you are suggesting multiple guides for each platform (Android Development
Guide, iOS Development Guide) then I think I agree. The problem will be not
reproducing the plugman documentation. I think we should have a high level
Using Plugman guide that details all of the common pieces of the shell
workflow and plugman API (the missing counterpart to The Command-line
Interface guide). Then we can add any platform-specific steps or information
for this shell workflow in these platform-specific SoAndSo Development Guide
- such as logging capabilities, anything unique in the Command-line Utilities
section, and all of the information about loading a project into an IDE. Then
go back to the Using Plugman guide and insert a bunch of warning and
pointers.
bq. Not sure I agree naming the CLI guide to CLI Workflow, if that's what
you're suggesting. It implies a parallel set of Workflow topics elsewhere.
Agree. I'm not trying to suggest we call it the CLI Workflow, I was just
using that phrase because that's what we were all throwing around on the ML. I
do think that this guide is sorely lacking a parallel doc though, but that will
be rectified when we expand the Using Plugman guide.
Document supported workflows
Key: CB-5122
URL: https://issues.apache.org/jira/browse/CB-5122
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 3.1.0
Reporter: Mike Billau
Assignee: Mike Sierra
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin
scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide -- Development Paths section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it
clear that there are two distinct workflows, and that both are okay and
supported. It could list out some pros and cons of each workflow (I'm sure we
won't have any trouble finding those ;)). It should be prescriptive in that
users should be following one of the two workflows, but it shouldn't make any
statements about which is better.
{{The Command-line Interface guide}} -- The CLI workflow guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides -- (Platform) -- (Platform) Command-line tools}} -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these
guides and verify that they are up to date and include all of the lower level
command line tools and scripts. It should read like a tutorial in the same
way that the Command-line Interface guide does.
{{Using Plugman to Manage Plugins}} First, this guide needs to get exposed;
I can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1]
[jira] [Resolved] (CB-4890) Reference to plugins.xml should be config.xml
[
https://issues.apache.org/jira/browse/CB-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau resolved CB-4890.
-
Resolution: Fixed
Reference to plugins.xml should be config.xml
-
Key: CB-4890
URL: https://issues.apache.org/jira/browse/CB-4890
Project: Apache Cordova
Issue Type: Improvement
Components: Docs
Affects Versions: 2.9.0
Reporter: Peter
Assignee: Michael Brooks
Priority: Trivial
The Capture API documentation for Android (see Permissions section) is
still referring to plugins.xml instead of config.xml
{quote}
Permissions
Android
app/res/xml/plugins.xml
{quote}
http://cordova.apache.org/docs/en/2.9.0/cordova_media_capture_capture.md.html#Capture
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5196) BB10 invoke() plugin is shadowded by cordova.js
[
https://issues.apache.org/jira/browse/CB-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805334#comment-13805334
]
Mike Billau commented on CB-5196:
-
Hmmm so all of the WebWorks API's were folded into the Blackberry plugins
listed in the repo above?
If the WebWorks SDK is not compatible with Cordova 3.X, does that mean the only
way to access the WebWorks API is to install these plugins?
Is this documented anywhere? I was looking on edge but can't find anything
talking about installing these new plugins in order to continue to use
functionality that was just there from the WebWorks SDK. I can help with this
documentation if needed...We could probably create a new guide like Using
WebWorks APIs (blackberry.invoke) and link to this guide in the Blackberry
Platform Guide [1] and BB10 Command Line Tools [2]?
[1]http://cordova.apache.org/docs/en/edge/guide_platforms_blackberry10_index.md.html#BlackBerry%2010%20Platform%20Guide
[2]http://cordova.apache.org/docs/en/edge/guide_platforms_blackberry10_tools.md.html#BlackBerry%2010%20Command-line%20Tools
BB10 invoke() plugin is shadowded by cordova.js
---
Key: CB-5196
URL: https://issues.apache.org/jira/browse/CB-5196
Project: Apache Cordova
Issue Type: Bug
Components: BlackBerry
Affects Versions: 3.1.0
Environment: Blackberry 10
Reporter: Mike Billau
Attachments: bbInvoke.html
Our users need to invoke blackberry.invoke.invoke(). As per WebWorks doc, to
call any BB API, webworks.js needs to be included in the html file.
The problem is that there does not seem to be a way to call invoke():
1. Create a simple BB10 app using the attached HTML file,
2. Add feature to the config.xml: feature id=blackberry.invoke
name=blackberry.invoke value=blackberry.invoke/
3. Run the app. Press the button; the browser window doesn't open.
4. Edit the HTML file and place the cordova.js script before webworks.js
script
5. Run the app again, and there is a popup saying: Error intializing
cordova:undefined. After dismissing the alert, you can press the button and
the browser opens just fine.
Analysis:
Internally blackberry.invoke.invoke() ('invoke' plugin) calls
*window.webworks.event.isOn()* in blackberry.invoke/client.js. This is where
the problem is: *window.webworks* is defined in both cordova.js and
webworks.js.The one in cordova.js doesn't have 'event' function whereas it is
available in window.webworks of webworks.js. Hence when webworks.js is loaded
after cordova.js, it works fine and not if it is reversed.
Even though it works when we put webworks.js first we need to squash the
alert() and make sure cordova initializes correctly.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CB-5052) Andorid's media capture doesn't use ThreadPool
[
https://issues.apache.org/jira/browse/CB-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5052:
Priority: Minor (was: Major)
Andorid's media capture doesn't use ThreadPool
--
Key: CB-5052
URL: https://issues.apache.org/jira/browse/CB-5052
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Media Capture
Environment: Windows 7
Reporter: Mike Billau
Assignee: David Kemp
Priority: Minor
From:
http://stackoverflow.com/questions/19282318/phongap-capture-plugin-crashes-android
Taking a picture with media-capture plugin will crash the app when the plugin
returns from the camera app. Reproduced with Nexus 7 on 4.2, I used the
simple Full Example from the docs.
Got this in logcat:
{noformat}
I/ActivityManager( 476): Displayed
com.google.android.gallery3d/com.android.camera.CameraActivity: +1s80ms
W/IInputConnectionWrapper(31792): showStatusIcon on inactive InputConnection
V/CAM_PhotoModule(29129): Preview size is 960x720
V/CAM_PhotoModule(29129): onShutterButtonClick: mCameraState=1
E/NvOmxCamera( 128): OMX_ERRORTYPE
android::NvOmxCamera::getCameraStereoMode(NvxComponent*,
NvOmxCameraUserStereoMode): Error: invalid NVX mode 0.
E/NvOmxCamera( 128): OMX_ERRORTYPE
android::NvOmxCamera::getCameraStereoModeAndCaptureInfo(NvxComponent*,
NvOmxCameraUserStereoMode, NVX_STEREOCAPTUREINFO): getCameraStereoMode
failed with 0x
D/NvOsDebugPrintf( 128): NvMMLiteJPEGEncSetAttribute: Incorrect value 0 for
stereo capture type
E/NvOmxCameraSettings( 128): OMX_ERRORTYPE
android::programStereoInfo(OMX_HANDLETYPE, const NVX_STEREOCAPTUREINFO,
android::NvxWrappers*): pNvxWrappers-OMX_SetConfigIL failed with 0x80001005
V/CAM_PhotoModule(29129): mShutterToRawCallbackTime = 1381355622457ms
V/CAM_PhotoModule(29129): mShutterLag = 422ms
D/dalvikvm(29129): GC_FOR_ALLOC freed 679K, 15% free 1K/14236K, paused
27ms, total 28ms
I/dalvikvm-heap(29129): Grow heap (frag case) to 13.063MB for 1036816-byte
allocation
D/NvOsDebugPrintf( 128): Tryproc: INBuffer-Values of Width and Height 1280
960
D/dalvikvm(29129): GC_FOR_ALLOC freed 1K, 14% free 13233K/15252K, paused
33ms, total 33ms
V/CAM_PhotoModule(29129): mShutterToPostViewCallbackTime = 88ms
V/CAM_PhotoModule(29129): mShutterToRawCallbackTime = 109ms
V/CAM_PhotoModule(29129): mPictureDisplayedToJpegCallbackTime = 25ms
D/CameraStorage(29129): External storage state=mounted
V/CAM_PhotoModule(29129): mJpegCallbackFinishTime = 2ms
I/MPL-storeload( 476): mpl state size = 5512
E/MPL-storeload( 476): calData from inv_save_mpl_states, size=2
I/MPL-storeload( 476): cal data size to write = 5512
I/MPL-storeload( 476): Bytes written = 5512
V/CAM_PhotoModule(29129): stopPreview
D/( 128): Camera fd close (MI1040)
E/NvOmxCamera( 128): Already called release()
I/CameraClient( 128): Destroying camera 0
W/NvOmxCamera( 128): Already called release()
D/MediaProvider(27296): object removed 2270
W/AudioFlinger( 128): session id 453 not found for pid 128
W/AudioFlinger( 128): session id 454 not found for pid 128
D/CordovaActivity(31792): Request code = 1
D/AndroidRuntime(31792): Shutting down VM
W/dalvikvm(31792): threadid=1: thread exiting with uncaught exception
(group=0x410ee930)
E/AndroidRuntime(31792): FATAL EXCEPTION: main
E/AndroidRuntime(31792): java.lang.RuntimeException: Failure delivering
result ResultInfo{who=null, request=1, result=-1, data=null} to activity
{io.cordova.hellocordova/io.cordova.hellocordova.HelloCordova}:
java.lang.IllegalStateException: Do not perform IO operations on the UI
thread. Use Cordova
Interface.getThreadPool() instead.
E/AndroidRuntime(31792):at
android.app.ActivityThread.deliverResults(ActivityThread.java:3319)
E/AndroidRuntime(31792):at
android.app.ActivityThread.handleSendResult(ActivityThread.java:3362)
E/AndroidRuntime(31792):at
android.app.ActivityThread.access$1100(ActivityThread.java:141)
E/AndroidRuntime(31792):at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1282)
E/AndroidRuntime(31792):at
android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime(31792):at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime(31792):at
android.app.ActivityThread.main(ActivityThread.java:5041)
E/AndroidRuntime(31792):at
java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime(31792):at
java.lang.reflect.Method.invoke(Method.java:511)
E/AndroidRuntime(31792):at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
E/AndroidRuntime(31792):at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
[jira] [Created] (CB-5196) BB10 invoke() plugin is shadowded by cordova.js
Mike Billau created CB-5196:
---
Summary: BB10 invoke() plugin is shadowded by cordova.js
Key: CB-5196
URL: https://issues.apache.org/jira/browse/CB-5196
Project: Apache Cordova
Issue Type: Bug
Components: BlackBerry
Affects Versions: 3.1.0
Environment: Blackberry 10
Reporter: Mike Billau
Our users need to invoke blackberry.invoke.invoke(). As per WebWorks doc, to
call any BB API, webworks.js needs to be included in the html file.
The problem is that there does not seem to be a way to call invoke():
1. Create a simple BB10 app using the attached HTML file,
2. Add feature to the config.xml: feature id=blackberry.invoke
name=blackberry.invoke value=blackberry.invoke/
3. Run the app. Press the button; the browser window doesn't open.
4. Edit the HTML file and place the cordova.js script before webworks.js script
5. Run the app again, and there is a popup saying: Error intializing
cordova:undefined. After dismissing the alert, you can press the button and
the browser opens just fine.
Analysis:
Internally blackberry.invoke.invoke() ('invoke' plugin) calls
*window.webworks.event.isOn()* in blackberry.invoke/client.js. This is where
the problem is: *window.webworks* is defined in both cordova.js and
webworks.js.The one in cordova.js doesn't have 'event' function whereas it is
available in window.webworks of webworks.js. Hence when webworks.js is loaded
after cordova.js, it works fine and not if it is reversed.
Even though it works when we put webworks.js first we need to squash the
alert() and make sure cordova initializes correctly.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CB-5196) BB10 invoke() plugin is shadowded by cordova.js
[
https://issues.apache.org/jira/browse/CB-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5196:
Attachment: bbInvoke.html
BB10 invoke() plugin is shadowded by cordova.js
---
Key: CB-5196
URL: https://issues.apache.org/jira/browse/CB-5196
Project: Apache Cordova
Issue Type: Bug
Components: BlackBerry
Affects Versions: 3.1.0
Environment: Blackberry 10
Reporter: Mike Billau
Attachments: bbInvoke.html
Our users need to invoke blackberry.invoke.invoke(). As per WebWorks doc, to
call any BB API, webworks.js needs to be included in the html file.
The problem is that there does not seem to be a way to call invoke():
1. Create a simple BB10 app using the attached HTML file,
2. Add feature to the config.xml: feature id=blackberry.invoke
name=blackberry.invoke value=blackberry.invoke/
3. Run the app. Press the button; the browser window doesn't open.
4. Edit the HTML file and place the cordova.js script before webworks.js
script
5. Run the app again, and there is a popup saying: Error intializing
cordova:undefined. After dismissing the alert, you can press the button and
the browser opens just fine.
Analysis:
Internally blackberry.invoke.invoke() ('invoke' plugin) calls
*window.webworks.event.isOn()* in blackberry.invoke/client.js. This is where
the problem is: *window.webworks* is defined in both cordova.js and
webworks.js.The one in cordova.js doesn't have 'event' function whereas it is
available in window.webworks of webworks.js. Hence when webworks.js is loaded
after cordova.js, it works fine and not if it is reversed.
Even though it works when we put webworks.js first we need to squash the
alert() and make sure cordova initializes correctly.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CB-4982) cordova plugin add help text should show how to install plugin by git url plus branch and subdir
[ https://issues.apache.org/jira/browse/CB-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau reassigned CB-4982: --- Assignee: Mike Billau cordova plugin add help text should show how to install plugin by git url plus branch and subdir -- Key: CB-4982 URL: https://issues.apache.org/jira/browse/CB-4982 Project: Apache Cordova Issue Type: Improvement Components: CLI Affects Versions: Master Environment: cordova 3.1.0-0.1.0 Reporter: Shazron Abdullah Assignee: Mike Billau Priority: Minor when you run cordova with no arguments, the Project Level Commands section, plugin add parameter has help text on how to install a plugin by git url, but nothing about how to specify a branch and a subdir. A branch is specified by a hash, and subdir with a colon. For example, this uses the plugins branch, and the subdir of keyboard: https://git-wip-us.apache.org/repos/asf/cordova-labs.git#plugins:keyboard -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5034) Document plugin registry
[ https://issues.apache.org/jira/browse/CB-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13803220#comment-13803220 ] Mike Billau commented on CB-5034: - Plugman README.md: https://github.com/apache/cordova-plugman/pull/28 Adds registry commands to the README.md file including how to change the registry's URL. `plugman help` already had comments about the registry, these just weren't reflected in the README.md CLI help command: https://github.com/apache/cordova-cli/pull/48 Adds the search command to the CLI's help file. Currently the CLI is unable to set the registry for plugman so I did not include the config set commands yet (filed CB-5185 for this) readme.md: Forgot to add the registry stuff in the above pull request; created a new request based off of the updated README.md: https://github.com/apache/cordova-cli/pull/61 Command-line Interface guide: It looks like Mike Sierra and Michael Brooks beat me to it with https://github.com/apache/cordova-docs/commit/8b1b333d3fd37ad256c3c2a8894dc4405c61bc19. This adds a line about how the plugins use a registry and how plugin add will take the plugin id, along with some examples of advanced plugin usage. Looks great. It doesn't talk about using 3rd party registries but I think that can wait until the CLI can change plugman's registry. Sorry that it took me a little while to get to this. Document plugin registry Key: CB-5034 URL: https://issues.apache.org/jira/browse/CB-5034 Project: Apache Cordova Issue Type: Bug Components: Docs, Registry Affects Versions: Master Reporter: Mike Billau Assignee: Mike Billau I can't find any reference to the plugin registry anywhere in our documentation. Am I looking in the wrong place or are we waiting for the web component to be more polished before announcing the registry? I think some places the registry should be mentioned: Plugman: readme.md CLI: cordova help command (CB-5031) readme.md docs: http://cordova.apache.org/docs/en/edge/guide_cli_index.md.html#The%20Command-line%20Interface (I think it's best to split the Add Platforms section into Add Platforms and Add Plugins, and in this new section talk about adding plugins, automatic plugin installation (plugin dependencies), and the registry) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5175) Fix core plugins that incorrectly run on main thread
Mike Billau created CB-5175: --- Summary: Fix core plugins that incorrectly run on main thread Key: CB-5175 URL: https://issues.apache.org/jira/browse/CB-5175 Project: Apache Cordova Issue Type: Bug Components: Docs, Plugin Device Orientation, Plugin File, Plugin Media Reporter: Mike Billau Priority: Minor After CB-4133 we are able to detect and log when a plugin incorrectly does work on the UI thread instead of a worker thread. We should go back and verify that all of our plugins follow this practice - eat your own dogfood type of thing. We know there are problems with: Android: file, compass iOS: media Docs: Need to verify plugin author guide is still valid -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CB-5117) Android's bin/check_reqs should report success
[ https://issues.apache.org/jira/browse/CB-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-5117. - Resolution: Fixed Fix Version/s: 3.2.0 Android's bin/check_reqs should report success -- Key: CB-5117 URL: https://issues.apache.org/jira/browse/CB-5117 Project: Apache Cordova Issue Type: Bug Components: Android Environment: Windows 7 Reporter: Mike Billau Priority: Minor Fix For: 3.2.0 Running the /bin/check_reqs script will report errors if there is a problem with your ant, java, or Android SDK versions. If there are no problems, it remains silents - it'd be nice for some positive feedback so that you know that the script worked and nothing is wrong. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5052) Andorid's media capture doesn't use ThreadPool
[
https://issues.apache.org/jira/browse/CB-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802218#comment-13802218
]
Mike Billau commented on CB-5052:
-
The workaround in the stack overflow post just disables threadChecking before
calling out to webView.getResourceApi().mapUriToFile(data); then re-enables
threadChecking, so I'm not sure that this is an actual solution (the workaround
DOES work fine btw.) Regardless we can't take photos or videos on Android
(well, Nexus 7 and S4)...not sure how this slipped through the release testing.
Andorid's media capture doesn't use ThreadPool
--
Key: CB-5052
URL: https://issues.apache.org/jira/browse/CB-5052
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Media Capture
Environment: Windows 7
Reporter: Mike Billau
Assignee: David Kemp
From:
http://stackoverflow.com/questions/19282318/phongap-capture-plugin-crashes-android
Taking a picture with media-capture plugin will crash the app when the plugin
returns from the camera app. Reproduced with Nexus 7 on 4.2, I used the
simple Full Example from the docs.
Got this in logcat:
{noformat}
I/ActivityManager( 476): Displayed
com.google.android.gallery3d/com.android.camera.CameraActivity: +1s80ms
W/IInputConnectionWrapper(31792): showStatusIcon on inactive InputConnection
V/CAM_PhotoModule(29129): Preview size is 960x720
V/CAM_PhotoModule(29129): onShutterButtonClick: mCameraState=1
E/NvOmxCamera( 128): OMX_ERRORTYPE
android::NvOmxCamera::getCameraStereoMode(NvxComponent*,
NvOmxCameraUserStereoMode): Error: invalid NVX mode 0.
E/NvOmxCamera( 128): OMX_ERRORTYPE
android::NvOmxCamera::getCameraStereoModeAndCaptureInfo(NvxComponent*,
NvOmxCameraUserStereoMode, NVX_STEREOCAPTUREINFO): getCameraStereoMode
failed with 0x
D/NvOsDebugPrintf( 128): NvMMLiteJPEGEncSetAttribute: Incorrect value 0 for
stereo capture type
E/NvOmxCameraSettings( 128): OMX_ERRORTYPE
android::programStereoInfo(OMX_HANDLETYPE, const NVX_STEREOCAPTUREINFO,
android::NvxWrappers*): pNvxWrappers-OMX_SetConfigIL failed with 0x80001005
V/CAM_PhotoModule(29129): mShutterToRawCallbackTime = 1381355622457ms
V/CAM_PhotoModule(29129): mShutterLag = 422ms
D/dalvikvm(29129): GC_FOR_ALLOC freed 679K, 15% free 1K/14236K, paused
27ms, total 28ms
I/dalvikvm-heap(29129): Grow heap (frag case) to 13.063MB for 1036816-byte
allocation
D/NvOsDebugPrintf( 128): Tryproc: INBuffer-Values of Width and Height 1280
960
D/dalvikvm(29129): GC_FOR_ALLOC freed 1K, 14% free 13233K/15252K, paused
33ms, total 33ms
V/CAM_PhotoModule(29129): mShutterToPostViewCallbackTime = 88ms
V/CAM_PhotoModule(29129): mShutterToRawCallbackTime = 109ms
V/CAM_PhotoModule(29129): mPictureDisplayedToJpegCallbackTime = 25ms
D/CameraStorage(29129): External storage state=mounted
V/CAM_PhotoModule(29129): mJpegCallbackFinishTime = 2ms
I/MPL-storeload( 476): mpl state size = 5512
E/MPL-storeload( 476): calData from inv_save_mpl_states, size=2
I/MPL-storeload( 476): cal data size to write = 5512
I/MPL-storeload( 476): Bytes written = 5512
V/CAM_PhotoModule(29129): stopPreview
D/( 128): Camera fd close (MI1040)
E/NvOmxCamera( 128): Already called release()
I/CameraClient( 128): Destroying camera 0
W/NvOmxCamera( 128): Already called release()
D/MediaProvider(27296): object removed 2270
W/AudioFlinger( 128): session id 453 not found for pid 128
W/AudioFlinger( 128): session id 454 not found for pid 128
D/CordovaActivity(31792): Request code = 1
D/AndroidRuntime(31792): Shutting down VM
W/dalvikvm(31792): threadid=1: thread exiting with uncaught exception
(group=0x410ee930)
E/AndroidRuntime(31792): FATAL EXCEPTION: main
E/AndroidRuntime(31792): java.lang.RuntimeException: Failure delivering
result ResultInfo{who=null, request=1, result=-1, data=null} to activity
{io.cordova.hellocordova/io.cordova.hellocordova.HelloCordova}:
java.lang.IllegalStateException: Do not perform IO operations on the UI
thread. Use Cordova
Interface.getThreadPool() instead.
E/AndroidRuntime(31792):at
android.app.ActivityThread.deliverResults(ActivityThread.java:3319)
E/AndroidRuntime(31792):at
android.app.ActivityThread.handleSendResult(ActivityThread.java:3362)
E/AndroidRuntime(31792):at
android.app.ActivityThread.access$1100(ActivityThread.java:141)
E/AndroidRuntime(31792):at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1282)
E/AndroidRuntime(31792):at
android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime(31792):at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime(31792):at
android.app.ActivityThread.main(ActivityThread.java:5041)
E/AndroidRuntime(31792):
[jira] [Closed] (CB-5097) Device - API docs / plugin.xml permission mismatch
[
https://issues.apache.org/jira/browse/CB-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau closed CB-5097.
---
Resolution: Fixed
Device - API docs / plugin.xml permission mismatch
--
Key: CB-5097
URL: https://issues.apache.org/jira/browse/CB-5097
Project: Apache Cordova
Issue Type: Bug
Components: Android, Docs, Plugin Device
Affects Versions: 3.1.0
Reporter: Peter
Assignee: Mike Sierra
Priority: Minor
The plugin.xml for *cordova-plugin-device* Device doesn't have any special
Android permissions, but the documentation
http://cordova.apache.org/docs/en/3.1.0/cordova_device_device.md.html#Device
says it needs
{code}
uses-permission android:name=android.permission.READ_PHONE_STATE /
{code}
Documentation incorrect?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (CB-5005) Feature and Permissions docs wrong for Android plugins
[ https://issues.apache.org/jira/browse/CB-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau closed CB-5005. --- Resolution: Fixed Feature and Permissions docs wrong for Android plugins -- Key: CB-5005 URL: https://issues.apache.org/jira/browse/CB-5005 Project: Apache Cordova Issue Type: Bug Components: Plugin Battery Status, Plugin Camera, Plugin Console, Plugin Contacts, Plugin Device, Plugin Device Motion, Plugin Device Orientation, Plugin Dialogs, Plugin File, Plugin File Transfer, Plugin Geolocation, Plugin Globalization, Plugin InAppBrowser, Plugin Media, Plugin Media Capture, Plugin Network Information, Plugin SplashScreen, Plugin Vibration Affects Versions: Master Reporter: Mike Billau Assignee: Michael Brooks Priority: Trivial Most (all?) of the plugin documentation pages have the wrong value for the plugin id attribute in the Accessing the Feature section for Android. A lot of the plugins also seem to have the wrong list of Permissions that get added to the AndroidManifest.xml. This can be confusing for new users who follow along with the docs and expect to see something different in these files. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CB-5074) Battery status plugin permission not added for Android?
[
https://issues.apache.org/jira/browse/CB-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau closed CB-5074.
---
Resolution: Fixed
Assignee: Mike Billau (was: Mike Sierra)
Thanks Steve!
Battery status plugin permission not added for Android?
---
Key: CB-5074
URL: https://issues.apache.org/jira/browse/CB-5074
Project: Apache Cordova
Issue Type: Bug
Components: Android, Docs, Plugin Battery Status
Affects Versions: 3.1.0
Reporter: Peter
Assignee: Mike Billau
Priority: Minor
The documentation for the Events
http://cordova.apache.org/docs/en/3.1.0/cordova_events_events.md.html#Events
says that for Android it needs the following permission:
{code}
uses-permission android:name=android.permission.BROADCAST_STICKY /
{code}
But after we added the v3.1 *corova-plugin-battery-status* plugin via CLI we
noticed this permission had not been set in the AndroidManifest.xml
And when we went back to look at the plugin.xml for the
corova-plugin-battery-status the necessary Android permission is not there.
https://github.com/apache/cordova-plugin-battery-status/blob/master/plugin.xml
So is the permission needed or not? The documentation and battery plugin's
plugin.xml seem to be in disagreement
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CB-5095) Capture - API documentation / plugin.xml permission mismatch
[
https://issues.apache.org/jira/browse/CB-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau resolved CB-5095.
-
Resolution: Fixed
Assignee: Mike Billau (was: Mike Sierra)
Thanks Steve.
Capture - API documentation / plugin.xml permission mismatch
Key: CB-5095
URL: https://issues.apache.org/jira/browse/CB-5095
Project: Apache Cordova
Issue Type: Bug
Components: Android, Docs, Plugin Media Capture
Affects Versions: 3.1.0
Reporter: Peter
Assignee: Mike Billau
Priority: Minor
The plugin for *cordova-plugin-media-capture* plugin.xml
https://github.com/apache/cordova-plugin-media-capture/blob/3.1.0/plugin.xml
says it needs the following permissions
{code}
uses-permission android:name=android.permission.RECORD_AUDIO /
uses-permission android:name=android.permission.RECORD_VIDEO/
uses-permission android:name=android.permission.WRITE_EXTERNAL_STORAGE /
{code}
but the documentation
http://cordova.apache.org/docs/en/3.1.0/cordova_media_capture_capture.md.html#Capture
says it only needs
{code}
uses-permission android:name=android.permission.RECORD_AUDIO /
uses-permission android:name=android.permission.WRITE_EXTERNAL_STORAGE /
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (CB-5096) Compass - API docs / plugin.xml permission mismatch
[
https://issues.apache.org/jira/browse/CB-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau closed CB-5096.
---
Resolution: Fixed
Assignee: Mike Billau (was: Mike Sierra)
Thanks Steve!
Compass - API docs / plugin.xml permission mismatch
---
Key: CB-5096
URL: https://issues.apache.org/jira/browse/CB-5096
Project: Apache Cordova
Issue Type: Bug
Components: Android, Docs, Plugin Device Orientation
Affects Versions: 3.1.0
Reporter: Peter
Assignee: Mike Billau
Priority: Minor
The plugin for *cordova-plugin-device-orientation* plugin.xml
https://github.com/apache/cordova-plugin-device-orientation/blob/master/plugin.xml
says the Compass needs the following permissions
{code}
uses-permission android:name=android.permission.ACCESS_COARSE_LOCATION /
uses-permission android:name=android.permission.ACCESS_FINE_LOCATION /
{code}
but the documentation
http://cordova.apache.org/docs/en/3.1.0/cordova_compass_compass.md.html#Compass
makes no mention of this requirement.
Which one is correct?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CB-4811) Device plugin requires no permissions, so remove from documentaion
[ https://issues.apache.org/jira/browse/CB-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-4811. - Resolution: Fixed Merged in here with a larger commit of the same type of issues: https://github.com/apache/cordova-docs/commit/56c0f53e88bae1eafb56b743dd6bae26b7198f13 Device plugin requires no permissions, so remove from documentaion --- Key: CB-4811 URL: https://issues.apache.org/jira/browse/CB-4811 Project: Apache Cordova Issue Type: Bug Components: Docs, Plugin Device Affects Versions: 3.0.0 Environment: Windows 7 Reporter: Mike Billau Assignee: Michael Brooks Priority: Minor The docs for the cordova-plugin-device plugin (http://cordova.apache.org/docs/en/edge/cordova_device_device.md.html#Device) say that the plugin will add uses-permission android:name=android.permission.READ_PHONE_STATE / to AndroidManifest.xml However, it seems like this is not actually the case, because 1) there is nothing in the plugin.xml file that would do this (missing config-file target=AndroidManifest.xml parent=/*[...]) element, and 2) it doesn't seem like the device functionality needs this permission at all. Unless there are some strange dependencies that I'm not seeing between other plugins that require the device plugin to have this permission (that wouldn't make sense...?), I think the docs should be edited to reflect this to avoid causing confusion (it confused me at least!) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5116) Link to config.xml guide broken on Android Configuration guide
Mike Billau created CB-5116: --- Summary: Link to config.xml guide broken on Android Configuration guide Key: CB-5116 URL: https://issues.apache.org/jira/browse/CB-5116 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 3.1.0 Reporter: Mike Billau Priority: Minor When on the Android Configuration Guide, there are links to the Config.xml guide but the link is broken: http://cordova.apache.org/docs/en/edge/guide_platforms_android_config.md.html#Android%20Configuration -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-4818) InAppBrowser addEventListener 3rd parameter?
[
https://issues.apache.org/jira/browse/CB-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797955#comment-13797955
]
Mike Billau commented on CB-4818:
-
The only place I see this is:
https://github.com/apache/cordova-mobile-spec/blob/master/inappbrowser/index.html#L115
It's not in the documentation or examples or any other tests.
I'm thinking that somebody just accidentally added a false parameter to the
end, like what we normally do for document.addEventListener.
InAppBrowser addEventListener 3rd parameter?
Key: CB-4818
URL: https://issues.apache.org/jira/browse/CB-4818
Project: Apache Cordova
Issue Type: Test
Components: Docs, mobile-spec
Affects Versions: 2.9.0
Reporter: Peter
Assignee: Michael Brooks
Priority: Minor
The mobile-spec InAppBrowser tests addEventListener:
{code}
iab.addEventListener('loaderror', logEvent, false);
iab.addEventListener('loadstart', logEvent, false);
iab.addEventListener('loadstop', logEvent, false);
iab.addEventListener('exit', logEvent, false);
{code}
But that test code above is calling addEventListener with 3 parameters, and
the 3rd parameter is neither documented
http://cordova.apache.org/docs/en/3.0.0/cordova_inappbrowser_inappbrowser.md.html#addEventListener,
nor (IIUC) is it implemented in the cordova.js
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-4974) Load page domain name with between character error
[
https://issues.apache.org/jira/browse/CB-4974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797983#comment-13797983
]
Mike Billau commented on CB-4974:
-
Are you talking about loading a page with a hyphen or something in the url,
like www.my-website.com? Did you make sure that the page is added to your
whitelist? There was an issue filed like this a few months ago and I remember
testing that hyphenated URL's were treated correctly.
Load page domain name with between character error
--
Key: CB-4974
URL: https://issues.apache.org/jira/browse/CB-4974
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 3.0.0
Environment: Android
Reporter: Khai Bui
Original Estimate: 24h
Remaining Estimate: 24h
public class HelloWorld extends DroidGap
{
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
// Set by content src=index.html / in config.xml
//super.loadUrl(Config.getStartUrl());
super.loadUrl(http://www.example-name.com;);
}
}
URL http://www.example-name.com have a between - on example-name
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CB-4725) device.cordova returns 'dev' on Android
[ https://issues.apache.org/jira/browse/CB-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-4725. - Resolution: Fixed Looks like it's fixed. device.cordova returns 'dev' on Android --- Key: CB-4725 URL: https://issues.apache.org/jira/browse/CB-4725 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Device Affects Versions: 3.0.0 Environment: Android Reporter: Stefan Dobrev Assignee: Andrew Grieve Priority: Minor device.cordova returns 'dev' on Android platform. Expected value is '3.0.0' -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-4518) Battery level is not calculated correctly
[
https://issues.apache.org/jira/browse/CB-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797995#comment-13797995
]
Mike Billau commented on CB-4518:
-
Not sure if these are the same issues or not...
Battery level is not calculated correctly
---
Key: CB-4518
URL: https://issues.apache.org/jira/browse/CB-4518
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.9.0
Reporter: Peter
Assignee: Joe Bowser
Priority: Minor
The meaning of the Battery level in Cordova is a charge *percentage*.
Ref
http://cordova.apache.org/docs/en/2.9.0/cordova_events_events.md.html#batterylow
But the Battery EXTRA_LEVEL is not a percentage. It's just a number in the
range 0 to EXTRA_SCALE
Ref
http://developer.android.com/reference/android/os/BatteryManager.html#EXTRA_LEVEL
So the battery level calculation should be something like:
{code}
int level = batteryIntent.getIntExtra(android.os.BatteryManager.EXTRA_LEVEL,
0);
int scale = batteryIntent.getIntExtra(android.os.BatteryManager.EXTRA_SCALE,
100);
int percent = 100 * level / scale;
obj.put(level, percent);
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CB-5117) Android's bin/check_reqs should report success
Mike Billau created CB-5117: --- Summary: Android's bin/check_reqs should report success Key: CB-5117 URL: https://issues.apache.org/jira/browse/CB-5117 Project: Apache Cordova Issue Type: Bug Components: Android Environment: Windows 7 Reporter: Mike Billau Priority: Minor Running the /bin/check_reqs script will report errors if there is a problem with your ant, java, or Android SDK versions. If there are no problems, it remains silents - it'd be nice for some positive feedback so that you know that the script worked and nothing is wrong. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5119) Android's bin/check_reqs fails with spaces
Mike Billau created CB-5119: --- Summary: Android's bin/check_reqs fails with spaces Key: CB-5119 URL: https://issues.apache.org/jira/browse/CB-5119 Project: Apache Cordova Issue Type: Bug Components: Android Environment: Windows 7 Reporter: Mike Billau Priority: Minor If you have a path with a space in it, running the check_reqs script will fail. Thought this was a bit odd since the create script will work even with spaces. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5119) Android's bin/check_reqs fails with spaces
[ https://issues.apache.org/jira/browse/CB-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798170#comment-13798170 ] Mike Billau commented on CB-5119: - Fails when there are spaces in the path. Android's bin/check_reqs fails with spaces -- Key: CB-5119 URL: https://issues.apache.org/jira/browse/CB-5119 Project: Apache Cordova Issue Type: Bug Components: Android Environment: Windows 7 Reporter: Mike Billau Priority: Minor If you have a path with a space in it, running the check_reqs script will fail. Thought this was a bit odd since the create script will work even with spaces. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5117) Android's bin/check_reqs should report success
[ https://issues.apache.org/jira/browse/CB-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798268#comment-13798268 ] Mike Billau commented on CB-5117: - Here is a pull request: https://github.com/apache/cordova-android/pull/79 Still wrapping my head around Q.js so any hints or comments are appreciated. Android's bin/check_reqs should report success -- Key: CB-5117 URL: https://issues.apache.org/jira/browse/CB-5117 Project: Apache Cordova Issue Type: Bug Components: Android Environment: Windows 7 Reporter: Mike Billau Priority: Minor Running the /bin/check_reqs script will report errors if there is a problem with your ant, java, or Android SDK versions. If there are no problems, it remains silents - it'd be nice for some positive feedback so that you know that the script worked and nothing is wrong. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5122:
Description:
Based on the recent discussion here [1], we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide -- Development Paths section}}[2]. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
{{The Command-line Interface guide}} -- The CLI workflow guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides -- (Platform) -- (Platform) Command-line tools}} -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
{{Using Plugman to Manage Plugins}} [3] First, this guide needs to get
exposed; I can't find any way to get to this guide from the docs and even had
to ask a user how she managed to find it (a link from Plugman's readme!). This
guide needs to be expanded quite a bit; we can probably fold most/all of
Plugman's README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
was:
Based on the recent discussion here[1], we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
Overview guide -- Development Paths section[2]. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
The Command-line Interface guide -- The CLI workflow guide. It generally
looks complete except for some missing functionality that is documented in the
CLI's README.md file (tests, hooks, some commands (serve), some merges info).
Platform Guides -- {Platform} -- {Platform} Command-line tools -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
Using Plugman to Manage Plugins [3] First, this guide needs to get exposed; I
can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
Document supported workflows
Key: CB-5122
URL: https://issues.apache.org/jira/browse/CB-5122
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 3.1.0
Reporter: Mike Billau
Assignee: Mike Billau
Based on the recent discussion here [1], we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin
scripts.
Some of
[jira] [Updated] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5122:
Description:
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide -- Development Paths section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
{{The Command-line Interface guide}} -- The CLI workflow guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides -- (Platform) -- (Platform) Command-line tools}} -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
{{Using Plugman to Manage Plugins}} First, this guide needs to get exposed; I
can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
was:
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide -- Development Paths section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
{{The Command-line Interface guide}} -- The CLI workflow guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides -- (Platform) -- (Platform) Command-line tools}} -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
{{Using Plugman to Manage Plugins}} [3] First, this guide needs to get
exposed; I can't find any way to get to this guide from the docs and even had
to ask a user how she managed to find it (a link from Plugman's readme!). This
guide needs to be expanded quite a bit; we can probably fold most/all of
Plugman's README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
Document supported workflows
Key: CB-5122
URL: https://issues.apache.org/jira/browse/CB-5122
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 3.1.0
Reporter: Mike Billau
Assignee: Mike Billau
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin
scripts.
Some
[jira] [Updated] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5122:
Description:
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide -- Development Paths section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
{{The Command-line Interface guide}} -- The CLI workflow guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides -- (Platform) -- (Platform) Command-line tools}} -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
{{Using Plugman to Manage Plugins}} [3] First, this guide needs to get
exposed; I can't find any way to get to this guide from the docs and even had
to ask a user how she managed to find it (a link from Plugman's readme!). This
guide needs to be expanded quite a bit; we can probably fold most/all of
Plugman's README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
was:
Based on the recent discussion here [1], we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide -- Development Paths section}}[2]. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
{{The Command-line Interface guide}} -- The CLI workflow guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides -- (Platform) -- (Platform) Command-line tools}} -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
{{Using Plugman to Manage Plugins}} [3] First, this guide needs to get
exposed; I can't find any way to get to this guide from the docs and even had
to ask a user how she managed to find it (a link from Plugman's readme!). This
guide needs to be expanded quite a bit; we can probably fold most/all of
Plugman's README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
Document supported workflows
Key: CB-5122
URL: https://issues.apache.org/jira/browse/CB-5122
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 3.1.0
Reporter: Mike Billau
Assignee: Mike Billau
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin
scripts.
[jira] [Created] (CB-5122) Document supported workflows
Mike Billau created CB-5122:
---
Summary: Document supported workflows
Key: CB-5122
URL: https://issues.apache.org/jira/browse/CB-5122
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 3.1.0
Reporter: Mike Billau
Assignee: Mike Billau
Based on the recent discussion here[1], we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
Overview guide -- Development Paths section[2]. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
The Command-line Interface guide -- The CLI workflow guide. It generally
looks complete except for some missing functionality that is documented in the
CLI's README.md file (tests, hooks, some commands (serve), some merges info).
Platform Guides -- {Platform} -- {Platform} Command-line tools -- Each
platform has a Command-line tools doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
Using Plugman to Manage Plugins [3] First, this guide needs to get exposed; I
can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
