[jira] [Commented] (CB-5767) Keyboard will/did hide/show events should be passed to JavaScript

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940161#comment-13940161
 ] 

ASF GitHub Bot commented on CB-5767:


Github user kant2002 closed the pull request at:

https://github.com/apache/cordova-plugins/pull/7


> Keyboard will/did hide/show events should be passed to JavaScript
> -
>
> Key: CB-5767
> URL: https://issues.apache.org/jira/browse/CB-5767
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Affects Versions: 3.0.0, 3.1.0, 3.2.0, 3.3.0
> Environment: iOS 7
>Reporter: Paul Hickman
>Assignee: Shazron Abdullah
>  Labels: ios7, keyboard-plugin
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> In order to resolve the issues iOS 7 creates with the keyboard shrinking the 
> view, our project needs the KeyboardWillShow, KeyboardDidShow, 
> KeyboardWillHide and KeyboardDidHide native events to be raised by the 
> keyboard plugin as JavaScript events, so that we can show/hide some HTML 
> elements.
> Would it be possible to add observers for the "Will" events as well as the 
> "Did" events, and then make all four observers execute some JavaScript to 
> trigger events in the DOM.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CB-6300) window.resolveLocalFileSystemURL weirdness

[nii amon dsane (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940158#comment-13940158
 ] 

nii amon dsane edited comment on CB-6300 at 3/19/14 4:37 AM:
-

Hey Ian, some feedback.

1. Adding the org.apache.cordova.file-system-roots plugin fixes the filesystem 
resolve issue. Yay!

2. When I have the resolved filesystem path and I try to display it on a page, 
I get a broken link. So somehow, cordova is unable to read the image that's 
referenced by the resolved filesystem path. This is how I am referencing the 
image in the page:


{{
  

{{image}}
  
}}

The image path is printed out on the page so I can confirm that it's the 
correct resolved filesystem path.

3. When I select a picture from the gallery, I get a really weird unresolved 
URI: 
file:///storage/sdcard0/Android/data/com.lukaduka.pos/cache/modified.jpg?1395202637809
I suppose the modified.jpg file is a sort of placeholder image and the query 
string timestamp points to the actual picture in the gallery. That's all fine 
as long as the filesystem resolve can point me to the right file in the gallery 
but that doesn't happen. This is the resolved filesystem path I get:

cdvfile://localhost/cache-external/modified.jpg

I suppose that's because the resolve is unable to use the query string part of 
the URI to resolve to the real file in the gallery.

I have saveToPhotoAlbum: true in the options for the camera and I don't know if 
setting that to false and then copying the file to a folder is wise. Ideally, I 
would like all this to be transparent to my code and so should be able to do a 
camera capture and then when selecting from a folder, I get the true file path 
not one to the modified.jpg with a querystring. 


was (Author: niiamon):
Hey Ian, some feedback.

1. Adding the org.apache.cordova.file-system-roots plugin fixes the filesystem 
resolve issue. Yay!

2. When I have the resolved filesystem path and I try to display it on a page, 
I get a broken link. So somehow, cordova is unable to read the image that's 
referenced by the resolved filesystem path. This is how I am referencing the 
image in the page:

{{

  

{{image}}
  

}}

The image path is printed out on the page so I can confirm that it's the 
correct resolved filesystem path.

3. When I select a picture from the gallery, I get a really weird unresolved 
URI: 
file:///storage/sdcard0/Android/data/com.lukaduka.pos/cache/modified.jpg?1395202637809
I suppose the modified.jpg file is a sort of placeholder image and the query 
string timestamp points to the actual picture in the gallery. That's all fine 
as long as the filesystem resolve can point me to the right file in the gallery 
but that doesn't happen. This is the resolved filesystem path I get:

cdvfile://localhost/cache-external/modified.jpg

I suppose that's because the resolve is unable to use the query string part of 
the URI to resolve to the real file in the gallery.

I have saveToPhotoAlbum: true in the options for the camera and I don't know if 
setting that to false and then copying the file to a folder is wise. Ideally, I 
would like all this to be transparent to my code and so should be able to do a 
camera capture and then when selecting from a folder, I get the true file path 
not one to the modified.jpg with a querystring. 

> window.resolveLocalFileSystemURL weirdness
> --
>
> Key: CB-6300
> URL: https://issues.apache.org/jira/browse/CB-6300
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS, Plugin File
>Affects Versions: 3.3.0
> Environment: file plugin 1.0.1
>Reporter: nii amon dsane
>Assignee: Ian Clelland
>  Labels: camera, file, newbie, plugin, resolveLocalFileSystemURL
>
> I am trying to use the window.resolveLocalFileSystemURL but for some reason 
> my failure callback is always triggered. The success callback is never 
> triggered. This is my code:
> {code}
> // Take a picture using the camera
> $scope.takePicture = function () {
> var options = {
>   quality: 100,
>   targetWidth: 500,
>   targetHeight: 500,
>   destinationType: Camera.DestinationType.FILE_URI,
>   encodingType: Camera.EncodingType.JPEG,
>   saveToPhotoAlbum: true,
>   correctOrientation: true,
>   sourceType: Camera.PictureSourceType.CAMERA,
>   allowEdit: true
> };
> navigator.camera.getPicture(
>   cameraSuccess,
>   cameraFailure,
>   options
> );
> return false;
>   };
>   // what to do when the camera has  successfully yielded a good image
>   function cameraSuccess(imageURI){
> var uri = 'cdv' + imageURI;
> alert('this is imageURI: ' + imageURI);
> window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
>   };
> {

[jira] [Comment Edited] (CB-6300) window.resolveLocalFileSystemURL weirdness

[nii amon dsane (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940158#comment-13940158
 ] 

nii amon dsane edited comment on CB-6300 at 3/19/14 4:37 AM:
-

Hey Ian, some feedback.

1. Adding the org.apache.cordova.file-system-roots plugin fixes the filesystem 
resolve issue. Yay!

2. When I have the resolved filesystem path and I try to display it on a page, 
I get a broken link. So somehow, cordova is unable to read the image that's 
referenced by the resolved filesystem path. This is how I am referencing the 
image in the page:



  

{{image}}
  


The image path is printed out on the page so I can confirm that it's the 
correct resolved filesystem path.

3. When I select a picture from the gallery, I get a really weird unresolved 
URI: 
file:///storage/sdcard0/Android/data/com.lukaduka.pos/cache/modified.jpg?1395202637809
I suppose the modified.jpg file is a sort of placeholder image and the query 
string timestamp points to the actual picture in the gallery. That's all fine 
as long as the filesystem resolve can point me to the right file in the gallery 
but that doesn't happen. This is the resolved filesystem path I get:

cdvfile://localhost/cache-external/modified.jpg

I suppose that's because the resolve is unable to use the query string part of 
the URI to resolve to the real file in the gallery.

I have saveToPhotoAlbum: true in the options for the camera and I don't know if 
setting that to false and then copying the file to a folder is wise. Ideally, I 
would like all this to be transparent to my code and so should be able to do a 
camera capture and then when selecting from a folder, I get the true file path 
not one to the modified.jpg with a querystring. 


was (Author: niiamon):
Hey Ian, some feedback.

1. Adding the org.apache.cordova.file-system-roots plugin fixes the filesystem 
resolve issue. Yay!

2. When I have the resolved filesystem path and I try to display it on a page, 
I get a broken link. So somehow, cordova is unable to read the image that's 
referenced by the resolved filesystem path. This is how I am referencing the 
image in the page:


{{
  

image
  
}}

The image path is printed out on the page so I can confirm that it's the 
correct resolved filesystem path.

3. When I select a picture from the gallery, I get a really weird unresolved 
URI: 
file:///storage/sdcard0/Android/data/com.lukaduka.pos/cache/modified.jpg?1395202637809
I suppose the modified.jpg file is a sort of placeholder image and the query 
string timestamp points to the actual picture in the gallery. That's all fine 
as long as the filesystem resolve can point me to the right file in the gallery 
but that doesn't happen. This is the resolved filesystem path I get:

cdvfile://localhost/cache-external/modified.jpg

I suppose that's because the resolve is unable to use the query string part of 
the URI to resolve to the real file in the gallery.

I have saveToPhotoAlbum: true in the options for the camera and I don't know if 
setting that to false and then copying the file to a folder is wise. Ideally, I 
would like all this to be transparent to my code and so should be able to do a 
camera capture and then when selecting from a folder, I get the true file path 
not one to the modified.jpg with a querystring. 

> window.resolveLocalFileSystemURL weirdness
> --
>
> Key: CB-6300
> URL: https://issues.apache.org/jira/browse/CB-6300
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS, Plugin File
>Affects Versions: 3.3.0
> Environment: file plugin 1.0.1
>Reporter: nii amon dsane
>Assignee: Ian Clelland
>  Labels: camera, file, newbie, plugin, resolveLocalFileSystemURL
>
> I am trying to use the window.resolveLocalFileSystemURL but for some reason 
> my failure callback is always triggered. The success callback is never 
> triggered. This is my code:
> {code}
> // Take a picture using the camera
> $scope.takePicture = function () {
> var options = {
>   quality: 100,
>   targetWidth: 500,
>   targetHeight: 500,
>   destinationType: Camera.DestinationType.FILE_URI,
>   encodingType: Camera.EncodingType.JPEG,
>   saveToPhotoAlbum: true,
>   correctOrientation: true,
>   sourceType: Camera.PictureSourceType.CAMERA,
>   allowEdit: true
> };
> navigator.camera.getPicture(
>   cameraSuccess,
>   cameraFailure,
>   options
> );
> return false;
>   };
>   // what to do when the camera has  successfully yielded a good image
>   function cameraSuccess(imageURI){
> var uri = 'cdv' + imageURI;
> alert('this is imageURI: ' + imageURI);
> window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
>   };
> {code}
>  

[jira] [Comment Edited] (CB-6300) window.resolveLocalFileSystemURL weirdness

[nii amon dsane (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940158#comment-13940158
 ] 

nii amon dsane edited comment on CB-6300 at 3/19/14 4:37 AM:
-

Hey Ian, some feedback.

1. Adding the org.apache.cordova.file-system-roots plugin fixes the filesystem 
resolve issue. Yay!

2. When I have the resolved filesystem path and I try to display it on a page, 
I get a broken link. So somehow, cordova is unable to read the image that's 
referenced by the resolved filesystem path. This is how I am referencing the 
image in the page:


{{
  

image
  
}}

The image path is printed out on the page so I can confirm that it's the 
correct resolved filesystem path.

3. When I select a picture from the gallery, I get a really weird unresolved 
URI: 
file:///storage/sdcard0/Android/data/com.lukaduka.pos/cache/modified.jpg?1395202637809
I suppose the modified.jpg file is a sort of placeholder image and the query 
string timestamp points to the actual picture in the gallery. That's all fine 
as long as the filesystem resolve can point me to the right file in the gallery 
but that doesn't happen. This is the resolved filesystem path I get:

cdvfile://localhost/cache-external/modified.jpg

I suppose that's because the resolve is unable to use the query string part of 
the URI to resolve to the real file in the gallery.

I have saveToPhotoAlbum: true in the options for the camera and I don't know if 
setting that to false and then copying the file to a folder is wise. Ideally, I 
would like all this to be transparent to my code and so should be able to do a 
camera capture and then when selecting from a folder, I get the true file path 
not one to the modified.jpg with a querystring. 


was (Author: niiamon):
Hey Ian, some feedback.

1. Adding the org.apache.cordova.file-system-roots plugin fixes the filesystem 
resolve issue. Yay!

2. When I have the resolved filesystem path and I try to display it on a page, 
I get a broken link. So somehow, cordova is unable to read the image that's 
referenced by the resolved filesystem path. This is how I am referencing the 
image in the page:


{{
  

{{image}}
  
}}

The image path is printed out on the page so I can confirm that it's the 
correct resolved filesystem path.

3. When I select a picture from the gallery, I get a really weird unresolved 
URI: 
file:///storage/sdcard0/Android/data/com.lukaduka.pos/cache/modified.jpg?1395202637809
I suppose the modified.jpg file is a sort of placeholder image and the query 
string timestamp points to the actual picture in the gallery. That's all fine 
as long as the filesystem resolve can point me to the right file in the gallery 
but that doesn't happen. This is the resolved filesystem path I get:

cdvfile://localhost/cache-external/modified.jpg

I suppose that's because the resolve is unable to use the query string part of 
the URI to resolve to the real file in the gallery.

I have saveToPhotoAlbum: true in the options for the camera and I don't know if 
setting that to false and then copying the file to a folder is wise. Ideally, I 
would like all this to be transparent to my code and so should be able to do a 
camera capture and then when selecting from a folder, I get the true file path 
not one to the modified.jpg with a querystring. 

> window.resolveLocalFileSystemURL weirdness
> --
>
> Key: CB-6300
> URL: https://issues.apache.org/jira/browse/CB-6300
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS, Plugin File
>Affects Versions: 3.3.0
> Environment: file plugin 1.0.1
>Reporter: nii amon dsane
>Assignee: Ian Clelland
>  Labels: camera, file, newbie, plugin, resolveLocalFileSystemURL
>
> I am trying to use the window.resolveLocalFileSystemURL but for some reason 
> my failure callback is always triggered. The success callback is never 
> triggered. This is my code:
> {code}
> // Take a picture using the camera
> $scope.takePicture = function () {
> var options = {
>   quality: 100,
>   targetWidth: 500,
>   targetHeight: 500,
>   destinationType: Camera.DestinationType.FILE_URI,
>   encodingType: Camera.EncodingType.JPEG,
>   saveToPhotoAlbum: true,
>   correctOrientation: true,
>   sourceType: Camera.PictureSourceType.CAMERA,
>   allowEdit: true
> };
> navigator.camera.getPicture(
>   cameraSuccess,
>   cameraFailure,
>   options
> );
> return false;
>   };
>   // what to do when the camera has  successfully yielded a good image
>   function cameraSuccess(imageURI){
> var uri = 'cdv' + imageURI;
> alert('this is imageURI: ' + imageURI);
> window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
>   };
> {code}

[jira] [Commented] (CB-6300) window.resolveLocalFileSystemURL weirdness

[nii amon dsane (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940158#comment-13940158
 ] 

nii amon dsane commented on CB-6300:


Hey Ian, some feedback.

1. Adding the org.apache.cordova.file-system-roots plugin fixes the filesystem 
resolve issue. Yay!

2. When I have the resolved filesystem path and I try to display it on a page, 
I get a broken link. So somehow, cordova is unable to read the image that's 
referenced by the resolved filesystem path. This is how I am referencing the 
image in the page:


  

{{image}}
  


The image path is printed out on the page so I can confirm that it's the 
correct resolved filesystem path.

3. When I select a picture from the gallery, I get a really weird unresolved 
URI: 
file:///storage/sdcard0/Android/data/com.lukaduka.pos/cache/modified.jpg?1395202637809
I suppose the modified.jpg file is a sort of placeholder image and the query 
string timestamp points to the actual picture in the gallery. That's all fine 
as long as the filesystem resolve can point me to the right file in the gallery 
but that doesn't happen. This is the resolved filesystem path I get:

cdvfile://localhost/cache-external/modified.jpg

I suppose that's because the resolve is unable to use the query string part of 
the URI to resolve to the real file in the gallery.

I have saveToPhotoAlbum: true in the options for the camera and I don't know if 
setting that to false and then copying the file to a folder is wise. Ideally, I 
would like all this to be transparent to my code and so should be able to do a 
camera capture and then when selecting from a folder, I get the true file path 
not one to the modified.jpg with a querystring. 

> window.resolveLocalFileSystemURL weirdness
> --
>
> Key: CB-6300
> URL: https://issues.apache.org/jira/browse/CB-6300
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS, Plugin File
>Affects Versions: 3.3.0
> Environment: file plugin 1.0.1
>Reporter: nii amon dsane
>Assignee: Ian Clelland
>  Labels: camera, file, newbie, plugin, resolveLocalFileSystemURL
>
> I am trying to use the window.resolveLocalFileSystemURL but for some reason 
> my failure callback is always triggered. The success callback is never 
> triggered. This is my code:
> {code}
> // Take a picture using the camera
> $scope.takePicture = function () {
> var options = {
>   quality: 100,
>   targetWidth: 500,
>   targetHeight: 500,
>   destinationType: Camera.DestinationType.FILE_URI,
>   encodingType: Camera.EncodingType.JPEG,
>   saveToPhotoAlbum: true,
>   correctOrientation: true,
>   sourceType: Camera.PictureSourceType.CAMERA,
>   allowEdit: true
> };
> navigator.camera.getPicture(
>   cameraSuccess,
>   cameraFailure,
>   options
> );
> return false;
>   };
>   // what to do when the camera has  successfully yielded a good image
>   function cameraSuccess(imageURI){
> var uri = 'cdv' + imageURI;
> alert('this is imageURI: ' + imageURI);
> window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
>   };
> {code}
>   When I print out the imageURI, I get something like this:
>   file:///storage/sdcard0/DCIM/Camera/1395126124474.jpg
>   I can confirm that when I look at that path using the Files application on 
> an   android, the file is indeed there. But when the code runs and it 
> executes the window.resolveLocalFileSystemURL, the fail callback is always 
> triggered with an error of \{"code":5}.
> I've seen that that means there's an ENCODING_ERR but a bit baffled as to 
> what is causing that. The file does save properly to that location so I am at 
> a loss at to why the code will fail.
> Any help here?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CB-6300) window.resolveLocalFileSystemURL weirdness

[nii amon dsane (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940158#comment-13940158
 ] 

nii amon dsane edited comment on CB-6300 at 3/19/14 4:36 AM:
-

Hey Ian, some feedback.

1. Adding the org.apache.cordova.file-system-roots plugin fixes the filesystem 
resolve issue. Yay!

2. When I have the resolved filesystem path and I try to display it on a page, 
I get a broken link. So somehow, cordova is unable to read the image that's 
referenced by the resolved filesystem path. This is how I am referencing the 
image in the page:

{{

  

{{image}}
  

}}

The image path is printed out on the page so I can confirm that it's the 
correct resolved filesystem path.

3. When I select a picture from the gallery, I get a really weird unresolved 
URI: 
file:///storage/sdcard0/Android/data/com.lukaduka.pos/cache/modified.jpg?1395202637809
I suppose the modified.jpg file is a sort of placeholder image and the query 
string timestamp points to the actual picture in the gallery. That's all fine 
as long as the filesystem resolve can point me to the right file in the gallery 
but that doesn't happen. This is the resolved filesystem path I get:

cdvfile://localhost/cache-external/modified.jpg

I suppose that's because the resolve is unable to use the query string part of 
the URI to resolve to the real file in the gallery.

I have saveToPhotoAlbum: true in the options for the camera and I don't know if 
setting that to false and then copying the file to a folder is wise. Ideally, I 
would like all this to be transparent to my code and so should be able to do a 
camera capture and then when selecting from a folder, I get the true file path 
not one to the modified.jpg with a querystring. 


was (Author: niiamon):
Hey Ian, some feedback.

1. Adding the org.apache.cordova.file-system-roots plugin fixes the filesystem 
resolve issue. Yay!

2. When I have the resolved filesystem path and I try to display it on a page, 
I get a broken link. So somehow, cordova is unable to read the image that's 
referenced by the resolved filesystem path. This is how I am referencing the 
image in the page:


  

{{image}}
  


The image path is printed out on the page so I can confirm that it's the 
correct resolved filesystem path.

3. When I select a picture from the gallery, I get a really weird unresolved 
URI: 
file:///storage/sdcard0/Android/data/com.lukaduka.pos/cache/modified.jpg?1395202637809
I suppose the modified.jpg file is a sort of placeholder image and the query 
string timestamp points to the actual picture in the gallery. That's all fine 
as long as the filesystem resolve can point me to the right file in the gallery 
but that doesn't happen. This is the resolved filesystem path I get:

cdvfile://localhost/cache-external/modified.jpg

I suppose that's because the resolve is unable to use the query string part of 
the URI to resolve to the real file in the gallery.

I have saveToPhotoAlbum: true in the options for the camera and I don't know if 
setting that to false and then copying the file to a folder is wise. Ideally, I 
would like all this to be transparent to my code and so should be able to do a 
camera capture and then when selecting from a folder, I get the true file path 
not one to the modified.jpg with a querystring. 

> window.resolveLocalFileSystemURL weirdness
> --
>
> Key: CB-6300
> URL: https://issues.apache.org/jira/browse/CB-6300
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS, Plugin File
>Affects Versions: 3.3.0
> Environment: file plugin 1.0.1
>Reporter: nii amon dsane
>Assignee: Ian Clelland
>  Labels: camera, file, newbie, plugin, resolveLocalFileSystemURL
>
> I am trying to use the window.resolveLocalFileSystemURL but for some reason 
> my failure callback is always triggered. The success callback is never 
> triggered. This is my code:
> {code}
> // Take a picture using the camera
> $scope.takePicture = function () {
> var options = {
>   quality: 100,
>   targetWidth: 500,
>   targetHeight: 500,
>   destinationType: Camera.DestinationType.FILE_URI,
>   encodingType: Camera.EncodingType.JPEG,
>   saveToPhotoAlbum: true,
>   correctOrientation: true,
>   sourceType: Camera.PictureSourceType.CAMERA,
>   allowEdit: true
> };
> navigator.camera.getPicture(
>   cameraSuccess,
>   cameraFailure,
>   options
> );
> return false;
>   };
>   // what to do when the camera has  successfully yielded a good image
>   function cameraSuccess(imageURI){
> var uri = 'cdv' + imageURI;
> alert('this is imageURI: ' + imageURI);
> window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
>   };
> {code}

[jira] [Resolved] (CB-6307) minor bugs in coho when non-standard release

[Marcel Kinard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Kinard resolved CB-6307.
---

Resolution: Fixed

> minor bugs in coho when non-standard release
> 
>
> Key: CB-6307
> URL: https://issues.apache.org/jira/browse/CB-6307
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Coho
>Reporter: Marcel Kinard
>Assignee: Marcel Kinard
>Priority: Minor
> Fix For: 3.5.0
>
>
> While using coho on our own distribution, I ran into a few minor bugs:
> - re-execing with the modified ulimit would hide all the output and mask 
> non-zero rc when there was an error. It should show the output and let the 
> non-zero rc cascade out.
> - the "\-\-sign" argv for create-archive was not properly typed to boolean. 
> So doing "\-\-sign false" did not have the intended result.
> - if not signing the archive, it still failed if 'gpg' was not present.
> - when unzipping the zip archive of the source, there is no leading prefix. 
> Thus when unzipping multiple repo archives, they will step on each other 
> unless you first manually create separate subdirectories for each repo zip. 
> Although this isn't technically an error, I think it would more friendly if 
> the zips were already separated into different subdirectories when you unzip 
> them. If there is a reason why my modified behavior in undesirable, please 
> let me know.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6307) minor bugs in coho when non-standard release

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940112#comment-13940112
 ] 

ASF subversion and git services commented on CB-6307:
-

Commit 32ab0c9a634070fb74246b9caab3d7f4f0c9f163 in cordova-coho's branch 
refs/heads/master from [~cmarcelk]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-coho.git;h=32ab0c9 ]

CB-6307 minor bugs

- re-execing with the modified ulimit would hide all the output and mask
  non-zero rc when there was an error. It should show the output and let the
  non-zero rc cascade out.
- the "--sign" argv for create-archive was not properly typed to boolean. So
  doing "--sign false" did not have the intended result.
- if not signing the archive, it still failed if 'gpg' was not present.
- when unzipping the zip archive of the source, there is no leading prefix.
  Thus when unzipping multiple repo archives, they will step on each other
  unless you first manually create separate subdirectories for each repo zip.
  Although this isn't technically an error, I think it would more friendly if
  the zips were already separated into different subdirectories when you unzip
  them.


> minor bugs in coho when non-standard release
> 
>
> Key: CB-6307
> URL: https://issues.apache.org/jira/browse/CB-6307
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Coho
>Reporter: Marcel Kinard
>Assignee: Marcel Kinard
>Priority: Minor
> Fix For: 3.5.0
>
>
> While using coho on our own distribution, I ran into a few minor bugs:
> - re-execing with the modified ulimit would hide all the output and mask 
> non-zero rc when there was an error. It should show the output and let the 
> non-zero rc cascade out.
> - the "\-\-sign" argv for create-archive was not properly typed to boolean. 
> So doing "\-\-sign false" did not have the intended result.
> - if not signing the archive, it still failed if 'gpg' was not present.
> - when unzipping the zip archive of the source, there is no leading prefix. 
> Thus when unzipping multiple repo archives, they will step on each other 
> unless you first manually create separate subdirectories for each repo zip. 
> Although this isn't technically an error, I think it would more friendly if 
> the zips were already separated into different subdirectories when you unzip 
> them. If there is a reason why my modified behavior in undesirable, please 
> let me know.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CB-6307) minor bugs in coho when non-standard release

[Marcel Kinard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Kinard updated CB-6307:
--

Description: 
While using coho on our own distribution, I ran into a few minor bugs:

- re-execing with the modified ulimit would hide all the output and mask 
non-zero rc when there was an error. It should show the output and let the 
non-zero rc cascade out.
- the "\-\-sign" argv for create-archive was not properly typed to boolean. So 
doing "\-\-sign false" did not have the intended result.
- if not signing the archive, it still failed if 'gpg' was not present.
- when unzipping the zip archive of the source, there is no leading prefix. 
Thus when unzipping multiple repo archives, they will step on each other unless 
you first manually create separate subdirectories for each repo zip. Although 
this isn't technically an error, I think it would more friendly if the zips 
were already separated into different subdirectories when you unzip them. If 
there is a reason why my modified behavior in undesirable, please let me know.

  was:
While using coho on our own distribution, I ran into a few minor bugs:

- re-execing with the modified ulimit would hide all the output and mask 
non-zero rc when there was an error. It should show the output and let the 
non-zero rc cascade out.
- the "--sign" argv for create-archive was not properly typed to boolean. So 
doing "--sign false" did not have the intended result.
- if not signing the archive, it still failed if 'gpg' was not present.
- when unzipping the zip archive of the source, there is no leading prefix. 
Thus when unzipping multiple repo archives, they will step on each other unless 
you first manually create separate subdirectories for each repo zip. Although 
this isn't technically an error, I think it would more friendly if the zips 
were already separated into different subdirectories when you unzip them. If 
there is a reason why my modified behavior in undesirable, please let me know.


> minor bugs in coho when non-standard release
> 
>
> Key: CB-6307
> URL: https://issues.apache.org/jira/browse/CB-6307
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Coho
>Reporter: Marcel Kinard
>Assignee: Marcel Kinard
>Priority: Minor
> Fix For: 3.5.0
>
>
> While using coho on our own distribution, I ran into a few minor bugs:
> - re-execing with the modified ulimit would hide all the output and mask 
> non-zero rc when there was an error. It should show the output and let the 
> non-zero rc cascade out.
> - the "\-\-sign" argv for create-archive was not properly typed to boolean. 
> So doing "\-\-sign false" did not have the intended result.
> - if not signing the archive, it still failed if 'gpg' was not present.
> - when unzipping the zip archive of the source, there is no leading prefix. 
> Thus when unzipping multiple repo archives, they will step on each other 
> unless you first manually create separate subdirectories for each repo zip. 
> Although this isn't technically an error, I think it would more friendly if 
> the zips were already separated into different subdirectories when you unzip 
> them. If there is a reason why my modified behavior in undesirable, please 
> let me know.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CB-6307) minor bugs in coho when non-standard release

[Marcel Kinard (JIRA)]

Marcel Kinard created CB-6307:
-

 Summary: minor bugs in coho when non-standard release
 Key: CB-6307
 URL: https://issues.apache.org/jira/browse/CB-6307
 Project: Apache Cordova
  Issue Type: Bug
  Components: Coho
Reporter: Marcel Kinard
Assignee: Marcel Kinard
Priority: Minor
 Fix For: 3.5.0


While using coho on our own distribution, I ran into a few minor bugs:

- re-execing with the modified ulimit would hide all the output and mask 
non-zero rc when there was an error. It should show the output and let the 
non-zero rc cascade out.
- the "--sign" argv for create-archive was not properly typed to boolean. So 
doing "--sign false" did not have the intended result.
- if not signing the archive, it still failed if 'gpg' was not present.
- when unzipping the zip archive of the source, there is no leading prefix. 
Thus when unzipping multiple repo archives, they will step on each other unless 
you first manually create separate subdirectories for each repo zip. Although 
this isn't technically an error, I think it would more friendly if the zips 
were already separated into different subdirectories when you unzip them. If 
there is a reason why my modified behavior in undesirable, please let me know.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CB-6160) adding plugin fails for Firefoxos.

[Piotr Zalewa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940024#comment-13940024
 ] 

Piotr Zalewa edited comment on CB-6160 at 3/19/14 12:45 AM:


As far as I can see this merge is actually in master here: 
https://github.com/apache/cordova-plugman/blob/master/src/platforms/firefoxos.js#L4
Can we please ship it?


was (Author: zalun):
As far as I can get this merge is actually in master here: 
https://github.com/apache/cordova-plugman/blob/master/src/platforms/firefoxos.js#L4
Can we please ship it?

> adding plugin fails for Firefoxos. 
> ---
>
> Key: CB-6160
> URL: https://issues.apache.org/jira/browse/CB-6160
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugman
>Reporter: Gert-Jan Braas
>Priority: Blocker
>
> reason:  
> No xml_helpers defined ( in src/platforms/firefoxos.js)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6160) adding plugin fails for Firefoxos.

[Piotr Zalewa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940024#comment-13940024
 ] 

Piotr Zalewa commented on CB-6160:
--

As far as I can get this merge is actually in master here: 
https://github.com/apache/cordova-plugman/blob/master/src/platforms/firefoxos.js#L4
Can we please ship it?

> adding plugin fails for Firefoxos. 
> ---
>
> Key: CB-6160
> URL: https://issues.apache.org/jira/browse/CB-6160
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugman
>Reporter: Gert-Jan Braas
>Priority: Blocker
>
> reason:  
> No xml_helpers defined ( in src/platforms/firefoxos.js)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6160) adding plugin fails for Firefoxos.

[Piotr Zalewa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940010#comment-13940010
 ] 

Piotr Zalewa commented on CB-6160:
--

Ping. What test should be run to test plugman?
We need this shipped. I believe bug was introduced in 0.20.1 or 0.20.2
I will try tomorrow, but I haven't been working on plugman yet

> adding plugin fails for Firefoxos. 
> ---
>
> Key: CB-6160
> URL: https://issues.apache.org/jira/browse/CB-6160
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugman
>Reporter: Gert-Jan Braas
>Priority: Blocker
>
> reason:  
> No xml_helpers defined ( in src/platforms/firefoxos.js)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6146) FileTransfer.upload does not support iOS asset library type of URL

[Farhad Farzaneh (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939982#comment-13939982
 ] 

Farhad Farzaneh commented on CB-6146:
-

Hi, I did manage to test the new File plugin and it *does* seem to be working 
in our application for camera roll images.

> FileTransfer.upload does not support iOS asset library type of URL
> --
>
> Key: CB-6146
> URL: https://issues.apache.org/jira/browse/CB-6146
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 3.3.0
> Environment: Macbook Air, 10.9
>Reporter: Farhad Farzaneh
>Assignee: Ian Clelland
>
> When picking an image from the camera roll and using a NATIVE_URL type, the 
> url may be something like: 
> {{assets-library://asset/asset.PNG?id=CFDB9708-75A2-44A9-9092-FCE1DB471B30&ext=PNG}}.
>   When this is presented as the localURL to {{[CDVFileTransfer 
> fileDataForUploadCommand:]}} it recognizes the file system to be the asset 
> library and tries to read the file from the indicated URL using 
> {{[CDVAssetLibraryFilesystem readFileAtURL:]}}. I'm not sure why this method 
> tries to pull back the path from the URL with
> {code}
> NSString *path = [self fileSystemPathForURL:localURL];
> {code}
> and then rebuild the URL from that path below (line 223).  However, the 
> returned path is {{@"/asset.PNG"}}, which when used to retrieve the asset 
> fails.  
> If the line (CDVAssetLibraryFilesystem.m: 223)
> {code}
> [assetsLibrary assetForURL:[NSURL URLWithString:path] resultBlock:resultBlock 
> failureBlock:failureBlock];
> {code}
> is changed for
> {code}
> [assetsLibrary assetForURL:localURL.url resultBlock:resultBlock 
> failureBlock:failureBlock];
> {code}
> then the asset can be found.  But of course this was done for a reason, so I 
> imagine my fix breaks something else...
>  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CB-1291) Windows 8 Contacts - Find+Create APIs

[Jesse MacFadyen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesse MacFadyen resolved CB-1291.
-

Resolution: Fixed

Resolved where possible.
The Windows 8 version of the contacts.find API spawn a system dialog where the 
user must pick one or more contacts.  The contacts are returned to the cordova 
app with the same properties as the other platforms, where available.  Docs are 
updated to include #quirks.

> Windows 8 Contacts - Find+Create APIs
> -
>
> Key: CB-1291
> URL: https://issues.apache.org/jira/browse/CB-1291
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Contacts, Windows 8
>Reporter: Jesse MacFadyen
>Assignee: Jesse MacFadyen
>
> It looks like we will need to approach Contacts on Windows 8 differently.
> The goal of the Contacts API is not to have every app become a 
> ContactProvider, which would result in chaos ... 
> Windows 8 does not have built in contacts, they are managed internally by the 
> People app.  The People app is a ContactProvider  so when you are performing 
> an operation that requires a contact, you are given the opportunity to select 
> one or more contacts from the People app, as well as every other app that 
> publishes the ContactProvider contract.
> Searching contacts cannot be achieved given Windows 8 APIs and interaction 
> with the People app, but the primary use case of picking one or more contacts 
> to interact with can work.
> I think the best approach would be to return a contact object as defined by 
> PhoneGap APIs, but allow the user to actually do the selection ( via the 
> picker )
> Here is a good write-up by a Microsoft evangelist about how contacts work on 
> Windows 8.
> http://blogs.msdn.com/b/glengordon/archive/2012/08/28/windows-8-apps-for-the-phonegap-developer-contacts.aspx



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6299) Ajax of local files not working when requested via absolute URL

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939954#comment-13939954
 ] 

ASF GitHub Bot commented on CB-6299:


Github user purplecabbage commented on the pull request:

https://github.com/apache/cordova-wp8/pull/30#issuecomment-38001455
  
@gabrielschulhof 
Can you provide a test case that demonstrates the issue?
I thought this would do it, but it seems to load regardless of whether the 
patch is applied.
```
var xhr = new XMLHttpRequest();
xhr.onload = function () {
console.log("loaded");
}
var loc = window.location.toString() + "#Hoopla";
xhr.open("GET", loc, true);
xhr.send();
```


> Ajax of local files not working when requested via absolute URL
> ---
>
> Key: CB-6299
> URL: https://issues.apache.org/jira/browse/CB-6299
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: WP7, WP8
>Reporter: Gabriel Schulhof
>Assignee: Jesse MacFadyen
>
> The code does not properly strip slashes from the path name when the URL is 
> absolute, because in that case the path name is prefixed with the protocol, 
> so the protocol must be stripped off first.
> References:
> https://github.com/jquery/jquery-mobile/issues/6574



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-5520) Should we add "DEBUG=1" to "Preprocessor Macros"->"Debug" ?

[Shazron Abdullah (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939906#comment-13939906
 ] 

Shazron Abdullah commented on CB-5520:
--

Yeah and possibly plugman/cordova CLI updates to Build Settings, possibly 
without having to muck with the .pbxproj. I'll try to export all the project 
settings to .xcconfig style, and prune it

> Should we add "DEBUG=1" to "Preprocessor Macros"->"Debug" ?
> ---
>
> Key: CB-5520
> URL: https://issues.apache.org/jira/browse/CB-5520
> Project: Apache Cordova
>  Issue Type: Wish
>  Components: iOS
>Affects Versions: 3.2.0
>Reporter: glmnbeyond
>Assignee: Shazron Abdullah
>Priority: Minor
>  Labels: core
>
> I created a helloCordova project via Cordova CLI, and added some debug info 
> to native code:
> DLog('This is a debug info');
> But the debug info is never outputted.If I use  ALog, the info can be 
> outputted, so I think it probably has something to do with the "DEBUG" macro.
> After I added "DEBUG=1" to "Preprocessor Macros", ran the helloCordova 
> target, DLog can be outputted.
> So here is my question:
> Should we add "DEBUG=1" to iOS template project->"Build Settings"-> 
> "Preprocessor Macros" ->"Debug" ?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6306) Error creating project when path to project includes spaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939877#comment-13939877
 ] 

ASF GitHub Bot commented on CB-6306:


GitHub user jsoref opened a pull request:

https://github.com/apache/cordova-cli/pull/143

CB-6306 Error creating project when path to project includes spaces

https://issues.apache.org/jira/browse/CB-6306

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/blackberry/cordova-cli cb_6306

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-cli/pull/143.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #143


commit 5039abccb4d9df80da45b858fcc161e09254
Author: Josh Soref 
Date:   2014-03-18T22:06:27Z

CB-6306 Error creating project when path to project includes spaces




> Error creating project when path to project includes spaces
> ---
>
> Key: CB-6306
> URL: https://issues.apache.org/jira/browse/CB-6306
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CLI
>Affects Versions: 3.5.0
>Reporter: Josh Soref
>Assignee: Josh Soref
>Priority: Blocker
>
> 1. C:\Documents and Settings\IEUser>webworks create hello 
> --- Actual Result: --- 
> 'C:\Documents' is not recognized as an internal or external command, 
> operable program or batch file. 
> { [Error: cmd: Command failed with exit code 1] code: 1 } 
> - project is created without blackberry10 platform added 
> --- Expected Result: --- 
> - project is created with blackberry10 platform added 
> This is because of the superspawn rewrite which doesn't take into account the 
> absolute importance of the '/s' flag in child_process (for cmd)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CB-6306) Error creating project when CWD includes spaces

[Josh Soref (JIRA)]

Josh Soref created CB-6306:
--

 Summary: Error creating project when CWD includes spaces
 Key: CB-6306
 URL: https://issues.apache.org/jira/browse/CB-6306
 Project: Apache Cordova
  Issue Type: Bug
  Components: CLI
Affects Versions: 3.5.0
Reporter: Josh Soref
Assignee: Josh Soref
Priority: Blocker


1. C:\Documents and Settings\IEUser>webworks create hello 

--- Actual Result: --- 
'C:\Documents' is not recognized as an internal or external command, 
operable program or batch file. 
{ [Error: cmd: Command failed with exit code 1] code: 1 } 
- project is created without blackberry10 platform added 

--- Expected Result: --- 
- project is created with blackberry10 platform added 

This is because of the superspawn rewrite which doesn't take into account the 
absolute importance of the '/s' flag in child_process (for cmd)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CB-6306) Error creating project when path to project includes spaces

[Josh Soref (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Soref updated CB-6306:
---

Summary: Error creating project when path to project includes spaces  (was: 
Error creating project when CWD includes spaces)

> Error creating project when path to project includes spaces
> ---
>
> Key: CB-6306
> URL: https://issues.apache.org/jira/browse/CB-6306
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CLI
>Affects Versions: 3.5.0
>Reporter: Josh Soref
>Assignee: Josh Soref
>Priority: Blocker
>
> 1. C:\Documents and Settings\IEUser>webworks create hello 
> --- Actual Result: --- 
> 'C:\Documents' is not recognized as an internal or external command, 
> operable program or batch file. 
> { [Error: cmd: Command failed with exit code 1] code: 1 } 
> - project is created without blackberry10 platform added 
> --- Expected Result: --- 
> - project is created with blackberry10 platform added 
> This is because of the superspawn rewrite which doesn't take into account the 
> absolute importance of the '/s' flag in child_process (for cmd)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CB-6276) HideKeyboardFormAccessoryBar + KeyboardShrinksView = all-white keyboard background

[Shazron Abdullah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shazron Abdullah updated CB-6276:
-

Component/s: Plugins

> HideKeyboardFormAccessoryBar + KeyboardShrinksView = all-white keyboard 
> background
> --
>
> Key: CB-6276
> URL: https://issues.apache.org/jira/browse/CB-6276
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS, Plugins
>Affects Versions: 3.4.0
> Environment: ios7.1 
>Reporter: Udo Schroeter
>  Labels: ios7.1, keyboard-plugin
> Attachments: iOS Simulator Screen shot Mar 15, 2014, 11.05.25 AM.png
>
>
> Using the Cordova keyboard plugin, when turning on KeyboardShrinksView and 
> HideKeyboardFormAccessoryBar together, the keyboard's background becomes 
> white, so you get white keys on white background. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CB-6305) cordova 3.4 cordovalib created without arm64 architecture support

[Shazron Abdullah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shazron Abdullah resolved CB-6305.
--

   Resolution: Duplicate
Fix Version/s: 3.5.0
 Assignee: Shazron Abdullah

This has been resolved in 3.5.0
See CB-4863


> cordova 3.4 cordovalib created without arm64 architecture support
> -
>
> Key: CB-6305
> URL: https://issues.apache.org/jira/browse/CB-6305
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 3.4.0
> Environment: ios7.1, mac osx 10.9.2, xcode 5.1 build 5B130a
>Reporter: Farhad Farzaneh
>Assignee: Shazron Abdullah
>Priority: Minor
> Fix For: 3.5.0
>
>
> Create a new project.  The CordovaLib build rules do not include the arm64 
> target, but the project ones do, and the "build active architecture only" 
> flag is set to true.  So when building for an iphone5S, it fails to link.  
> Need to either update the project or CordovaLib build rules to make their 
> architectures match, or change the build flag.  It's not a great experience 
> when building the "Hello World" or initial app.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6274) iOS should support backgroundColor in config.xml

[Shazron Abdullah (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939857#comment-13939857
 ] 

Shazron Abdullah commented on CB-6274:
--

See http://stackoverflow.com/a/6605214/219684
This is probably the superview color. Not sure of performance impact.

> iOS should support backgroundColor in config.xml
> 
>
> Key: CB-6274
> URL: https://issues.apache.org/jira/browse/CB-6274
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: iOS
>Reporter: Jesse MacFadyen
>Priority: Minor
>
> http://cordova.apache.org/docs/en/3.4.0/config_ref_index.md.html#The%20config.xml%20File



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CB-6287) Add build script support for arm64

[Shazron Abdullah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shazron Abdullah updated CB-6287:
-

Summary: Add build script support for arm64  (was: Should build script add 
support for arm64?)

> Add build script support for arm64
> --
>
> Key: CB-6287
> URL: https://issues.apache.org/jira/browse/CB-6287
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: glmnbeyond
> Fix For: 3.5.0
>
>
> Currently, build script specify VALID_ARCHS as "armv7 armv7s", should we add 
> arm64 to VALID_ARCHS?
> exec xcodebuild -xcconfig "$CORDOVA_PATH/build.xcconfig" -project 
> "$PROJECT_NAME.xcodeproj" ARCHS="armv7 armv7s" -target "$PROJECT_NAME" 
> -configuration $CONFIGURATION -sdk iphoneos build VALID_ARCHS="armv7 armv7s" 
> CONFIGURATION_BUILD_DIR="$PROJECT_PATH/build/device"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CB-6287) Should build script add support for arm64?

[Shazron Abdullah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shazron Abdullah updated CB-6287:
-

Fix Version/s: 3.5.0

> Should build script add support for arm64?
> --
>
> Key: CB-6287
> URL: https://issues.apache.org/jira/browse/CB-6287
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: glmnbeyond
> Fix For: 3.5.0
>
>
> Currently, build script specify VALID_ARCHS as "armv7 armv7s", should we add 
> arm64 to VALID_ARCHS?
> exec xcodebuild -xcconfig "$CORDOVA_PATH/build.xcconfig" -project 
> "$PROJECT_NAME.xcodeproj" ARCHS="armv7 armv7s" -target "$PROJECT_NAME" 
> -configuration $CONFIGURATION -sdk iphoneos build VALID_ARCHS="armv7 armv7s" 
> CONFIGURATION_BUILD_DIR="$PROJECT_PATH/build/device"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CB-6277) Inappbrowser problem with ios 7.1 statusbar

[Shazron Abdullah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shazron Abdullah updated CB-6277:
-

Component/s: Plugin Statusbar
 Plugin InAppBrowser

> Inappbrowser problem with ios 7.1 statusbar
> ---
>
> Key: CB-6277
> URL: https://issues.apache.org/jira/browse/CB-6277
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS, Plugin InAppBrowser, Plugin Statusbar
>Affects Versions: 3.4.0
> Environment: Cordova 3.4 (maybe also bellow) Xcode 5.1, iOS 7.1
>Reporter: Miguel Lemos
>  Labels: inappbrowser, ios7.1, patch, statusbar
>
> Whatever I do to configure the status bar, when I enter in an external page 
> via Inappbrowser, the status bar always conflicts (overlaps) with the content.
> Due to the fact that the status bar inside the browser is always transparent 
> (this is the problem), when I scroll the content it overlaps the text of the 
> status bar.
> I can remove the status bar (not a good solution...) but I would like to have 
> it back when I return to the app, but this is not possible.
> The status bar definitions made regarding the app, should also affect the 
> inappbrowser content, but that doesn't happen. 
> I think anyway that Apple will not allow this situation.
> The Statusbar plugin can't either configure the status bar for the pages 
> opened with Inappbrowser and thus solve the problem. I can´t, for instance,  
> use a StatusBar.hide() and show() back and forth.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6287) Should build script add support for arm64?

[Shazron Abdullah (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939853#comment-13939853
 ] 

Shazron Abdullah commented on CB-6287:
--

With the upcoming 3.5.0, at least with the iOS core code, there should be no 
warnings. The plugins are on a different release schedule, and James is working 
on fixing the warnings.

> Should build script add support for arm64?
> --
>
> Key: CB-6287
> URL: https://issues.apache.org/jira/browse/CB-6287
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: glmnbeyond
> Fix For: 3.5.0
>
>
> Currently, build script specify VALID_ARCHS as "armv7 armv7s", should we add 
> arm64 to VALID_ARCHS?
> exec xcodebuild -xcconfig "$CORDOVA_PATH/build.xcconfig" -project 
> "$PROJECT_NAME.xcodeproj" ARCHS="armv7 armv7s" -target "$PROJECT_NAME" 
> -configuration $CONFIGURATION -sdk iphoneos build VALID_ARCHS="armv7 armv7s" 
> CONFIGURATION_BUILD_DIR="$PROJECT_PATH/build/device"



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CB-6295) Guide Platform Support links for plugins are bad

[Shazron Abdullah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shazron Abdullah resolved CB-6295.
--

Resolution: Fixed

> Guide Platform Support links for plugins are bad
> 
>
> Key: CB-6295
> URL: https://issues.apache.org/jira/browse/CB-6295
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs
>Affects Versions: 3.4.0
>Reporter: Josh Soref
>
> http://cordova.apache.org/docs/en/3.4.0/guide_support_index.md.html#Platform%20Support
> The plugins links don't work because plugin documentation no longer lives in 
> the cordova-docs repo.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CB-6289) Keyboard for Android

[Shazron Abdullah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shazron Abdullah updated CB-6289:
-

Assignee: Andrey Kurdyumov

> Keyboard for Android
> 
>
> Key: CB-6289
> URL: https://issues.apache.org/jira/browse/CB-6289
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Plugins
> Environment: Android
>Reporter: Andrey Kurdyumov
>Assignee: Andrey Kurdyumov
>Priority: Minor
>  Labels: keyboard-plugin
>
> Please extend the Keyboard plugin to support Android platform.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-4051) Splashscreen rotation problem

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939811#comment-13939811
 ] 

ASF GitHub Bot commented on CB-4051:


Github user shazron commented on the pull request:


https://github.com/apache/cordova-plugin-splashscreen/pull/13#issuecomment-37989527
  
Hmm, your first commit reverts https://issues.apache.org/jira/browse/CB-4051
Would my last comment in the issue (where I replace the || operator with an 
&& operator) fix the issue as well?


> Splashscreen rotation problem
> -
>
> Key: CB-4051
> URL: https://issues.apache.org/jira/browse/CB-4051
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 2.7.0
>Reporter: Estelle
>Assignee: Shazron Abdullah
>
> On Cordova 2.7
> I have made an application iPhone with Cordova, my application is only on 
> landscape mode. I have added splashscreens on the app and seen a bug.
> When I launch app, I see correctly the good splashscreen but after view 
> seconds the splashscreen rotate on 90°
> I think it's a bug because all params in XML, Xcode and plist are in 
> landscape mode.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-5767) Keyboard will/did hide/show events should be passed to JavaScript

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939795#comment-13939795
 ] 

ASF GitHub Bot commented on CB-5767:


Github user shazron commented on the pull request:

https://github.com/apache/cordova-plugins/pull/7#issuecomment-37988423
  
Merged in: 
https://git-wip-us.apache.org/repos/asf?p=cordova-plugins.git;h=80561e4
You can close this PR now


> Keyboard will/did hide/show events should be passed to JavaScript
> -
>
> Key: CB-5767
> URL: https://issues.apache.org/jira/browse/CB-5767
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Affects Versions: 3.0.0, 3.1.0, 3.2.0, 3.3.0
> Environment: iOS 7
>Reporter: Paul Hickman
>Assignee: Shazron Abdullah
>  Labels: ios7, keyboard-plugin
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> In order to resolve the issues iOS 7 creates with the keyboard shrinking the 
> view, our project needs the KeyboardWillShow, KeyboardDidShow, 
> KeyboardWillHide and KeyboardDidHide native events to be raised by the 
> keyboard plugin as JavaScript events, so that we can show/hide some HTML 
> elements.
> Would it be possible to add observers for the "Will" events as well as the 
> "Did" events, and then make all four observers execute some JavaScript to 
> trigger events in the DOM.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CB-5767) Keyboard will/did hide/show events should be passed to JavaScript

[Shazron Abdullah (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shazron Abdullah resolved CB-5767.
--

Resolution: Fixed
  Assignee: Shazron Abdullah

> Keyboard will/did hide/show events should be passed to JavaScript
> -
>
> Key: CB-5767
> URL: https://issues.apache.org/jira/browse/CB-5767
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Affects Versions: 3.0.0, 3.1.0, 3.2.0, 3.3.0
> Environment: iOS 7
>Reporter: Paul Hickman
>Assignee: Shazron Abdullah
>  Labels: ios7, keyboard-plugin
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> In order to resolve the issues iOS 7 creates with the keyboard shrinking the 
> view, our project needs the KeyboardWillShow, KeyboardDidShow, 
> KeyboardWillHide and KeyboardDidHide native events to be raised by the 
> keyboard plugin as JavaScript events, so that we can show/hide some HTML 
> elements.
> Would it be possible to add observers for the "Will" events as well as the 
> "Did" events, and then make all four observers execute some JavaScript to 
> trigger events in the DOM.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-5767) Keyboard will/did hide/show events should be passed to JavaScript

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939794#comment-13939794
 ] 

ASF subversion and git services commented on CB-5767:
-

Commit 80561e433ada6cd7f30dfce01fe6c8034cc124f2 in cordova-plugins's branch 
refs/heads/master from [~akurdyumov]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-plugins.git;h=80561e4 ]

CB-5767 - Keyboard will/did hide/show events should be passed to JavaScript


> Keyboard will/did hide/show events should be passed to JavaScript
> -
>
> Key: CB-5767
> URL: https://issues.apache.org/jira/browse/CB-5767
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Affects Versions: 3.0.0, 3.1.0, 3.2.0, 3.3.0
> Environment: iOS 7
>Reporter: Paul Hickman
>  Labels: ios7, keyboard-plugin
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> In order to resolve the issues iOS 7 creates with the keyboard shrinking the 
> view, our project needs the KeyboardWillShow, KeyboardDidShow, 
> KeyboardWillHide and KeyboardDidHide native events to be raised by the 
> keyboard plugin as JavaScript events, so that we can show/hide some HTML 
> elements.
> Would it be possible to add observers for the "Will" events as well as the 
> "Did" events, and then make all four observers execute some JavaScript to 
> trigger events in the DOM.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CB-5488) deviceready event not firing with jQuery Mobile

[Garth Gutenberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939710#comment-13939710
 ] 

Garth Gutenberg edited comment on CB-5488 at 3/18/14 8:32 PM:
--

Same issue for me (Cordova 3.4.0-0.1.3).  Using Sencha Touch, not jQuery 
Mobile.  The ST code loads after this block.  Following is the script tag load 
order:

{code}
https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >




{code}

Note that moving cordova.js to the top of the list of scripts has no effect, 
other than the error occurring sooner.  I.e., the following throws the same 
error:

{code}

https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >



{code}

FYI, rolling back to Cordova 3.3.1-0.4.2 resolves the issue.


was (Author: ggutenberg):
Same issue for me (Cordova 3.4.0-0.1.3).  Using Sencha Touch, not jQuery 
Mobile.  The ST code loads after this block.  Following is the script tag load 
order:

{code}
https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >




{code}

Note that moving cordova.js to the top of the list of scripts has no effect, 
other than the error occurring sooner.  I.e., the following throws the same 
error:

{code}

https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >



{code}

> 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
>  Components: iOS
>Affects Versions: 3.1.0
>Reporter: Federico Kereki
>Assignee: Shazron Abdullah
>
> 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.2#6252)

[jira] [Commented] (CB-6304) cordova 3.4 creates Xcode project with general www directory, not iOS platform-specific one

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939724#comment-13939724
 ] 

Andrew Grieve commented on CB-6304:
---

The update template adds both www/ directories. The one under platforms/ is 
within a "staging" group.

The hope here was to highlight the fact that you are *not* supposed to make 
edits within the platforms/www directory when using the CLI. Changes made there 
are blown away every time you do a "cordova build".

> cordova 3.4 creates Xcode project with general www directory, not iOS 
> platform-specific one
> ---
>
> Key: CB-6304
> URL: https://issues.apache.org/jira/browse/CB-6304
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CLI, iOS
>Affects Versions: 3.4.0
> Environment: ios7.1, mac osx 10.9.2, xcode 5.1 build 5B130a
>Reporter: Farhad Farzaneh
>
> using cordova 3.4.0-0.1.3 to build project with 
> {{cordova create APP_DIR APP_SIGNATURE APP_NAME}}
> {{cordova platform add ios}}
> for various plugins:
> {{cordova plugin add org.apache.cordova.plugin_name}}
> Open the Xcode project.  The www folder that is added is the one in the 
> top-level app_dir, not the one in app_dir/platforms/ios/www, which was 
> previously the one added.  So now you have to remove this www from the 
> project, add the correct one (which adds all the .js files to compile list 
> and creates copy build rules for all the images, etc.), so it takes some time 
> to clean it up manually (probably there is a faster way...), and then 
> continue.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CB-6304) cordova 3.4 creates Xcode project with general www directory, not iOS platform-specific one

[Andrew Grieve (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Grieve resolved CB-6304.
---

Resolution: Not A Problem
  Assignee: Andrew Grieve

> cordova 3.4 creates Xcode project with general www directory, not iOS 
> platform-specific one
> ---
>
> Key: CB-6304
> URL: https://issues.apache.org/jira/browse/CB-6304
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CLI, iOS
>Affects Versions: 3.4.0
> Environment: ios7.1, mac osx 10.9.2, xcode 5.1 build 5B130a
>Reporter: Farhad Farzaneh
>Assignee: Andrew Grieve
>
> using cordova 3.4.0-0.1.3 to build project with 
> {{cordova create APP_DIR APP_SIGNATURE APP_NAME}}
> {{cordova platform add ios}}
> for various plugins:
> {{cordova plugin add org.apache.cordova.plugin_name}}
> Open the Xcode project.  The www folder that is added is the one in the 
> top-level app_dir, not the one in app_dir/platforms/ios/www, which was 
> previously the one added.  So now you have to remove this www from the 
> project, add the correct one (which adds all the .js files to compile list 
> and creates copy build rules for all the images, etc.), so it takes some time 
> to clean it up manually (probably there is a faster way...), and then 
> continue.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CB-5488) deviceready event not firing with jQuery Mobile

[Garth Gutenberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939710#comment-13939710
 ] 

Garth Gutenberg edited comment on CB-5488 at 3/18/14 8:16 PM:
--

Same issue for me (Cordova 3.4.0-0.1.3).  Using Sencha Touch, not jQuery 
Mobile.  The ST code loads after this block.  Following is the script tag load 
order:

{code}
https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >




{code}

Note that moving cordova.js to the top of the list of scripts has no effect, 
other than the error occurring sooner.  I.e., the following throws the same 
error:

{code}

https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >



{code}


was (Author: ggutenberg):
Same issue for me (Cordova 3.4.0-0.1.3).  Using Sencha Touch, not jQuery 
Mobile.  Following is the script tag load order:

{code}
https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >




{code}

Note that moving cordova.js to the top of the list of scripts has no effect, 
other than the error occurring sooner.  I.e., the following throws the same 
error:

{code}

https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >



{code}

> 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
>  Components: iOS
>Affects Versions: 3.1.0
>Reporter: Federico Kereki
>Assignee: Shazron Abdullah
>
> 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.2#6252)

[jira] [Comment Edited] (CB-5488) deviceready event not firing with jQuery Mobile

[Garth Gutenberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939710#comment-13939710
 ] 

Garth Gutenberg edited comment on CB-5488 at 3/18/14 8:11 PM:
--

Same issue for me (Cordova 3.4.0-0.1.3).  Using Sencha Touch, not jQuery 
Mobile.  Following is the script tag load order:

{code}
https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >




{code}

Note that moving cordova.js to the top of the list of scripts has no effect, 
other than the error occurring sooner.  I.e., the following throws the same 
error:

{code}

https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >



{code}


was (Author: ggutenberg):
Same issue for me (Cordova 3.4.0-0.1.3).  Using Sencha Touch, not jQuery 
Mobile.  Following is the script tag load order:

{code}
https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >




{code}

> 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
>  Components: iOS
>Affects Versions: 3.1.0
>Reporter: Federico Kereki
>Assignee: Shazron Abdullah
>
> 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.2#6252)

[jira] [Comment Edited] (CB-5488) deviceready event not firing with jQuery Mobile

[Garth Gutenberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939710#comment-13939710
 ] 

Garth Gutenberg edited comment on CB-5488 at 3/18/14 8:07 PM:
--

Same issue for me (Cordova 3.4.0-0.1.3).  Using Sencha Touch, not jQuery 
Mobile.  Following is the script tag load order:

{code}
https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >




{code}


was (Author: ggutenberg):
Same issue for me.  Using Sencha Touch, not jQuery Mobile.  Following is the 
script tag load order:

{code}
https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >




{code}

> 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
>  Components: iOS
>Affects Versions: 3.1.0
>Reporter: Federico Kereki
>Assignee: Shazron Abdullah
>
> 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.2#6252)

[jira] [Commented] (CB-5488) deviceready event not firing with jQuery Mobile

[Garth Gutenberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939710#comment-13939710
 ] 

Garth Gutenberg commented on CB-5488:
-

Same issue for me.  Using Sencha Touch, not jQuery Mobile.  Following is the 
script tag load order:

{code}
https://maps.googleapis.com/maps/api/js?&sensor=true&v=3&libraries=geometry";
 type="text/javascript" >




{code}

> 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
>  Components: iOS
>Affects Versions: 3.1.0
>Reporter: Federico Kereki
>Assignee: Shazron Abdullah
>
> 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.2#6252)

[jira] [Commented] (CB-6291) [CLI] Implement dual promise/callback api

[Lorin Beer (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939699#comment-13939699
 ] 

Lorin Beer commented on CB-6291:


I'm looking into this now. In any case the current api had broken phonegap cli 
tests by not obeying callback arguments. I also started by writing failing 
tests which expected a callback argument. 

If that functionality was broken, then I can revert the commits so far.

> [CLI] Implement dual promise/callback api
> -
>
> Key: CB-6291
> URL: https://issues.apache.org/jira/browse/CB-6291
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CLI
>Reporter: Lorin Beer
>Assignee: Lorin Beer
>Priority: Critical
>
> Master issue to manage the subissues involved in this task.
> in each subtask, the goal is to implement an optional promise/callback 
> interface. If a callback argument is supplied as the last parameter to a 
> function call which supports this api, then the callback is used and the 
> function returns null.
> If no callback is supplied, then a promise is returned.
> This upgrade should be non-breaking and backwards compatible.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CB-6304) cordova 3.4 creates Xcode project with general www directory, not iOS platform-specific one

[Farhad Farzaneh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Farhad Farzaneh updated CB-6304:


Summary: cordova 3.4 creates Xcode project with general www directory, not 
iOS platform-specific one  (was: cordova 4 creates Xcode project with general 
www directory, not iOS platform-specific one)

> cordova 3.4 creates Xcode project with general www directory, not iOS 
> platform-specific one
> ---
>
> Key: CB-6304
> URL: https://issues.apache.org/jira/browse/CB-6304
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CLI, iOS
>Affects Versions: 3.4.0
> Environment: ios7.1, mac osx 10.9.2, xcode 5.1 build 5B130a
>Reporter: Farhad Farzaneh
>
> using cordova 3.4.0-0.1.3 to build project with 
> {{cordova create APP_DIR APP_SIGNATURE APP_NAME}}
> {{cordova platform add ios}}
> for various plugins:
> {{cordova plugin add org.apache.cordova.plugin_name}}
> Open the Xcode project.  The www folder that is added is the one in the 
> top-level app_dir, not the one in app_dir/platforms/ios/www, which was 
> previously the one added.  So now you have to remove this www from the 
> project, add the correct one (which adds all the .js files to compile list 
> and creates copy build rules for all the images, etc.), so it takes some time 
> to clean it up manually (probably there is a faster way...), and then 
> continue.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CB-6305) cordova 3.4 cordovalib created without arm64 architecture support

[Farhad Farzaneh (JIRA)]

Farhad Farzaneh created CB-6305:
---

 Summary: cordova 3.4 cordovalib created without arm64 architecture 
support
 Key: CB-6305
 URL: https://issues.apache.org/jira/browse/CB-6305
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 3.4.0
 Environment: ios7.1, mac osx 10.9.2, xcode 5.1 build 5B130a

Reporter: Farhad Farzaneh
Priority: Minor


Create a new project.  The CordovaLib build rules do not include the arm64 
target, but the project ones do, and the "build active architecture only" flag 
is set to true.  So when building for an iphone5S, it fails to link.  Need to 
either update the project or CordovaLib build rules to make their architectures 
match, or change the build flag.  It's not a great experience when building the 
"Hello World" or initial app.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CB-6304) cordova 4 creates Xcode project with general www directory, not iOS platform-specific one

[Farhad Farzaneh (JIRA)]

Farhad Farzaneh created CB-6304:
---

 Summary: cordova 4 creates Xcode project with general www 
directory, not iOS platform-specific one
 Key: CB-6304
 URL: https://issues.apache.org/jira/browse/CB-6304
 Project: Apache Cordova
  Issue Type: Bug
  Components: CLI, iOS
Affects Versions: 3.4.0
 Environment: ios7.1, mac osx 10.9.2, xcode 5.1 build 5B130a

Reporter: Farhad Farzaneh


using cordova 3.4.0-0.1.3 to build project with 
{{cordova create APP_DIR APP_SIGNATURE APP_NAME}}
{{cordova platform add ios}}
for various plugins:
{{cordova plugin add org.apache.cordova.plugin_name}}

Open the Xcode project.  The www folder that is added is the one in the 
top-level app_dir, not the one in app_dir/platforms/ios/www, which was 
previously the one added.  So now you have to remove this www from the project, 
add the correct one (which adds all the .js files to compile list and creates 
copy build rules for all the images, etc.), so it takes some time to clean it 
up manually (probably there is a faster way...), and then continue.  




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6300) window.resolveLocalFileSystemURL weirdness

[nii amon dsane (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939621#comment-13939621
 ] 

nii amon dsane commented on CB-6300:


Hey Ian, thanks for getting on this.

I am using a Tecno Phantom Tab running Android 4.2.1. I get the alert with that 
file path, which is legit. However the call always goes into an error state no 
matter what format of file path I specify.

Tecno is one of the many Android devices popular in West and East Africa so I 
have to take them into consideration. You can find some tech specs here: 
http://www.netmediablog.com/tecno-phantom-tab-n9-features-specifications-price-nigeria.
 

It's pretty late here so I will have to try out your first suggestion when I'm 
up this morning. I will then report back. 

Many thanks.

> window.resolveLocalFileSystemURL weirdness
> --
>
> Key: CB-6300
> URL: https://issues.apache.org/jira/browse/CB-6300
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS, Plugin File
>Affects Versions: 3.3.0
> Environment: file plugin 1.0.1
>Reporter: nii amon dsane
>Assignee: Ian Clelland
>  Labels: camera, file, newbie, plugin, resolveLocalFileSystemURL
>
> I am trying to use the window.resolveLocalFileSystemURL but for some reason 
> my failure callback is always triggered. The success callback is never 
> triggered. This is my code:
> {code}
> // Take a picture using the camera
> $scope.takePicture = function () {
> var options = {
>   quality: 100,
>   targetWidth: 500,
>   targetHeight: 500,
>   destinationType: Camera.DestinationType.FILE_URI,
>   encodingType: Camera.EncodingType.JPEG,
>   saveToPhotoAlbum: true,
>   correctOrientation: true,
>   sourceType: Camera.PictureSourceType.CAMERA,
>   allowEdit: true
> };
> navigator.camera.getPicture(
>   cameraSuccess,
>   cameraFailure,
>   options
> );
> return false;
>   };
>   // what to do when the camera has  successfully yielded a good image
>   function cameraSuccess(imageURI){
> var uri = 'cdv' + imageURI;
> alert('this is imageURI: ' + imageURI);
> window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
>   };
> {code}
>   When I print out the imageURI, I get something like this:
>   file:///storage/sdcard0/DCIM/Camera/1395126124474.jpg
>   I can confirm that when I look at that path using the Files application on 
> an   android, the file is indeed there. But when the code runs and it 
> executes the window.resolveLocalFileSystemURL, the fail callback is always 
> triggered with an error of \{"code":5}.
> I've seen that that means there's an ENCODING_ERR but a bit baffled as to 
> what is causing that. The file does save properly to that location so I am at 
> a loss at to why the code will fail.
> Any help here?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6300) window.resolveLocalFileSystemURL weirdness

[Ian Clelland (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939595#comment-13939595
 ] 

Ian Clelland commented on CB-6300:
--

What device / OS version are you seeing this with? I'm testing with a Nexus7 
with Android 4.4, and my first tests aren't showing that particular issue.

I see this in the alert:
"this is imageURI: file:///storage/emulated/0/DCIM/Camera/1395167011485.jpg"

And that resolves correctly to a file at the URL 
{{cdvfile://localhost/persistent/DCIM/Camera/1395167011485.jpg}}

(I have no doubt you're seeing a real problem, BTW; I just want to be able to 
reproduce it reliably here. Thanks)

> window.resolveLocalFileSystemURL weirdness
> --
>
> Key: CB-6300
> URL: https://issues.apache.org/jira/browse/CB-6300
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS, Plugin File
>Affects Versions: 3.3.0
> Environment: file plugin 1.0.1
>Reporter: nii amon dsane
>Assignee: Ian Clelland
>  Labels: camera, file, newbie, plugin, resolveLocalFileSystemURL
>
> I am trying to use the window.resolveLocalFileSystemURL but for some reason 
> my failure callback is always triggered. The success callback is never 
> triggered. This is my code:
> {code}
> // Take a picture using the camera
> $scope.takePicture = function () {
> var options = {
>   quality: 100,
>   targetWidth: 500,
>   targetHeight: 500,
>   destinationType: Camera.DestinationType.FILE_URI,
>   encodingType: Camera.EncodingType.JPEG,
>   saveToPhotoAlbum: true,
>   correctOrientation: true,
>   sourceType: Camera.PictureSourceType.CAMERA,
>   allowEdit: true
> };
> navigator.camera.getPicture(
>   cameraSuccess,
>   cameraFailure,
>   options
> );
> return false;
>   };
>   // what to do when the camera has  successfully yielded a good image
>   function cameraSuccess(imageURI){
> var uri = 'cdv' + imageURI;
> alert('this is imageURI: ' + imageURI);
> window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
>   };
> {code}
>   When I print out the imageURI, I get something like this:
>   file:///storage/sdcard0/DCIM/Camera/1395126124474.jpg
>   I can confirm that when I look at that path using the Files application on 
> an   android, the file is indeed there. But when the code runs and it 
> executes the window.resolveLocalFileSystemURL, the fail callback is always 
> triggered with an error of \{"code":5}.
> I've seen that that means there's an ENCODING_ERR but a bit baffled as to 
> what is causing that. The file does save properly to that location so I am at 
> a loss at to why the code will fail.
> Any help here?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CB-6242) [BlackBerry10] resolveLocalFileSystemURL not mapped correctly

[Bryan Higgins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Higgins closed CB-6242.
-

Resolution: Fixed

> [BlackBerry10] resolveLocalFileSystemURL not mapped correctly
> -
>
> Key: CB-6242
> URL: https://issues.apache.org/jira/browse/CB-6242
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin File
>Reporter: Bryan Higgins
>Assignee: Bryan Higgins
>
> resolveLocalFileSystemURI is working correctly, but this has been deprecated 
> in favour of resolveLocalFileSystemURL



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6242) [BlackBerry10] resolveLocalFileSystemURL not mapped correctly

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939587#comment-13939587
 ] 

ASF subversion and git services commented on CB-6242:
-

Commit d9189f96ebe3c8436aa0b79abcb0bc7aa840 in cordova-plugin-file's branch 
refs/heads/dev from [~bhigg...@blackberry.com]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file.git;h=d9189f9 ]

CB-6242 [BlackBerry10] Add deprecated version of resolveLocalFileSystemURI


> [BlackBerry10] resolveLocalFileSystemURL not mapped correctly
> -
>
> Key: CB-6242
> URL: https://issues.apache.org/jira/browse/CB-6242
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin File
>Reporter: Bryan Higgins
>Assignee: Bryan Higgins
>
> resolveLocalFileSystemURI is working correctly, but this has been deprecated 
> in favour of resolveLocalFileSystemURL



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CB-6300) window.resolveLocalFileSystemURL weirdness

[Ian Clelland (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ian Clelland updated CB-6300:
-

Description: 
I am trying to use the window.resolveLocalFileSystemURL but for some reason my 
failure callback is always triggered. The success callback is never triggered. 
This is my code:

{code}
// Take a picture using the camera
$scope.takePicture = function () {
var options = {
  quality: 100,
  targetWidth: 500,
  targetHeight: 500,
  destinationType: Camera.DestinationType.FILE_URI,
  encodingType: Camera.EncodingType.JPEG,
  saveToPhotoAlbum: true,
  correctOrientation: true,
  sourceType: Camera.PictureSourceType.CAMERA,
  allowEdit: true
};

navigator.camera.getPicture(
  cameraSuccess,
  cameraFailure,
  options
);
return false;
  };

  // what to do when the camera has  successfully yielded a good image
  function cameraSuccess(imageURI){
var uri = 'cdv' + imageURI;
alert('this is imageURI: ' + imageURI);
window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
  };
{code}

  When I print out the imageURI, I get something like this:
  file:///storage/sdcard0/DCIM/Camera/1395126124474.jpg

  I can confirm that when I look at that path using the Files application on an 
  android, the file is indeed there. But when the code runs and it executes the 
window.resolveLocalFileSystemURL, the fail callback is always triggered with an 
error of \{"code":5}.

I've seen that that means there's an ENCODING_ERR but a bit baffled as to what 
is causing that. The file does save properly to that location so I am at a loss 
at to why the code will fail.

Any help here?



  was:
I am trying to use the window.resolveLocalFileSystemURL but for some reason my 
failure callback is always triggered. The success callback is never triggered. 
This is my code:

// Take a picture using the camera
$scope.takePicture = function () {
var options = {
  quality: 100,
  targetWidth: 500,
  targetHeight: 500,
  destinationType: Camera.DestinationType.FILE_URI,
  encodingType: Camera.EncodingType.JPEG,
  saveToPhotoAlbum: true,
  correctOrientation: true,
  sourceType: Camera.PictureSourceType.CAMERA,
  allowEdit: true
};

navigator.camera.getPicture(
  cameraSuccess,
  cameraFailure,
  options
);
return false;
  };

  // what to do when the camera has  successfully yielded a good image
  function cameraSuccess(imageURI){
var uri = 'cdv' + imageURI;
alert('this is imageURI: ' + imageURI);
window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
  };

  When I print out the imageURI, I get something like this:
  file:///storage/sdcard0/DCIM/Camera/1395126124474.jpg

  I can confirm that when I look at that path using the Files application on an 
  android, the file is indeed there. But when the code runs and it executes the 
window.resolveLocalFileSystemURL, the fail callback is always triggered with an 
error of {"code":5}.

I've seen that that means there's an ENCODING_ERR but a bit baffled as to what 
is causing that. The file does save properly to that location so I am at a loss 
at to why the code will fail.

Any help here?




> window.resolveLocalFileSystemURL weirdness
> --
>
> Key: CB-6300
> URL: https://issues.apache.org/jira/browse/CB-6300
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS, Plugin File
>Affects Versions: 3.3.0
> Environment: file plugin 1.0.1
>Reporter: nii amon dsane
>Assignee: Ian Clelland
>  Labels: camera, file, newbie, plugin, resolveLocalFileSystemURL
>
> I am trying to use the window.resolveLocalFileSystemURL but for some reason 
> my failure callback is always triggered. The success callback is never 
> triggered. This is my code:
> {code}
> // Take a picture using the camera
> $scope.takePicture = function () {
> var options = {
>   quality: 100,
>   targetWidth: 500,
>   targetHeight: 500,
>   destinationType: Camera.DestinationType.FILE_URI,
>   encodingType: Camera.EncodingType.JPEG,
>   saveToPhotoAlbum: true,
>   correctOrientation: true,
>   sourceType: Camera.PictureSourceType.CAMERA,
>   allowEdit: true
> };
> navigator.camera.getPicture(
>   cameraSuccess,
>   cameraFailure,
>   options
> );
> return false;
>   };
>   // what to do when the camera has  successfully yielded a good image
>   function cameraSuccess(imageURI){
> var uri = 'cdv' + imageURI;
> alert('this is imageURI: ' + imageURI);
> window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
>   };
> {code}
>   When I print out the imageURI, I get something like this:
>   file:///storage/sdcard0/

[jira] [Assigned] (CB-6249) Camera fails to return an actual FILE_URI it always returns content://

[Ian Clelland (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ian Clelland reassigned CB-6249:


Assignee: Ian Clelland

> Camera fails to return an actual FILE_URI it always returns content://
> --
>
> Key: CB-6249
> URL: https://issues.apache.org/jira/browse/CB-6249
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, Plugin Camera, Plugin File
>Affects Versions: 3.4.0
> Environment: Current Node Version
> v0.10.25
> Current Cordova CLI Version
> 3.4.0-0.1.0
> Android
>Reporter: Ralph S Theart
>Assignee: Ian Clelland
>  Labels: camera, file
>
> No matter what I do I can not get a url of file:///... all I get is 
> {code}
> content://media/external/images/media/1357
> {code}
> Here is my very simple code
> {code}
> navigator.camera.getPicture(function(imageURI){
>console.log('GOT IMAGE: '+imageURI);
>window.resolveLocalFileSystemURL(imageURI, function(entry){
>   console.log(entry.name + " " +entry.fullPath);
>}, function(e){
>   console.log('Some error occured: '+e.code);
>}); 
> }, onPhotoFail, {
>destinationType: 1, 
>sourceType: pictureSource,
>mediaType : Camera.MediaType.ALLMEDIA,
>encodingType: 0,
>allowEdit : false,
>correctOrientation:true,
>saveToPhotoAlbum: false,
>quality: 50
> });
> {code}
> I always get content://... for the returned path from camera and even the 
> same thing when I resolve the url. Can you confirm this bug?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6242) [BlackBerry10] resolveLocalFileSystemURL not mapped correctly

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939567#comment-13939567
 ] 

ASF subversion and git services commented on CB-6242:
-

Commit 9ec3b64948ee5b939d8be8f9a94721559d9fd039 in cordova-plugin-file's branch 
refs/heads/dev from [~bhigg...@blackberry.com]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file.git;h=9ec3b64 ]

CB-6242 [BlackBerry10] add file:/// prefix for toURI / toURL


> [BlackBerry10] resolveLocalFileSystemURL not mapped correctly
> -
>
> Key: CB-6242
> URL: https://issues.apache.org/jira/browse/CB-6242
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin File
>Reporter: Bryan Higgins
>Assignee: Bryan Higgins
>
> resolveLocalFileSystemURI is working correctly, but this has been deprecated 
> in favour of resolveLocalFileSystemURL



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CB-6300) window.resolveLocalFileSystemURL weirdness

[Ian Clelland (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ian Clelland reassigned CB-6300:


Assignee: Ian Clelland

> window.resolveLocalFileSystemURL weirdness
> --
>
> Key: CB-6300
> URL: https://issues.apache.org/jira/browse/CB-6300
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS, Plugin File
>Affects Versions: 3.3.0
> Environment: file plugin 1.0.1
>Reporter: nii amon dsane
>Assignee: Ian Clelland
>  Labels: camera, file, newbie, plugin, resolveLocalFileSystemURL
>
> I am trying to use the window.resolveLocalFileSystemURL but for some reason 
> my failure callback is always triggered. The success callback is never 
> triggered. This is my code:
> // Take a picture using the camera
> $scope.takePicture = function () {
> var options = {
>   quality: 100,
>   targetWidth: 500,
>   targetHeight: 500,
>   destinationType: Camera.DestinationType.FILE_URI,
>   encodingType: Camera.EncodingType.JPEG,
>   saveToPhotoAlbum: true,
>   correctOrientation: true,
>   sourceType: Camera.PictureSourceType.CAMERA,
>   allowEdit: true
> };
> navigator.camera.getPicture(
>   cameraSuccess,
>   cameraFailure,
>   options
> );
> return false;
>   };
>   // what to do when the camera has  successfully yielded a good image
>   function cameraSuccess(imageURI){
> var uri = 'cdv' + imageURI;
> alert('this is imageURI: ' + imageURI);
> window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
>   };
>   When I print out the imageURI, I get something like this:
>   file:///storage/sdcard0/DCIM/Camera/1395126124474.jpg
>   I can confirm that when I look at that path using the Files application on 
> an   android, the file is indeed there. But when the code runs and it 
> executes the window.resolveLocalFileSystemURL, the fail callback is always 
> triggered with an error of {"code":5}.
> I've seen that that means there's an ENCODING_ERR but a bit baffled as to 
> what is causing that. The file does save properly to that location so I am at 
> a loss at to why the code will fail.
> Any help here?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6300) window.resolveLocalFileSystemURL weirdness

[Ian Clelland (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939554#comment-13939554
 ] 

Ian Clelland commented on CB-6300:
--

The encoding error, in this case, means that there are no installed file 
systems which can handle that particular file location. Neither the temporary 
or persistent file systems consider that directory to be within their root. I'm 
looking into why the camera plugin would be saving images in a place that the 
file plugin does not recognize as a storage location.

In the meantime, you can try installing the 
org.apache.cordova.file-system-roots plugin (it's been in the cordova-plugins 
repository, but I just published it now), and add this to your config.xml:

{code}

{code}

> window.resolveLocalFileSystemURL weirdness
> --
>
> Key: CB-6300
> URL: https://issues.apache.org/jira/browse/CB-6300
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS, Plugin File
>Affects Versions: 3.3.0
> Environment: file plugin 1.0.1
>Reporter: nii amon dsane
>  Labels: camera, file, newbie, plugin, resolveLocalFileSystemURL
>
> I am trying to use the window.resolveLocalFileSystemURL but for some reason 
> my failure callback is always triggered. The success callback is never 
> triggered. This is my code:
> // Take a picture using the camera
> $scope.takePicture = function () {
> var options = {
>   quality: 100,
>   targetWidth: 500,
>   targetHeight: 500,
>   destinationType: Camera.DestinationType.FILE_URI,
>   encodingType: Camera.EncodingType.JPEG,
>   saveToPhotoAlbum: true,
>   correctOrientation: true,
>   sourceType: Camera.PictureSourceType.CAMERA,
>   allowEdit: true
> };
> navigator.camera.getPicture(
>   cameraSuccess,
>   cameraFailure,
>   options
> );
> return false;
>   };
>   // what to do when the camera has  successfully yielded a good image
>   function cameraSuccess(imageURI){
> var uri = 'cdv' + imageURI;
> alert('this is imageURI: ' + imageURI);
> window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
>   };
>   When I print out the imageURI, I get something like this:
>   file:///storage/sdcard0/DCIM/Camera/1395126124474.jpg
>   I can confirm that when I look at that path using the Files application on 
> an   android, the file is indeed there. But when the code runs and it 
> executes the window.resolveLocalFileSystemURL, the fail callback is always 
> triggered with an error of {"code":5}.
> I've seen that that means there's an ENCODING_ERR but a bit baffled as to 
> what is causing that. The file does save properly to that location so I am at 
> a loss at to why the code will fail.
> Any help here?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6146) FileTransfer.upload does not support iOS asset library type of URL

[Farhad Farzaneh (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939541#comment-13939541
 ] 

Farhad Farzaneh commented on CB-6146:
-

Sadly I'm unable to run my app on 3.4 on iOS 7.1 to test this.  Even doing a 
clean build using "cordova create ..." followed by "cordova platform add iOS" 
and adding the plugins doesn't run correctly with the simple example app. I'll 
submit other bug reports once I'm sure it's not my stupidity that's the cause.

> FileTransfer.upload does not support iOS asset library type of URL
> --
>
> Key: CB-6146
> URL: https://issues.apache.org/jira/browse/CB-6146
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 3.3.0
> Environment: Macbook Air, 10.9
>Reporter: Farhad Farzaneh
>Assignee: Ian Clelland
>
> When picking an image from the camera roll and using a NATIVE_URL type, the 
> url may be something like: 
> {{assets-library://asset/asset.PNG?id=CFDB9708-75A2-44A9-9092-FCE1DB471B30&ext=PNG}}.
>   When this is presented as the localURL to {{[CDVFileTransfer 
> fileDataForUploadCommand:]}} it recognizes the file system to be the asset 
> library and tries to read the file from the indicated URL using 
> {{[CDVAssetLibraryFilesystem readFileAtURL:]}}. I'm not sure why this method 
> tries to pull back the path from the URL with
> {code}
> NSString *path = [self fileSystemPathForURL:localURL];
> {code}
> and then rebuild the URL from that path below (line 223).  However, the 
> returned path is {{@"/asset.PNG"}}, which when used to retrieve the asset 
> fails.  
> If the line (CDVAssetLibraryFilesystem.m: 223)
> {code}
> [assetsLibrary assetForURL:[NSURL URLWithString:path] resultBlock:resultBlock 
> failureBlock:failureBlock];
> {code}
> is changed for
> {code}
> [assetsLibrary assetForURL:localURL.url resultBlock:resultBlock 
> failureBlock:failureBlock];
> {code}
> then the asset can be found.  But of course this was done for a reason, so I 
> imagine my fix breaks something else...
>  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CB-6249) Camera fails to return an actual FILE_URI it always returns content://

[Ralph S Theart (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939523#comment-13939523
 ] 

Ralph S Theart edited comment on CB-6249 at 3/18/14 5:49 PM:
-

Thank you for you detailed explanation and I understand. I think for the most 
part it would return a file:// since it did that consistently with all the 276 
unique android devices in our database from 2012 till a week ago since the new 
phonegap was introduce. The problem is when uploading a file to a backend 
service what is the back end supposed to do with a file called 4331 or some 
other obscure naming convention since the content uri's can't be resolved to 
expose the name of the file. I don't care about it's location since I move the 
file anyway. Remember this issue "only" exist with the _returned uri from the 
file picker of the camera plugin_ all other api like media capture return a 
file URI. What I love to see added is something that would at least give you 
the name of the file so when you moved it you could name it that with in the 
fileEntry.moveTo() method. Trying to switch case through mime types is more 
unreliable. I ran a test case in which video/mp4 was actually .3gpp on the 
Galaxy tab. 

I would love to see _this_ as part of a files properties: filesName or 
trueFilesName or something like that.

so obviously keep *name* =   _content:144_ as  it is but maybe have something 
like *trueName*: _image.png_
 does this make sense? This would be helpful since moveTo is always 
successful with the content URLs anyway. All I need to know is the file 
name..thats it.

The work flow I always had and the work flow that would solve this issue could 
be:

1. Pick image or video from file picker of camera api
2. Grab the files name, not the numerical value attached to the content url but 
it's real file name...image.png or whatever the path of file:/// is  irrelevant 
at this point.
3. Move the file and rename it with the real name you just got
4. Every one is happy including this guy.

I don't even know if what I am asking is even possible so I'm not presuming 
this to be possible but let me know your thoughts. For now I have no choice but 
to muck through the mime type craziness ;}.

Thanks Ian again for all of your help...have had a great experience with 
Phonegap, team, and these threads.




was (Author: drumaboy46):
Thanks you for you detailed explanation and I understand. I think for the most 
part it would return a file:// since it did that consistently with all the 276 
unique android devices in our database from 2012 till a week ago since the new 
phonegap was introduce. The problem is when uploading a file to a backend 
service what is the back end supposed to do with a file called 4331 or some 
other obscure naming convention since the content uri's can't be resolved to 
expose the name of the file. I don't care about it's location since I move the 
file anyway. Remember this issue "only" exist with the _returned uri from the 
file picker of the camera plugin_ all other api like media capture return a 
file URI. What I love to see added is something that would at least give you 
the name of the file so when you moved it you could name it that with in the 
fileEntry.moveTo() method. Using trying to switch case through mime types is 
more unreliable. I ran a test case in which video/mp4 was actually .3gpp on the 
Galaxy tab. I would love you see this as part of a files properties;

so obviously keep *name* =   _content:144_ as  it is but maybe have something 
like *trueName*: _image.png_
 does this make sense? This would be helpful since the move is always 
successful with the content URLs anyway. All I need is the file name..thats it.

The work flow I always had and the work flow that would solve this issue would 
be

1. Pick image or video from file picker of camera api
2. Grab the files name, not the numerical value attached to the content url but 
it's real file name...image.png or whatever the path of file:/// is  irrelevant 
at this point.
3. Move the file and rename it with the real name you just got
4. Every one is happy including this guy.

I don't even know if what I am asking is even possible so I'm not presuming 
this to be possible but let know your thoughts. For now I have no choice but to 
muck through the mime type craziness ;}.

Thanks Ian again for all of your help...have had a great experience with 
Phonegap, team, and these threads.



> Camera fails to return an actual FILE_URI it always returns content://
> --
>
> Key: CB-6249
> URL: https://issues.apache.org/jira/browse/CB-6249
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, Plugin Camera, Plugin File
>Affects Versions: 3.4.0
> Environment: Current Node Vers

[jira] [Commented] (CB-6249) Camera fails to return an actual FILE_URI it always returns content://

[Ralph S Theart (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939523#comment-13939523
 ] 

Ralph S Theart commented on CB-6249:


Thanks you for you detailed explanation and I understand. I think for the most 
part it would return a file:// since it did that consistently with all the 276 
unique android devices in our database from 2012 till a week ago since the new 
phonegap was introduce. The problem is when uploading a file to a backend 
service what is the back end supposed to do with a file called 4331 or some 
other obscure naming convention since the content uri's can't be resolved to 
expose the name of the file. I don't care about it's location since I move the 
file anyway. Remember this issue "only" exist with the _returned uri from the 
file picker of the camera plugin_ all other api like media capture return a 
file URI. What I love to see added is something that would at least give you 
the name of the file so when you moved it you could name it that with in the 
fileEntry.moveTo() method. Using trying to switch case through mime types is 
more unreliable. I ran a test case in which video/mp4 was actually .3gpp on the 
Galaxy tab. I would love you see this as part of a files properties;

so obviously keep *name* =   _content:144_ as  it is but maybe have something 
like *trueName*: _image.png_
 does this make sense. This would be helpful since the move is always 
successful with the content URLs

The work flow I always had and that would solve this issue would be

1. Pick image or video from file picker of camera api
2. Grab the files name, not the numerical value attached to the content url but 
it's real file name...image.png or whatever the path of file:/// is  irrelevant 
at this point.
3. Move the file and rename it with the real name you just got
4. Every one is happy including this guy.

I don't even know if what I am asking is even possible so I'm not presuming 
this to be possible but let know your thoughts. For now I have no choice but to 
muck through the mime type craziness ;}.

Thanks Ian again for all of your help...have had a great experience with 
Phonegap, team, and these threads.



> Camera fails to return an actual FILE_URI it always returns content://
> --
>
> Key: CB-6249
> URL: https://issues.apache.org/jira/browse/CB-6249
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, Plugin Camera, Plugin File
>Affects Versions: 3.4.0
> Environment: Current Node Version
> v0.10.25
> Current Cordova CLI Version
> 3.4.0-0.1.0
> Android
>Reporter: Ralph S Theart
>  Labels: camera, file
>
> No matter what I do I can not get a url of file:///... all I get is 
> {code}
> content://media/external/images/media/1357
> {code}
> Here is my very simple code
> {code}
> navigator.camera.getPicture(function(imageURI){
>console.log('GOT IMAGE: '+imageURI);
>window.resolveLocalFileSystemURL(imageURI, function(entry){
>   console.log(entry.name + " " +entry.fullPath);
>}, function(e){
>   console.log('Some error occured: '+e.code);
>}); 
> }, onPhotoFail, {
>destinationType: 1, 
>sourceType: pictureSource,
>mediaType : Camera.MediaType.ALLMEDIA,
>encodingType: 0,
>allowEdit : false,
>correctOrientation:true,
>saveToPhotoAlbum: false,
>quality: 50
> });
> {code}
> I always get content://... for the returned path from camera and even the 
> same thing when I resolve the url. Can you confirm this bug?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CB-6249) Camera fails to return an actual FILE_URI it always returns content://

[Ralph S Theart (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939523#comment-13939523
 ] 

Ralph S Theart edited comment on CB-6249 at 3/18/14 5:45 PM:
-

Thanks you for you detailed explanation and I understand. I think for the most 
part it would return a file:// since it did that consistently with all the 276 
unique android devices in our database from 2012 till a week ago since the new 
phonegap was introduce. The problem is when uploading a file to a backend 
service what is the back end supposed to do with a file called 4331 or some 
other obscure naming convention since the content uri's can't be resolved to 
expose the name of the file. I don't care about it's location since I move the 
file anyway. Remember this issue "only" exist with the _returned uri from the 
file picker of the camera plugin_ all other api like media capture return a 
file URI. What I love to see added is something that would at least give you 
the name of the file so when you moved it you could name it that with in the 
fileEntry.moveTo() method. Using trying to switch case through mime types is 
more unreliable. I ran a test case in which video/mp4 was actually .3gpp on the 
Galaxy tab. I would love you see this as part of a files properties;

so obviously keep *name* =   _content:144_ as  it is but maybe have something 
like *trueName*: _image.png_
 does this make sense? This would be helpful since the move is always 
successful with the content URLs anyway. All I need is the file name..thats it.

The work flow I always had and the work flow that would solve this issue would 
be

1. Pick image or video from file picker of camera api
2. Grab the files name, not the numerical value attached to the content url but 
it's real file name...image.png or whatever the path of file:/// is  irrelevant 
at this point.
3. Move the file and rename it with the real name you just got
4. Every one is happy including this guy.

I don't even know if what I am asking is even possible so I'm not presuming 
this to be possible but let know your thoughts. For now I have no choice but to 
muck through the mime type craziness ;}.

Thanks Ian again for all of your help...have had a great experience with 
Phonegap, team, and these threads.




was (Author: drumaboy46):
Thanks you for you detailed explanation and I understand. I think for the most 
part it would return a file:// since it did that consistently with all the 276 
unique android devices in our database from 2012 till a week ago since the new 
phonegap was introduce. The problem is when uploading a file to a backend 
service what is the back end supposed to do with a file called 4331 or some 
other obscure naming convention since the content uri's can't be resolved to 
expose the name of the file. I don't care about it's location since I move the 
file anyway. Remember this issue "only" exist with the _returned uri from the 
file picker of the camera plugin_ all other api like media capture return a 
file URI. What I love to see added is something that would at least give you 
the name of the file so when you moved it you could name it that with in the 
fileEntry.moveTo() method. Using trying to switch case through mime types is 
more unreliable. I ran a test case in which video/mp4 was actually .3gpp on the 
Galaxy tab. I would love you see this as part of a files properties;

so obviously keep *name* =   _content:144_ as  it is but maybe have something 
like *trueName*: _image.png_
 does this make sense. This would be helpful since the move is always 
successful with the content URLs

The work flow I always had and that would solve this issue would be

1. Pick image or video from file picker of camera api
2. Grab the files name, not the numerical value attached to the content url but 
it's real file name...image.png or whatever the path of file:/// is  irrelevant 
at this point.
3. Move the file and rename it with the real name you just got
4. Every one is happy including this guy.

I don't even know if what I am asking is even possible so I'm not presuming 
this to be possible but let know your thoughts. For now I have no choice but to 
muck through the mime type craziness ;}.

Thanks Ian again for all of your help...have had a great experience with 
Phonegap, team, and these threads.



> Camera fails to return an actual FILE_URI it always returns content://
> --
>
> Key: CB-6249
> URL: https://issues.apache.org/jira/browse/CB-6249
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, Plugin Camera, Plugin File
>Affects Versions: 3.4.0
> Environment: Current Node Version
> v0.10.25
> Current Cordova CLI Version
> 3.4.0-0.1.0
> Android
>Reporter: Ralph S Theart
> 

[jira] [Commented] (CB-6243) FileEntry.toURL() "cdvfile://localhost/persistent/file://"

[Ian Clelland (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939515#comment-13939515
 ] 

Ian Clelland commented on CB-6243:
--

Odd. Are you still resolving the same URL as in the description?

Have you added any preferences to your config.xml for the file plugin? (I 
haven't, and this code is working for me)

This is my console output (filename changed slightly from yours to pick an 
image on my device):

{code}
window.resolveLocalFileSystemURL('file:///storage/emulated/0/DCIM/Camera/1386780126389.jpg',
 function(entry) {
console.log(entry.fullPath);
console.log(entry.toURL());
console.log(entry.toNativeURL());
}, function(err) { console.log(err); });

undefined
/DCIM/Camera/1386780126389.jpg
cdvfile://localhost/persistent/DCIM/Camera/1386780126389.jpg
file:///storage/emulated/0/DCIM/Camera/1386780126389.jpg
{code}


> FileEntry.toURL() "cdvfile://localhost/persistent/file://"
> --
>
> Key: CB-6243
> URL: https://issues.apache.org/jira/browse/CB-6243
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin File
>Affects Versions: 3.4.0
> Environment: Android 4.4 using Genymotion emulator
>Reporter: David Normington
>Assignee: Ian Clelland
>  Labels: android, cdvfile
>
> When I run something like this:
> {code}
> window.resolveLocalFileSystemURL('file:///storage/emulated/0/DCIM/Camera/1394726081689.jpg',
>  function(entry) {
> console.log(entry.fullPath);
> console.log(entry.toURL());
> entry.file(fileSuccess, fail);
> });
> {code}
> The logcat shows this result:
> {code}
> I/chromium( 3022): [INFO:CONSOLE(28)] 
> "file:///storage/emulated/0/DCIM/Camera/1394726081689.jpg", source: 
> file:///android_asset/www/js/pdf.js (28)
> I/chromium( 3022): [INFO:CONSOLE(29)] 
> "cdvfile://localhost/temporary/file://storage/emulated/0/DCIM/Camera/1394726081689.jpg",
>  source: file:///android_asset/www/js/pdf.js (29)
> W/System.err( 2928): java.io.FileNotFoundException: File: 
> cdvfile://localhost/persistent/file://storage/emulated/0/DCIM/Camera/1394726081689.jpg
>  does not exist.
> W/System.err( 2928):at 
> org.apache.cordova.file.FileUtils.getFileMetadata(FileUtils.java:953)
> W/System.err( 2928):at 
> org.apache.cordova.file.FileUtils.access$400(FileUtils.java:53)
> W/System.err( 2928):at 
> org.apache.cordova.file.FileUtils$14.run(FileUtils.java:220)
> W/System.err( 2928):at 
> org.apache.cordova.file.FileUtils$23.run(FileUtils.java:325)
> W/System.err( 2928):at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
> W/System.err( 2928):at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
> W/System.err( 2928):at java.lang.Thread.run(Thread.java:841)
> {code}
> As you can see the second console.log has the cdvfile protocol with the file 
> protocol appended to the end. I'm sure this is causing the following error. 
> Seems that the same code runs perfectly on iOS returning the correct URLs:
> {code}
> [Log] /cdv_photo_001.jpg
> [Log] cdvfile://localhost/temporary/cdv_photo_001.jpg
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6163) [BlackBerry10] NaN returned for Cordova Geolocation heading value

[Josh Soref (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939509#comment-13939509
 ] 

Josh Soref commented on CB-6163:


OK, it turns out that this is by design, see
www/Coordinates.js
var Coordinates = function(lat, lng, alt, acc, head, vel, altacc) {
this.heading = (head !== undefined ? head : null);
this.speed = (vel !== undefined ? vel : null);
if (this.speed === 0 || this.speed === null) {
this.heading = NaN;
}

Mobile Spec should be adjusted to indicate that "NaN" is expected if you aren't 
moving.

> [BlackBerry10] NaN returned for Cordova Geolocation heading value
> -
>
> Key: CB-6163
> URL: https://issues.apache.org/jira/browse/CB-6163
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry, mobile-spec
>Affects Versions: 3.3.0
>Reporter: James Keshavarzi
>
> When using the mobile spec, a NaN value is returned for Heading when testing 
> the Cordova Geolocation plugin using the Location test page.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CB-6163) [BlackBerry10] NaN returned for Cordova Geolocation heading value

[Josh Soref (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Soref updated CB-6163:
---

Component/s: mobile-spec

> [BlackBerry10] NaN returned for Cordova Geolocation heading value
> -
>
> Key: CB-6163
> URL: https://issues.apache.org/jira/browse/CB-6163
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry, mobile-spec
>Affects Versions: 3.3.0
>Reporter: James Keshavarzi
>
> When using the mobile spec, a NaN value is returned for Heading when testing 
> the Cordova Geolocation plugin using the Location test page.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6249) Camera fails to return an actual FILE_URI it always returns content://

[Ian Clelland (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939497#comment-13939497
 ] 

Ian Clelland commented on CB-6249:
--

So the one problem I see with simply returning the file is that there is no 
guarantee that the file exists in a place that is accessible to the File plugin 
(short of mandating that everyone expose the *entire* filesystem to JavaScript 
by installing the file-system-roots plugin, which I'd rather not have to do).

Right now, {{entry.toNativeURL()}} and {{entry.toURL()}} always return a URL 
which can be handled by {{resolveLocalFileSystemURL}}. If we unconditionally 
resolve all content:// URLs to their file representation, that would mean that 
this snippet would fail on some content:// URLs:

{code}
resolveLocalFileSystemURL(contentURL, function(entry) {  // start with a 
content:// url
var fileURL = entry.toNativeURL();  // turn it into a file:// url, pointing 
to a location outside of the sandbox
resolveLocalFileSystemURL(fileURL, successCallback);  // fails because the 
file is inaccessible
});
{code}

One way forward would be to opportunistically convert content:// URLs to 
file:// URLs, *if* it can be done (the file exists) and *if* the process is 
reversible (the file could be resolved again to get a cdvfile url), and leave 
all other content:// URLs unchanged.

Alternately, we could ignore that particular issue, since there has never been 
a guarantee that to\*URL / resolveLocalFileSystemURL can round-trip like that, 
and just convert all content URLs which map to files, regardless of whether or 
not the resulting file url can be re-consumed by the file plugin.

(No matter what we do, though, there is never going to be a guarantee that a 
URL returned by {{.toURL()}} or {{.toNativeURL()}} is a file:// URL. Some 
resources are simply not available through that protocol.)

> Camera fails to return an actual FILE_URI it always returns content://
> --
>
> Key: CB-6249
> URL: https://issues.apache.org/jira/browse/CB-6249
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, Plugin Camera, Plugin File
>Affects Versions: 3.4.0
> Environment: Current Node Version
> v0.10.25
> Current Cordova CLI Version
> 3.4.0-0.1.0
> Android
>Reporter: Ralph S Theart
>  Labels: camera, file
>
> No matter what I do I can not get a url of file:///... all I get is 
> {code}
> content://media/external/images/media/1357
> {code}
> Here is my very simple code
> {code}
> navigator.camera.getPicture(function(imageURI){
>console.log('GOT IMAGE: '+imageURI);
>window.resolveLocalFileSystemURL(imageURI, function(entry){
>   console.log(entry.name + " " +entry.fullPath);
>}, function(e){
>   console.log('Some error occured: '+e.code);
>}); 
> }, onPhotoFail, {
>destinationType: 1, 
>sourceType: pictureSource,
>mediaType : Camera.MediaType.ALLMEDIA,
>encodingType: 0,
>allowEdit : false,
>correctOrientation:true,
>saveToPhotoAlbum: false,
>quality: 50
> });
> {code}
> I always get content://... for the returned path from camera and even the 
> same thing when I resolve the url. Can you confirm this bug?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6303) Simplify error when user uses ^C at password prompt

[Josh Soref (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939417#comment-13939417
 ] 

Josh Soref commented on CB-6303:


https://github.com/blackberry/cordova-blackberry/pull/22

> Simplify error when user uses ^C at password prompt
> ---
>
> Key: CB-6303
> URL: https://issues.apache.org/jira/browse/CB-6303
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry
>Affects Versions: 3.4.0
>Reporter: Josh Soref
>Assignee: Josh Soref
>Priority: Minor
>
> Steps to reproduce:
> Attached a device to machine. 
> Execute cordova run blackberry10
> When the following shows up, click control-C
> "Please enter your device password: "
> Actual result:
> Output: 
> .../myAppww/platforms/blackberry10/cordova/lib/utils.js:341
> done(err, results.property);
>  ^
> TypeError: Cannot read property 'property' of undefined
> at .../myAppww/platforms/blackberry10/cordova/lib/utils.js:341:30
> at 
> .../myAppww/platforms/blackberry10/cordova/node_modules/prompt/lib/prompt.js:316:20
> ...
> Expected result:
> Command should exit more gracefully



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CB-6303) Simplify error when user uses ^C at password prompt

[Josh Soref (JIRA)]

Josh Soref created CB-6303:
--

 Summary: Simplify error when user uses ^C at password prompt
 Key: CB-6303
 URL: https://issues.apache.org/jira/browse/CB-6303
 Project: Apache Cordova
  Issue Type: Bug
  Components: BlackBerry
Affects Versions: 3.4.0
Reporter: Josh Soref
Assignee: Josh Soref
Priority: Minor


Steps to reproduce:

Attached a device to machine. 
Execute cordova run blackberry10
When the following shows up, click control-C
"Please enter your device password: "


Actual result:

Output: 

.../myAppww/platforms/blackberry10/cordova/lib/utils.js:341
done(err, results.property);
 ^
TypeError: Cannot read property 'property' of undefined
at .../myAppww/platforms/blackberry10/cordova/lib/utils.js:341:30
at 
.../myAppww/platforms/blackberry10/cordova/node_modules/prompt/lib/prompt.js:316:20
...


Expected result:
Command should exit more gracefully



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-5468) improve config.xml encoding handling of utf-8

[Josh Soref (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939406#comment-13939406
 ] 

Josh Soref commented on CB-5468:


I still have the two other branches/repos for which I have changes. We can 
close this and I can open new bugs for them, I guess...

> improve config.xml encoding handling of utf-8
> -
>
> Key: CB-5468
> URL: https://issues.apache.org/jira/browse/CB-5468
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry, CLI, Plugman
>Reporter: Josh Soref
>Assignee: Josh Soref
> Fix For: 3.5.0
>
>
> If you have a config.xml w/o a BOM in UTF-8 and try to use cordova build on 
> BlackBerry, you'll get an error.
> That logic is here:
> https://github.com/apache/cordova-blackberry/blob/master/blackberry10/bin/templates/project/cordova/lib/packager-utils.js#L143
> cordova cli on the other hand seems to only handle UTF-8 (and not 
> UCS2/UTF-16).
> That logic is here:
> https://github.com/apache/cordova-cli/blob/master/src/xml-helpers.js#L111
> The specification for config.xml is here:
> http://www.w3.org/TR/widgets/#algorithm-to-process-a-configuration-document
> Let doc be the result of loading the widget config doc as a [DOMCore] 
> Document using an [XML] parser that is both [XMLNS]-aware and xml:lang aware.
> [XML] defers to:
> http://www.w3.org/TR/2008/REC-xml-20081126/#charsets
> which says:
> The mechanism for encoding character code points into bit patterns may vary 
> from entity to entity. All XML processors must accept the UTF-8 and UTF-16 
> encodings of Unicode [Unicode].



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CB-6222) Various updates for the BlackBerry 10 documentation

[Josh Soref (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Soref resolved CB-6222.


   Resolution: Fixed
Fix Version/s: 3.5.0

> Various updates for the BlackBerry 10 documentation
> ---
>
> Key: CB-6222
> URL: https://issues.apache.org/jira/browse/CB-6222
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry
>Affects Versions: 3.4.0
>Reporter: Josh Soref
>Assignee: Josh Soref
>Priority: Minor
> Fix For: 3.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CB-6241) Default to prompting for passwords (replace --query with --no-query)

[Josh Soref (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Soref resolved CB-6241.


   Resolution: Fixed
Fix Version/s: 3.5.0

> Default to prompting for passwords (replace --query with --no-query)
> 
>
> Key: CB-6241
> URL: https://issues.apache.org/jira/browse/CB-6241
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry
>Affects Versions: 3.4.0
>Reporter: Josh Soref
>Assignee: Josh Soref
> Fix For: 3.5.0
>
>
> BlackBerry 10 has supported prompting for passwords for a while using the 
> --query flag, and we've used it for our end users.
> This behavior makes sense as a default, and more or less matches the behavior 
> for Android. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-5203) Using XmlHTTPRequest.open on WP8 raises a TypeError

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939362#comment-13939362
 ] 

ASF GitHub Bot commented on CB-5203:


Github user dotnetwise commented on the pull request:

https://github.com/apache/cordova-wp8/pull/19#issuecomment-37944939
  
Hmm, this is still an issue on WP8 :(
The fix affects a .cs file, so not sure how it really helps?


> Using XmlHTTPRequest.open on WP8 raises a TypeError
> ---
>
> Key: CB-5203
> URL: https://issues.apache.org/jira/browse/CB-5203
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: weinre
>Affects Versions: 3.1.0
> Environment: Windows Phone 7 + 8
> Windows 8, MS Visual Studio Express 2012 for Windows Phone version 
> 11.0.60610.01 Update 3. .NET version 4.5.50709. Weinre 2.0.0-pre-HH0SN197
>Reporter: Björn Andersson
>Assignee: Sergey Grebnov
> Fix For: 3.3.0
>
>
> Using the {{cordova-app-hello-world}} code on a WP8 device, connected to the 
> device through weinre, trying to use XMLHTTPRequest like this:
> {code:language=javascript}
> var xhr = new XMLHttpRequest();
> xhr.open('GET', 'js/index.js', true);
> xhr.send();
> console.log(xhr.responseText);
> {code}
> An error is raised at {{xhr.open}}: {{TypeError: Object doesn't support 
> property or method 'addEventListener'}}
> The same code on iOS runs through and shows me the content of {{index.js}}.
> Changing the call to:
> {code:javascript}
> var xhr = new XMLHttpRequest();
> xhr._url = 'js/index.js';
> xhr.send();
> console.log(xhr.responseText);
> {code}
> Returns the expected result.
> I also noticed that {{XMLHttpRequest.prototype.open}} does not match the code 
> in {{cordovalib\XHRHelper.cs}}:
> {code:title=XMLHttpRequest.prototype.open|javascript}
> function() {
> var result;
> callBeforeHooks(hookSite, this, arguments);
> try {
> result = func.apply(this, arguments);
> } catch (e) {
> callExceptHooks(hookSite, this, arguments, e);
> throw e;
> } finally {
> callAfterHooks(hookSite, this, arguments, result);
> }
> return result;
> }
> {code}
> GitHub repository with the code I used: 
> https://github.com/gaqzi/cordova-wp8-xhr-test



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6242) [BlackBerry10] resolveLocalFileSystemURL not mapped correctly

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939328#comment-13939328
 ] 

ASF subversion and git services commented on CB-6242:
-

Commit b9fd769912357a755866499066d8c4a615ac96d8 in cordova-plugin-file's branch 
refs/heads/dev from [~bhigg...@blackberry.com]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file.git;h=b9fd769 ]

CB-6242 [BlackBerry10] Polyfill window.requestAnimationFrame for OS < 10.2


> [BlackBerry10] resolveLocalFileSystemURL not mapped correctly
> -
>
> Key: CB-6242
> URL: https://issues.apache.org/jira/browse/CB-6242
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin File
>Reporter: Bryan Higgins
>Assignee: Bryan Higgins
>
> resolveLocalFileSystemURI is working correctly, but this has been deprecated 
> in favour of resolveLocalFileSystemURL



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6242) [BlackBerry10] resolveLocalFileSystemURL not mapped correctly

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939323#comment-13939323
 ] 

ASF subversion and git services commented on CB-6242:
-

Commit 044f07d7fa4cb34ee1870258bd2b4848db65fdf2 in cordova-plugin-file's branch 
refs/heads/dev from [~bhigg...@blackberry.com]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file.git;h=044f07d ]

CB-6242 [BlackBerry10] Override window.resolveLocalFileSystemURL


> [BlackBerry10] resolveLocalFileSystemURL not mapped correctly
> -
>
> Key: CB-6242
> URL: https://issues.apache.org/jira/browse/CB-6242
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin File
>Reporter: Bryan Higgins
>Assignee: Bryan Higgins
>
> resolveLocalFileSystemURI is working correctly, but this has been deprecated 
> in favour of resolveLocalFileSystemURL



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CB-6302) Document config.xml platform element

[Bryan Higgins (JIRA)]

Bryan Higgins created CB-6302:
-

 Summary: Document config.xml platform element
 Key: CB-6302
 URL: https://issues.apache.org/jira/browse/CB-6302
 Project: Apache Cordova
  Issue Type: Improvement
  Components: Docs
Affects Versions: 3.4.0
Reporter: Bryan Higgins
Assignee: Bryan Higgins






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6201) Invalid full path and URI returned from fileEntry.moveTo and fileEntry.copyTo

[Brian Keith Johnston (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939263#comment-13939263
 ] 

Brian Keith Johnston commented on CB-6201:
--

Ian,  Thank you for explaining the changes.  I tried toURL already, but
still it did not give me valid URL to the file.  I'll give toNativeURL a
try.  -Brian





-- 



> Invalid full path and URI returned from fileEntry.moveTo and fileEntry.copyTo 
> --
>
> Key: CB-6201
> URL: https://issues.apache.org/jira/browse/CB-6201
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin File
>Affects Versions: 1.1.0
> Environment: I'm building Android and iOS with build.phonegap.com 
> version 3.10.  This issue is occuring on both Android and iOS.
>Reporter: brian johnston
>Assignee: Ian Clelland
> Attachments: copyToMoveToCode.txt
>
>
> fileEntry.fullPath does not return the full path in version 1.1.0.  However, 
> version 1.0.0 of the file plugin does return the full path.  This issue 
> occurs on both iOS and Android.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6302) Document config.xml platform element

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939208#comment-13939208
 ] 

ASF subversion and git services commented on CB-6302:
-

Commit 7598207d0e4395905c009c056947a5a7c9930b1a in cordova-docs's branch 
refs/heads/master from [~bhigg...@blackberry.com]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;h=7598207 ]

CB-6302 - Document config.xml platform element


> Document config.xml platform element
> 
>
> Key: CB-6302
> URL: https://issues.apache.org/jira/browse/CB-6302
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Docs
>Affects Versions: 3.4.0
>Reporter: Bryan Higgins
>Assignee: Bryan Higgins
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CB-6302) Document config.xml platform element

[Bryan Higgins (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CB-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Higgins closed CB-6302.
-

   Resolution: Fixed
Fix Version/s: 3.5.0

> Document config.xml platform element
> 
>
> Key: CB-6302
> URL: https://issues.apache.org/jira/browse/CB-6302
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Docs
>Affects Versions: 3.4.0
>Reporter: Bryan Higgins
>Assignee: Bryan Higgins
> Fix For: 3.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6299) Ajax of local files not working when requested via absolute URL

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939120#comment-13939120
 ] 

ASF GitHub Bot commented on CB-6299:


GitHub user gabrielschulhof opened a pull request:

https://github.com/apache/cordova-wp8/pull/30

CB-6299 Strip protocol and leading slashes from XHRLOCAL URL

This PR submits the fix mentioned in a related jQuery Mobile 
[bug](https://github.com/jquery/jquery-mobile/issues/6574#issuecomment-37879404)

I've tested this fix on a Nokia Lumia 800 for WP7 and on a Nokia Lumia 520 
for WP8.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gabrielschulhof/cordova-wp8 
6299-abs-url-processing

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-wp8/pull/30.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #30


commit 3dbe46184c5846653dc553ea8984d1736380f0bc
Author: Gabriel Schulhof 
Date:   2014-03-18T12:16:20Z

CB-6299 [wp8] Strip protocol and leading slashes from XHRLOCAL URL

commit ca8efaf15cc5a286995fe28e9dd10146a53ff362
Author: Gabriel Schulhof 
Date:   2014-03-18T12:16:29Z

CB-6299 [wp7] Strip protocol and leading slashes from XHRLOCAL URL




> Ajax of local files not working when requested via absolute URL
> ---
>
> Key: CB-6299
> URL: https://issues.apache.org/jira/browse/CB-6299
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: WP7, WP8
>Reporter: Gabriel Schulhof
>Assignee: Jesse MacFadyen
>
> The code does not properly strip slashes from the path name when the URL is 
> absolute, because in that case the path name is prefixed with the protocol, 
> so the protocol must be stripped off first.
> References:
> https://github.com/jquery/jquery-mobile/issues/6574



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CB-6299) Ajax of local files not working when requested via absolute URL

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939121#comment-13939121
 ] 

ASF GitHub Bot commented on CB-6299:


Github user gabrielschulhof commented on the pull request:

https://github.com/apache/cordova-wp8/pull/30#issuecomment-37926378
  
@purplecabbage I guess a PR can't hurt, either, eh?


> Ajax of local files not working when requested via absolute URL
> ---
>
> Key: CB-6299
> URL: https://issues.apache.org/jira/browse/CB-6299
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: WP7, WP8
>Reporter: Gabriel Schulhof
>Assignee: Jesse MacFadyen
>
> The code does not properly strip slashes from the path name when the URL is 
> absolute, because in that case the path name is prefixed with the protocol, 
> so the protocol must be stripped off first.
> References:
> https://github.com/jquery/jquery-mobile/issues/6574



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CB-6301) Create Cordova platform wp8 or windows8 got error "Non-whitespace before first tag"

[steelair (JIRA)]

steelair created CB-6301:


 Summary: Create Cordova platform wp8 or windows8 got error 
"Non-whitespace before first tag"
 Key: CB-6301
 URL: https://issues.apache.org/jira/browse/CB-6301
 Project: Apache Cordova
  Issue Type: Bug
  Components: CLI
Affects Versions: 3.4.0
 Environment: Windows 8.1 Pro(Chinese-Simplified)
Visual Studio 2013 Ultimate with Update 1(Chinese-Simplified)
Reporter: steelair
 Fix For: 3.4.0


When I use Command-Line to add platforms like this:
cordova platform add wp8
cordova platform add windows8

The issue occurs like this:
C:\testproject>cordova platform add windows8
Checking windows8 requirements...
Creating windows8 project...
Creating Cordova Windows 8 Project:
App Name : testproject
Namespace : testproject
Path : C:\testproject\platforms\windows8
Project created
[Error: Non-whitespace before first tag.
Line: 0
Column: 1
Char: �]

I got the same issue when I Add plugin like this:
cordova plugin add org.apache.cordova.device

The issue goes to:
C:\testproject>cordova plugin add org.apache.cordova.device
Fetching plugin "org.apache.cordova.device" via plugin registry
Installing org.apache.cordova.device (windows8)
Error: Non-whitespace before first tag.
Line: 0
Column: 1
Char: �
at error (C:\Users\steelAir\AppData\Roaming\npm\node_modules\cordova\node_mo
dules\elementtree\node_modules\sax\lib\sax.js:347:8)
at strictFail (C:\Users\steelAir\AppData\Roaming\npm\node_modules\cordova\no
de_modules\elementtree\node_modules\sax\lib\sax.js:364:22)
at Object.write (C:\Users\steelAir\AppData\Roaming\npm\node_modules\cordova\
node_modules\elementtree\node_modules\sax\lib\sax.js:603:11)
at XMLParser.feed (C:\Users\steelAir\AppData\Roaming\npm\node_modules\cordov
a\node_modules\elementtree\lib\parsers\sax.js:48:15)
at ElementTree.parse (C:\Users\steelAir\AppData\Roaming\npm\node_modules\cor
dova\node_modules\elementtree\lib\elementtree.js:263:10)
at Object.exports.XML (C:\Users\steelAir\AppData\Roaming\npm\node_modules\co
rdova\node_modules\elementtree\lib\elementtree.js:593:13)
at Object.module.exports.parseElementtreeSync (C:\Users\steelAir\AppData\Roa
ming\npm\node_modules\cordova\node_modules\plugman\src\util\xml-helpers.js:120:3
8)
at Object.module.exports.package_name (C:\Users\steelAir\AppData\Roaming\npm
\node_modules\cordova\node_modules\plugman\src\platforms\windows8.js:35:36)
at PlatformMunger.generate_plugin_config_munge (C:\Users\steelAir\AppData\Ro
aming\npm\node_modules\cordova\node_modules\plugman\src\util\config-changes.js:2
85:54)
at PlatformMunger.add_plugin_changes (C:\Users\steelAir\AppData\Roaming\npm\
node_modules\cordova\node_modules\plugman\src\util\config-changes.js:211:29)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CB-6300) window.resolveLocalFileSystemURL weirdness

[nii amon dsane (JIRA)]

nii amon dsane created CB-6300:
--

 Summary: window.resolveLocalFileSystemURL weirdness
 Key: CB-6300
 URL: https://issues.apache.org/jira/browse/CB-6300
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android, CordovaJS, Plugin File
Affects Versions: 3.3.0
 Environment: file plugin 1.0.1
Reporter: nii amon dsane


I am trying to use the window.resolveLocalFileSystemURL but for some reason my 
failure callback is always triggered. The success callback is never triggered. 
This is my code:

// Take a picture using the camera
$scope.takePicture = function () {
var options = {
  quality: 100,
  targetWidth: 500,
  targetHeight: 500,
  destinationType: Camera.DestinationType.FILE_URI,
  encodingType: Camera.EncodingType.JPEG,
  saveToPhotoAlbum: true,
  correctOrientation: true,
  sourceType: Camera.PictureSourceType.CAMERA,
  allowEdit: true
};

navigator.camera.getPicture(
  cameraSuccess,
  cameraFailure,
  options
);
return false;
  };

  // what to do when the camera has  successfully yielded a good image
  function cameraSuccess(imageURI){
var uri = 'cdv' + imageURI;
alert('this is imageURI: ' + imageURI);
window.resolveLocalFileSystemURL(imageURI, resolvePhotoPath, fail);
  };

  When I print out the imageURI, I get something like this:
  file:///storage/sdcard0/DCIM/Camera/1395126124474.jpg

  I can confirm that when I look at that path using the Files application on an 
  android, the file is indeed there. But when the code runs and it executes the 
window.resolveLocalFileSystemURL, the fail callback is always triggered with an 
error of {"code":5}.

I've seen that that means there's an ENCODING_ERR but a bit baffled as to what 
is causing that. The file does save properly to that location so I am at a loss 
at to why the code will fail.

Any help here?





--
This message was sent by Atlassian JIRA
(v6.2#6252)