[jira] [Commented] (CB-6333) getPicture won't return photo after first shot, but the second shot will return first shot.
[ https://issues.apache.org/jira/browse/CB-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948994#comment-13948994 ] Zhang Hong commented on CB-6333: i forgot to metion that pick a photo from gallery has same issue. getPicture won't return photo after first shot, but the second shot will return first shot. --- Key: CB-6333 URL: https://issues.apache.org/jira/browse/CB-6333 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 3.4.0 Environment: osx 10.9.1 Reporter: Zhang Hong Assignee: Joe Bowser i've found that we have similar issues on other versions. 3.4.0-0.1.3 still has this issue. reproduce 1. create new blank project 2. add platform android 3. fetch device plugin 4. fetch camera plugin 5. write some js code follow document 6. build it for android tested on s4 4.2.2 and genymotion with built-in camera 4.4.2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6333) getPicture won't return photo after first shot, but the second shot will return first shot.
[ https://issues.apache.org/jira/browse/CB-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949004#comment-13949004 ] Joe Bowser commented on CB-6333: [~zhang_hais...@itrus.com.cn] Can you please create a new issue that covers that use case? I'd rather not re-open this one. getPicture won't return photo after first shot, but the second shot will return first shot. --- Key: CB-6333 URL: https://issues.apache.org/jira/browse/CB-6333 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 3.4.0 Environment: osx 10.9.1 Reporter: Zhang Hong Assignee: Joe Bowser i've found that we have similar issues on other versions. 3.4.0-0.1.3 still has this issue. reproduce 1. create new blank project 2. add platform android 3. fetch device plugin 4. fetch camera plugin 5. write some js code follow document 6. build it for android tested on s4 4.2.2 and genymotion with built-in camera 4.4.2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CB-6333) getPicture won't return photo after first shot, but the second shot will return first shot.
[ https://issues.apache.org/jira/browse/CB-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948340#comment-13948340 ] Joe Bowser edited comment on CB-6333 at 3/27/14 7:39 AM: - I didn't actually fix anything. I literally checked out the dev branch of the plugin to see if this was still an issue on the dev branch. Since I saw it was fixed, I marked it as fixed. was (Author: bowserj): I didn't actually fix anything. I literally checked out the dev branch of the plugin to see if this was still an issue on the dev branch, since it's fixed, I marked it as fixed. getPicture won't return photo after first shot, but the second shot will return first shot. --- Key: CB-6333 URL: https://issues.apache.org/jira/browse/CB-6333 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Camera Affects Versions: 3.4.0 Environment: osx 10.9.1 Reporter: Zhang Hong Assignee: Joe Bowser i've found that we have similar issues on other versions. 3.4.0-0.1.3 still has this issue. reproduce 1. create new blank project 2. add platform android 3. fetch device plugin 4. fetch camera plugin 5. write some js code follow document 6. build it for android tested on s4 4.2.2 and genymotion with built-in camera 4.4.2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6351) setMetadata fails silently
[ https://issues.apache.org/jira/browse/CB-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949024#comment-13949024 ] Robin Zeggelaar commented on CB-6351: - Dear Ian, The project was created after upgrading Cordova and Phonegap via NPM. The plugins were added using Cordova plugin add org.apache.cordova.x. Am i right to assume this is the correct way to handle things? I will look into updating/re-installing and get back to you with the results. setMetadata fails silently -- Key: CB-6351 URL: https://issues.apache.org/jira/browse/CB-6351 Project: Apache Cordova Issue Type: Bug Components: Plugin File Affects Versions: 3.4.0 Reporter: Robin Zeggelaar Assignee: Ian Clelland Labels: setMetadata In Cordova 3.0.4 the setMetadata call on iOS fails silently. Android does not seem to have this issue. On the javascript side the following call is made (Entry.js): exec(successCallback, errorCallback, File, setMetadata, [this.fullPath, metadataObject]); This fails silently on the native end. My callbacks are not invoked. I fixed this by changing this.fullPath to this.toURL(), conform the changes to the File plugin. After this change the callbacks did get invoked properly. Could you take a look at this and fix it in a future release? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CB-6351) setMetadata fails silently
[ https://issues.apache.org/jira/browse/CB-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949024#comment-13949024 ] Robin Zeggelaar edited comment on CB-6351 at 3/27/14 9:57 AM: -- Dear Ian, The project was created after upgrading Cordova and Phonegap via NPM. The plugins were added using Cordova plugin add org.apache.cordova.x. Am i right to assume this is the correct way to handle things? I will look into updating/re-installing and get back to you with the results. UPDATE: I just removed all my plugins and re-added them using the CLI. The same problem persists. I'm really curious as to where you got the line of code you showed from. Every git repo i check does not contain the line you quoted. See: https://github.com/apache/cordova-plugin-file/blob/master/www/Entry.js was (Author: robinzeggelaar): Dear Ian, The project was created after upgrading Cordova and Phonegap via NPM. The plugins were added using Cordova plugin add org.apache.cordova.x. Am i right to assume this is the correct way to handle things? I will look into updating/re-installing and get back to you with the results. setMetadata fails silently -- Key: CB-6351 URL: https://issues.apache.org/jira/browse/CB-6351 Project: Apache Cordova Issue Type: Bug Components: Plugin File Affects Versions: 3.4.0 Reporter: Robin Zeggelaar Assignee: Ian Clelland Labels: setMetadata In Cordova 3.0.4 the setMetadata call on iOS fails silently. Android does not seem to have this issue. On the javascript side the following call is made (Entry.js): exec(successCallback, errorCallback, File, setMetadata, [this.fullPath, metadataObject]); This fails silently on the native end. My callbacks are not invoked. I fixed this by changing this.fullPath to this.toURL(), conform the changes to the File plugin. After this change the callbacks did get invoked properly. Could you take a look at this and fix it in a future release? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CB-6351) setMetadata fails silently
[
https://issues.apache.org/jira/browse/CB-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949024#comment-13949024
]
Robin Zeggelaar edited comment on CB-6351 at 3/27/14 10:14 AM:
---
Dear Ian,
The project was created after upgrading Cordova and Phonegap via NPM. The
plugins were added using Cordova plugin add org.apache.cordova.x. Am i right
to assume this is the correct way to handle things?
I will look into updating/re-installing and get back to you with the results.
UPDATE: I just removed all my plugins and re-added them using the CLI. I used
{panel}cordova plugin add org.apache.cordova.file{panel} The Entry.js file is
still not containing the line you quoted. If it is of any help, the
cordova_plugins.js file is showwing the following for the file plugin:
{panel}org.apache.cordova.dialogs: 0.2.6,
org.apache.cordova.network-information: 0.2.7,
org.apache.cordova.console: 0.2.7,
org.apache.cordova.plugins.PowerManagement: 0.1.0,
org.apache.cordova.file: 1.0.1,
org.apache.cordova.file-transfer: 0.4.2{panel}
was (Author: robinzeggelaar):
Dear Ian,
The project was created after upgrading Cordova and Phonegap via NPM. The
plugins were added using Cordova plugin add org.apache.cordova.x. Am i right
to assume this is the correct way to handle things?
I will look into updating/re-installing and get back to you with the results.
UPDATE: I just removed all my plugins and re-added them using the CLI. The same
problem persists. I'm really curious as to where you got the line of code you
showed from. Every git repo i check does not contain the line you quoted. See:
https://github.com/apache/cordova-plugin-file/blob/master/www/Entry.js
setMetadata fails silently
--
Key: CB-6351
URL: https://issues.apache.org/jira/browse/CB-6351
Project: Apache Cordova
Issue Type: Bug
Components: Plugin File
Affects Versions: 3.4.0
Reporter: Robin Zeggelaar
Assignee: Ian Clelland
Labels: setMetadata
In Cordova 3.0.4 the setMetadata call on iOS fails silently. Android does not
seem to have this issue.
On the javascript side the following call is made (Entry.js):
exec(successCallback, errorCallback, File, setMetadata, [this.fullPath,
metadataObject]);
This fails silently on the native end. My callbacks are not invoked. I fixed
this by changing this.fullPath to this.toURL(), conform the changes to the
File plugin. After this change the callbacks did get invoked properly.
Could you take a look at this and fix it in a future release?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CB-6351) setMetadata fails silently
[
https://issues.apache.org/jira/browse/CB-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949024#comment-13949024
]
Robin Zeggelaar edited comment on CB-6351 at 3/27/14 10:14 AM:
---
Dear Ian,
The project was created after upgrading Cordova and Phonegap via NPM. The
plugins were added using Cordova plugin add org.apache.cordova.x. Am i right
to assume this is the correct way to handle things?
I will look into updating/re-installing and get back to you with the results.
UPDATE: I just removed all my plugins and re-added them using the CLI. I used
{panel}cordova plugin add org.apache.cordova.file{panel} The Entry.js file is
still not containing the line you quoted. If it is of any help, the
cordova_plugins.js file is showwing the following:
{panel}org.apache.cordova.dialogs: 0.2.6,
org.apache.cordova.network-information: 0.2.7,
org.apache.cordova.console: 0.2.7,
org.apache.cordova.plugins.PowerManagement: 0.1.0,
org.apache.cordova.file: 1.0.1,
org.apache.cordova.file-transfer: 0.4.2{panel}
was (Author: robinzeggelaar):
Dear Ian,
The project was created after upgrading Cordova and Phonegap via NPM. The
plugins were added using Cordova plugin add org.apache.cordova.x. Am i right
to assume this is the correct way to handle things?
I will look into updating/re-installing and get back to you with the results.
UPDATE: I just removed all my plugins and re-added them using the CLI. I used
{panel}cordova plugin add org.apache.cordova.file{panel} The Entry.js file is
still not containing the line you quoted. If it is of any help, the
cordova_plugins.js file is showwing the following for the file plugin:
{panel}org.apache.cordova.dialogs: 0.2.6,
org.apache.cordova.network-information: 0.2.7,
org.apache.cordova.console: 0.2.7,
org.apache.cordova.plugins.PowerManagement: 0.1.0,
org.apache.cordova.file: 1.0.1,
org.apache.cordova.file-transfer: 0.4.2{panel}
setMetadata fails silently
--
Key: CB-6351
URL: https://issues.apache.org/jira/browse/CB-6351
Project: Apache Cordova
Issue Type: Bug
Components: Plugin File
Affects Versions: 3.4.0
Reporter: Robin Zeggelaar
Assignee: Ian Clelland
Labels: setMetadata
In Cordova 3.0.4 the setMetadata call on iOS fails silently. Android does not
seem to have this issue.
On the javascript side the following call is made (Entry.js):
exec(successCallback, errorCallback, File, setMetadata, [this.fullPath,
metadataObject]);
This fails silently on the native end. My callbacks are not invoked. I fixed
this by changing this.fullPath to this.toURL(), conform the changes to the
File plugin. After this change the callbacks did get invoked properly.
Could you take a look at this and fix it in a future release?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6351) setMetadata fails silently
[
https://issues.apache.org/jira/browse/CB-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949227#comment-13949227
]
Ian Clelland commented on CB-6351:
--
Thanks for checking that, [~RobinZeggelaar] -- I ran the file through {{git
blame}}, and saw that it is only fixed in the dev branch. I merged in the pull
request https://github.com/apache/cordova-plugin-file/pull/33 about three weeks
ago, and promptly forgot about it.
You can see it fixed on the dev branch here:
https://github.com/apache/cordova-plugin-file/blob/dev/www/Entry.js#L89
I'll see if I can get a 1.0.2 release put together next week that will address
this.
Thanks,
Ian
setMetadata fails silently
--
Key: CB-6351
URL: https://issues.apache.org/jira/browse/CB-6351
Project: Apache Cordova
Issue Type: Bug
Components: Plugin File
Affects Versions: 3.4.0
Reporter: Robin Zeggelaar
Assignee: Ian Clelland
Labels: setMetadata
In Cordova 3.0.4 the setMetadata call on iOS fails silently. Android does not
seem to have this issue.
On the javascript side the following call is made (Entry.js):
exec(successCallback, errorCallback, File, setMetadata, [this.fullPath,
metadataObject]);
This fails silently on the native end. My callbacks are not invoked. I fixed
this by changing this.fullPath to this.toURL(), conform the changes to the
File plugin. After this change the callbacks did get invoked properly.
Could you take a look at this and fix it in a future release?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6351) setMetadata fails silently
[ https://issues.apache.org/jira/browse/CB-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949231#comment-13949231 ] ASF GitHub Bot commented on CB-6351: Github user clelland commented on the pull request: https://github.com/apache/cordova-plugin-file/pull/33#issuecomment-38797238 See [CB-6351](https://issues.apache.org/jira/browse/CB-6351) as well -- this was also reported on JIRA while still on the dev branch. setMetadata fails silently -- Key: CB-6351 URL: https://issues.apache.org/jira/browse/CB-6351 Project: Apache Cordova Issue Type: Bug Components: Plugin File Affects Versions: 3.4.0 Reporter: Robin Zeggelaar Assignee: Ian Clelland Labels: setMetadata In Cordova 3.0.4 the setMetadata call on iOS fails silently. Android does not seem to have this issue. On the javascript side the following call is made (Entry.js): exec(successCallback, errorCallback, File, setMetadata, [this.fullPath, metadataObject]); This fails silently on the native end. My callbacks are not invoked. I fixed this by changing this.fullPath to this.toURL(), conform the changes to the File plugin. After this change the callbacks did get invoked properly. Could you take a look at this and fix it in a future release? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6347) Camera-Copy Image failed !
[ https://issues.apache.org/jira/browse/CB-6347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949235#comment-13949235 ] Ian Clelland commented on CB-6347: -- Hi, [~glmnbeyond] -- can you check this again with the dev version of File? The fix for CB-6352 should have resolved this. I'm not seeing the JSON error any more on my mobilespec. Camera-Copy Image failed ! - Key: CB-6347 URL: https://issues.apache.org/jira/browse/CB-6347 Project: Apache Cordova Issue Type: Bug Components: iOS, mobile-spec, Plugin Camera, Plugin File Affects Versions: 3.4.0 Environment: org.apache.cordova.camera version: 0.2.9-dev Reporter: glmnbeyond Assignee: Ian Clelland Steps to reproduce it: 1) Using createmobilespec.sh to create mobilespec project 2) Load mobile-spec tests 3) Navigate to Camera and getPicture() 4) Click Copy Image Results: Copy image succeeded, but no results got outputted! Expected: FileEntry.copyTo success! If I try catch the function log, there is an exception says TypeError: JSON.stringify cannot serialize cyclic structures -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-6345) No installed handlers for this URL when using 'resolveLocalFileSystemURL'
[
https://issues.apache.org/jira/browse/CB-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Clelland updated CB-6345:
-
Component/s: Plugin File
No installed handlers for this URL when using 'resolveLocalFileSystemURL'
-
Key: CB-6345
URL: https://issues.apache.org/jira/browse/CB-6345
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File
Affects Versions: 3.4.0
Environment: Android 4.4.x, cordova-plugin-camera v 0.2.8,
cordova-plugin-file v 1.01
Reporter: David Pesce
After taking a picture, the imageURI that is returned cannot be handled by
window.resolveLocalFileSystemURL.
{code}
function movePhoto(imageURI){
console.log(Image URI:+ imageURI)
window.resolveLocalFileSystemURL(imageURI, resolveOnSuccess, resOnError);
}
{code}
console displays:
file:///storage/sdcard/Android/data/com.openht.oht/cache/1395760800560.jpg
resOnError is always called with an encoding error (5).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6345) No installed handlers for this URL when using 'resolveLocalFileSystemURL'
[
https://issues.apache.org/jira/browse/CB-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949246#comment-13949246
]
Ian Clelland commented on CB-6345:
--
I think that this is the same fundamental issue as CB-6300: The Camera and File
plugins have a different opinion of where the temporary files should live.
Previously, File would happily resolve files anywhere on the file system, but
since v1.0.0, file systems are properly sandboxed from each other, and File
will not resolve a file if it is not contained in a registered file system.
There are two ways to fix this: Either install the
{{org.apache.cordova.file-system-roots}} plugin, which can grant access to the
entire device filesystem, or install the development version of File, which
will use the same location for temporary files as Camera (or wait for File
1.0.2, which will include this change).
No installed handlers for this URL when using 'resolveLocalFileSystemURL'
-
Key: CB-6345
URL: https://issues.apache.org/jira/browse/CB-6345
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File
Affects Versions: 3.4.0
Environment: Android 4.4.x, cordova-plugin-camera v 0.2.8,
cordova-plugin-file v 1.01
Reporter: David Pesce
After taking a picture, the imageURI that is returned cannot be handled by
window.resolveLocalFileSystemURL.
{code}
function movePhoto(imageURI){
console.log(Image URI:+ imageURI)
window.resolveLocalFileSystemURL(imageURI, resolveOnSuccess, resOnError);
}
{code}
console displays:
file:///storage/sdcard/Android/data/com.openht.oht/cache/1395760800560.jpg
resOnError is always called with an encoding error (5).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6345) No installed handlers for this URL when using 'resolveLocalFileSystemURL'
[
https://issues.apache.org/jira/browse/CB-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949249#comment-13949249
]
Ian Clelland commented on CB-6345:
--
[~davidpesce], btw, the fix for CB-6300 just landed in dev yesterday; if you're
already running the dev branch of cordova-plugin-file, try updating and see if
is fixed now.
No installed handlers for this URL when using 'resolveLocalFileSystemURL'
-
Key: CB-6345
URL: https://issues.apache.org/jira/browse/CB-6345
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File
Affects Versions: 3.4.0
Environment: Android 4.4.x, cordova-plugin-camera v 0.2.8,
cordova-plugin-file v 1.01
Reporter: David Pesce
After taking a picture, the imageURI that is returned cannot be handled by
window.resolveLocalFileSystemURL.
{code}
function movePhoto(imageURI){
console.log(Image URI:+ imageURI)
window.resolveLocalFileSystemURL(imageURI, resolveOnSuccess, resOnError);
}
{code}
console displays:
file:///storage/sdcard/Android/data/com.openht.oht/cache/1395760800560.jpg
resOnError is always called with an encoding error (5).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CB-6345) No installed handlers for this URL when using 'resolveLocalFileSystemURL'
[
https://issues.apache.org/jira/browse/CB-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Clelland reassigned CB-6345:
Assignee: Ian Clelland
No installed handlers for this URL when using 'resolveLocalFileSystemURL'
-
Key: CB-6345
URL: https://issues.apache.org/jira/browse/CB-6345
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File
Affects Versions: 3.4.0
Environment: Android 4.4.x, cordova-plugin-camera v 0.2.8,
cordova-plugin-file v 1.01
Reporter: David Pesce
Assignee: Ian Clelland
After taking a picture, the imageURI that is returned cannot be handled by
window.resolveLocalFileSystemURL.
{code}
function movePhoto(imageURI){
console.log(Image URI:+ imageURI)
window.resolveLocalFileSystemURL(imageURI, resolveOnSuccess, resOnError);
}
{code}
console displays:
file:///storage/sdcard/Android/data/com.openht.oht/cache/1395760800560.jpg
resOnError is always called with an encoding error (5).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CB-6352) FileSystem objects are not JSON-serializable
[
https://issues.apache.org/jira/browse/CB-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Clelland resolved CB-6352.
--
Resolution: Fixed
FileSystem objects are not JSON-serializable
Key: CB-6352
URL: https://issues.apache.org/jira/browse/CB-6352
Project: Apache Cordova
Issue Type: Bug
Components: Plugin File
Reporter: Ian Clelland
Assignee: Ian Clelland
Attempting to render a FileSystem object (or a FileEntry, or DirectoryEntry,
or any other object with a FileSystem contained it) results in the error:
{code}
TypeError: JSON.stringify cannot serialize cyclic structures.
{code}
(This is new behaviour with File 1.0.0)
This happens because of a cycle in the FileSystem object structure:
FileSystem contains a 'root' property, which is a DirectoryEntry. The
DirectoryEntry contains a 'filesystem' property, which is the original
FileSystem.
I think that we can solve this with a {{.toJSON()}} method on the FileSystem
object. This is supported (tested) on iOS and Android, and appears to be
present in all versions of WebKit back to 2009. I don't believe that the
presence of this method should have any side effects on webviews (if there
are any) which do not support it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6343) FileTransfer failed to upload image
[
https://issues.apache.org/jira/browse/CB-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949256#comment-13949256
]
Ian Clelland commented on CB-6343:
--
What platform is this failing on?
FileTransfer failed to upload image
---
Key: CB-6343
URL: https://issues.apache.org/jira/browse/CB-6343
Project: Apache Cordova
Issue Type: Bug
Components: mobile-spec, Plugin Camera, Plugin File Transfer
Affects Versions: 3.3.0
Environment: org.apache.cordova.file-transfer version=0.4.3-dev
Reporter: glmnbeyond
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to Camera and Choose File
4) Click Upload Image
Results:
upload failed:
{code:1,source:{color:red}blob:file:///d5393bda-79b0-470c-8a1d-73e828c2f473{color},target:http://cordova-filetransfer.jitsu.com/upload,http_status:null,body:null}
Expected:
upload complete
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CB-6320) Incorrect claim of BB10 support for beep and vibrate
[ https://issues.apache.org/jira/browse/CB-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Kinard updated CB-6320: -- Issue Type: Bug (was: Task) Incorrect claim of BB10 support for beep and vibrate Key: CB-6320 URL: https://issues.apache.org/jira/browse/CB-6320 Project: Apache Cordova Issue Type: Bug Components: BlackBerry, Plugins Affects Versions: 2.3.0 Reporter: Staci Cooper Assignee: Staci Cooper Priority: Minor http://cordova.apache.org/docs/en/2.3.0/cordova_notification_notification.md.html#Notification 2.3 docs list support for BlackBerry WebWorks OS 5.0 and higher for all notification functions, although beep and vibrate are not supported for BlackBerry 10. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-6331) Typo in config-path (help.txt)
[
https://issues.apache.org/jira/browse/CB-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Kinard resolved CB-6331.
---
Resolution: Fixed
Fix Version/s: (was: Master)
3.5.0
Pull request merged. Thanks for the submission!
Please close the pull request.
Typo in config-path (help.txt)
--
Key: CB-6331
URL: https://issues.apache.org/jira/browse/CB-6331
Project: Apache Cordova
Issue Type: Bug
Components: CLI, Docs
Affects Versions: 3.4.0
Reporter: Philipp Austermann
Priority: Minor
Labels: cordova-cli, documentation
Fix For: 3.5.0
The helptext of the cordova CLI states
{noformat}
CONFIG is a json string whose key/values will be included
in [PATH]/.codova/config.json
{noformat}
I am assuming it should be {code}in
[PATH]/.cordova/config.json {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6331) Typo in config-path (help.txt)
[
https://issues.apache.org/jira/browse/CB-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949335#comment-13949335
]
Marcel Kinard commented on CB-6331:
---
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=4da7f4e373c6292d09800200faf9479827110a06
Typo in config-path (help.txt)
--
Key: CB-6331
URL: https://issues.apache.org/jira/browse/CB-6331
Project: Apache Cordova
Issue Type: Bug
Components: CLI, Docs
Affects Versions: 3.4.0
Reporter: Philipp Austermann
Priority: Minor
Labels: cordova-cli, documentation
Fix For: 3.5.0
The helptext of the cordova CLI states
{noformat}
CONFIG is a json string whose key/values will be included
in [PATH]/.codova/config.json
{noformat}
I am assuming it should be {code}in
[PATH]/.cordova/config.json {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6331) Typo in config-path (help.txt)
[
https://issues.apache.org/jira/browse/CB-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949362#comment-13949362
]
ASF GitHub Bot commented on CB-6331:
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-cli/pull/147
Typo in config-path (help.txt)
--
Key: CB-6331
URL: https://issues.apache.org/jira/browse/CB-6331
Project: Apache Cordova
Issue Type: Bug
Components: CLI, Docs
Affects Versions: 3.4.0
Reporter: Philipp Austermann
Priority: Minor
Labels: cordova-cli, documentation
Fix For: 3.5.0
The helptext of the cordova CLI states
{noformat}
CONFIG is a json string whose key/values will be included
in [PATH]/.codova/config.json
{noformat}
I am assuming it should be {code}in
[PATH]/.cordova/config.json {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6358) [IOS7.1] Keyboard plugin shinkView with or without disableScrollingInShrinkView scroll the main view and remove my header on IOS 7.0 its OK
Cedric LOMBARDOT created CB-6358: Summary: [IOS7.1] Keyboard plugin shinkView with or without disableScrollingInShrinkView scroll the main view and remove my header on IOS 7.0 its OK Key: CB-6358 URL: https://issues.apache.org/jira/browse/CB-6358 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugins Affects Versions: 3.4.0 Environment: IOS 7.1 Cordova 3.4 Reporter: Cedric LOMBARDOT In my webview, i have a top fixed header and one scrollable div with the form. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-6358) [IOS7.1] Keyboard plugin shinkView with or without disableScrollingInShrinkView scroll the main view and remove my header on IOS 7.0 its OK
[ https://issues.apache.org/jira/browse/CB-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric LOMBARDOT updated CB-6358: - Description: In my webview, i have a top fixed header and one scrollable div with the form. When i focus a field with Keyboard.hideFormAccessoryBar(true); Keyboard.shrinkView(true); Keyboard.disableScrollingInShrinkView(true); was:In my webview, i have a top fixed header and one scrollable div with the form. [IOS7.1] Keyboard plugin shinkView with or without disableScrollingInShrinkView scroll the main view and remove my header on IOS 7.0 its OK --- Key: CB-6358 URL: https://issues.apache.org/jira/browse/CB-6358 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugins Affects Versions: 3.4.0 Environment: IOS 7.1 Cordova 3.4 Reporter: Cedric LOMBARDOT In my webview, i have a top fixed header and one scrollable div with the form. When i focus a field with Keyboard.hideFormAccessoryBar(true); Keyboard.shrinkView(true); Keyboard.disableScrollingInShrinkView(true); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-6351) setMetadata fails silently
[ https://issues.apache.org/jira/browse/CB-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Clelland resolved CB-6351. -- Resolution: Fixed Resolved on dev branch with commit 70a1b72 setMetadata fails silently -- Key: CB-6351 URL: https://issues.apache.org/jira/browse/CB-6351 Project: Apache Cordova Issue Type: Bug Components: Plugin File Affects Versions: 3.4.0 Reporter: Robin Zeggelaar Assignee: Ian Clelland Labels: setMetadata In Cordova 3.0.4 the setMetadata call on iOS fails silently. Android does not seem to have this issue. On the javascript side the following call is made (Entry.js): exec(successCallback, errorCallback, File, setMetadata, [this.fullPath, metadataObject]); This fails silently on the native end. My callbacks are not invoked. I fixed this by changing this.fullPath to this.toURL(), conform the changes to the File plugin. After this change the callbacks did get invoked properly. Could you take a look at this and fix it in a future release? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-6358) [IOS7.1] Keyboard plugin shinkView with or without disableScrollingInShrinkView scroll the main view and remove my header on IOS 7.0 its OK
[ https://issues.apache.org/jira/browse/CB-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric LOMBARDOT updated CB-6358: - Description: In my webview, i have a top fixed header and one scrollable div with the form. When i focus a field with Keyboard.hideFormAccessoryBar(true); Keyboard.shrinkView(true); Keyboard.disableScrollingInShrinkView(true); in ios7.0 my header is still visible. In io7.1 my header is scrolled out. was: In my webview, i have a top fixed header and one scrollable div with the form. When i focus a field with Keyboard.hideFormAccessoryBar(true); Keyboard.shrinkView(true); Keyboard.disableScrollingInShrinkView(true); Labels: (was: patch) [IOS7.1] Keyboard plugin shinkView with or without disableScrollingInShrinkView scroll the main view and remove my header on IOS 7.0 its OK --- Key: CB-6358 URL: https://issues.apache.org/jira/browse/CB-6358 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugins Affects Versions: 3.4.0 Environment: IOS 7.1 Cordova 3.4 Reporter: Cedric LOMBARDOT In my webview, i have a top fixed header and one scrollable div with the form. When i focus a field with Keyboard.hideFormAccessoryBar(true); Keyboard.shrinkView(true); Keyboard.disableScrollingInShrinkView(true); in ios7.0 my header is still visible. In io7.1 my header is scrolled out. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-6358) [IOS7.1] Keyboard plugin shinkView with or without disableScrollingInShrinkView scroll the main view and remove my header on IOS 7.0 its OK
[ https://issues.apache.org/jira/browse/CB-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cedric LOMBARDOT updated CB-6358: - Description: In my webview, i have a top fixed header and one scrollable div with the form. When i focus a field with Keyboard.hideFormAccessoryBar(true); Keyboard.shrinkView(true); Keyboard.disableScrollingInShrinkView(true); in ios7.0 my header is still visible. In io7.1 my header is scrolled out. I think its also related to my second problem, when the webview is closed if i have an element in bottom:0 it was displayed out of the frame. Seems the webView size increase each time i open the keyboard was: In my webview, i have a top fixed header and one scrollable div with the form. When i focus a field with Keyboard.hideFormAccessoryBar(true); Keyboard.shrinkView(true); Keyboard.disableScrollingInShrinkView(true); in ios7.0 my header is still visible. In io7.1 my header is scrolled out. [IOS7.1] Keyboard plugin shinkView with or without disableScrollingInShrinkView scroll the main view and remove my header on IOS 7.0 its OK --- Key: CB-6358 URL: https://issues.apache.org/jira/browse/CB-6358 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugins Affects Versions: 3.4.0 Environment: IOS 7.1 Cordova 3.4 Reporter: Cedric LOMBARDOT In my webview, i have a top fixed header and one scrollable div with the form. When i focus a field with Keyboard.hideFormAccessoryBar(true); Keyboard.shrinkView(true); Keyboard.disableScrollingInShrinkView(true); in ios7.0 my header is still visible. In io7.1 my header is scrolled out. I think its also related to my second problem, when the webview is closed if i have an element in bottom:0 it was displayed out of the frame. Seems the webView size increase each time i open the keyboard -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6346) [BlackBerry10] Commit node_modules
[ https://issues.apache.org/jira/browse/CB-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949435#comment-13949435 ] ASF subversion and git services commented on CB-6346: - Commit 1139813cd8b7ee4b1a103ada5577cab79b2c39e6 in cordova-blackberry's branch refs/heads/master from [~bhigg...@blackberry.com] [ https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;h=1139813 ] CB-6346 - Add node_modules to source control [BlackBerry10] Commit node_modules -- Key: CB-6346 URL: https://issues.apache.org/jira/browse/CB-6346 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 3.4.0 Reporter: Bryan Higgins Assignee: Bryan Higgins Fix For: 3.5.0 We should commit node_modules for cordova-blackberry rather than running npm install within the init script. cordova-android has already moved to this model. https://www.npmjs.org/doc/faq.html#Should-I-check-my-node_modules-folder-into-git -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6346) [BlackBerry10] Commit node_modules
[ https://issues.apache.org/jira/browse/CB-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949436#comment-13949436 ] ASF GitHub Bot commented on CB-6346: Github user asfgit closed the pull request at: https://github.com/apache/cordova-blackberry/pull/152 [BlackBerry10] Commit node_modules -- Key: CB-6346 URL: https://issues.apache.org/jira/browse/CB-6346 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 3.4.0 Reporter: Bryan Higgins Assignee: Bryan Higgins Fix For: 3.5.0 We should commit node_modules for cordova-blackberry rather than running npm install within the init script. cordova-android has already moved to this model. https://www.npmjs.org/doc/faq.html#Should-I-check-my-node_modules-folder-into-git -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6362) The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:
Gilles Benzerrouk created CB-6362: - Summary: The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor: Key: CB-6362 URL: https://issues.apache.org/jira/browse/CB-6362 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin InAppBrowser Affects Versions: 3.4.0, 3.3.0 Environment: Cordova 3.3 or 3.4 Xcode 5.0.1. Test on Ipad 2, Iphone 3GS Reporter: Gilles Benzerrouk When i try to launch the InAppBrowser with : var ref =window.open(urlCt, '_blank','location=yes,closebuttoncaption=Fermer,EnableViewPortScale=yes'); InAppBrowser crash. Here the log on Xcode 5.0.1 2014-03-26 08:48:38.480 ParisFood[405:707] -[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10 2014-03-26 08:48:38.485 ParisFood[405:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10' *** First throw call stack: (0x30fc588f 0x37303259 0x30fc8a9b 0x30fc7915 0x30f22650 0x49409 0x47bfd 0x43f8f 0x43bc5 0x223c9 0x21cef 0x21899 0x21a7f 0x21991 0x30f241fb 0x318e1747 0x30f99ad3 0x30f9929f 0x30f98045 0x30f1b4a5 0x30f1b36d 0x32f95439 0x3067ecd5 0x2808f 0x28050) terminate called throwing an exception Before on cordova 2.9 everything was working well !!! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6363) The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:
Gilles Benzerrouk created CB-6363: - Summary: The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor: Key: CB-6363 URL: https://issues.apache.org/jira/browse/CB-6363 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin InAppBrowser Affects Versions: 3.4.0, 3.3.0 Environment: Cordova 3.3 or 3.4 Xcode 5.0.1. Test on Ipad 2, Iphone 3GS Reporter: Gilles Benzerrouk When i try to launch the InAppBrowser with : var ref =window.open(urlCt, '_blank','location=yes,closebuttoncaption=Fermer,EnableViewPortScale=yes'); InAppBrowser crash. Here the log on Xcode 5.0.1 2014-03-26 08:48:38.480 ParisFood[405:707] -[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10 2014-03-26 08:48:38.485 ParisFood[405:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10' *** First throw call stack: (0x30fc588f 0x37303259 0x30fc8a9b 0x30fc7915 0x30f22650 0x49409 0x47bfd 0x43f8f 0x43bc5 0x223c9 0x21cef 0x21899 0x21a7f 0x21991 0x30f241fb 0x318e1747 0x30f99ad3 0x30f9929f 0x30f98045 0x30f1b4a5 0x30f1b36d 0x32f95439 0x3067ecd5 0x2808f 0x28050) terminate called throwing an exception Before on cordova 2.9 everything was working well !!! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6364) The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:
Gilles Benzerrouk created CB-6364: - Summary: The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor: Key: CB-6364 URL: https://issues.apache.org/jira/browse/CB-6364 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin InAppBrowser Affects Versions: 3.4.0, 3.3.0 Environment: Cordova 3.3 or 3.4 Xcode 5.0.1. Test on Ipad 2, Iphone 3GS Reporter: Gilles Benzerrouk When i try to launch the InAppBrowser with : var ref =window.open(urlCt, '_blank','location=yes,closebuttoncaption=Fermer,EnableViewPortScale=yes'); InAppBrowser crash. Here the log on Xcode 5.0.1 2014-03-26 08:48:38.480 ParisFood[405:707] -[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10 2014-03-26 08:48:38.485 ParisFood[405:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10' *** First throw call stack: (0x30fc588f 0x37303259 0x30fc8a9b 0x30fc7915 0x30f22650 0x49409 0x47bfd 0x43f8f 0x43bc5 0x223c9 0x21cef 0x21899 0x21a7f 0x21991 0x30f241fb 0x318e1747 0x30f99ad3 0x30f9929f 0x30f98045 0x30f1b4a5 0x30f1b36d 0x32f95439 0x3067ecd5 0x2808f 0x28050) terminate called throwing an exception Before on cordova 2.9 everything was working well !!! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6365) The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:
Gilles Benzerrouk created CB-6365: - Summary: The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor: Key: CB-6365 URL: https://issues.apache.org/jira/browse/CB-6365 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin InAppBrowser Affects Versions: 3.4.0, 3.3.0 Environment: Cordova 3.3 or 3.4 Xcode 5.0.1. Test on Ipad 2, Iphone 3GS Reporter: Gilles Benzerrouk When i try to launch the InAppBrowser with : var ref =window.open(urlCt, '_blank','location=yes,closebuttoncaption=Fermer,EnableViewPortScale=yes'); InAppBrowser crash. Here the log on Xcode 5.0.1 2014-03-26 08:48:38.480 ParisFood[405:707] -[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10 2014-03-26 08:48:38.485 ParisFood[405:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10' *** First throw call stack: (0x30fc588f 0x37303259 0x30fc8a9b 0x30fc7915 0x30f22650 0x49409 0x47bfd 0x43f8f 0x43bc5 0x223c9 0x21cef 0x21899 0x21a7f 0x21991 0x30f241fb 0x318e1747 0x30f99ad3 0x30f9929f 0x30f98045 0x30f1b4a5 0x30f1b36d 0x32f95439 0x3067ecd5 0x2808f 0x28050) terminate called throwing an exception Before on cordova 2.9 everything was working well !!! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-2606) Add support for icon elements in config.xml
[
https://issues.apache.org/jira/browse/CB-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949596#comment-13949596
]
ASF GitHub Bot commented on CB-2606:
Github user cmarcelk commented on the pull request:
https://github.com/apache/cordova-cli/pull/126#issuecomment-38831161
In a broad sense this looks reasonable.
In the config.xml, why is there width and height attributes when using
cdv:platform=android and cdv:density=mdpi? Is hope to reuse the same icon
element for iOS and other non-Android platforms? But doing so doesn't seem like
it is meant to be compatible with cdv:platform=android. Or is it meant to be
an alternate way of specifying cdv:density=mdpi in the Android case?
I don't see where your code uses the id attribute in the icon element.
What is that element supposed to do? And what happens when it's not present in
the icon element?
It would be great to see some corresponding docs for this (i.e.,
cordova-docs). Those docs would describe from the end-users view how they would
consume this new capability.
When it inevitably comes time to do this for splash screens, will this icon
approach work for splash screens?
Add support for icon elements in config.xml
-
Key: CB-2606
URL: https://issues.apache.org/jira/browse/CB-2606
Project: Apache Cordova
Issue Type: Wish
Components: Docs
Reporter: Filip Maj
Assignee: Mark Koudritsky
This feature would add support for specifying the application icon by
changing values inside the {{config.xml}} document.
Relevant details for Cordova:
- {{icon}} elements _may_ have {{width}} and {{height}} attributes
representing the preferred size of the icon in CSS pixels.
- {{icon}} elements _must_ have a {{src}} attribute, which contains a path
string relative to the {{www/}} folder (or equivalent) in the platform.
See [the Widget Spec's section on
icons|http://www.w3.org/TR/widgets/#the-icon-element-and-its-attributes] for
specifics.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-5175) Fix core plugins that incorrectly run on main thread
[ https://issues.apache.org/jira/browse/CB-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949640#comment-13949640 ] ASF subversion and git services commented on CB-5175: - Commit 223d08626df36c0f386af3fe609d0a36c450d6d9 in cordova-plugin-file-transfer's branch refs/heads/dev from torrmal [ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file-transfer.git;h=223d086 ] [CB-5175] CDVFileTransfer asynchronous download (Fixes #24) Since download can take time, for it to be non-blocking, moved the call to a separate thread. Fix core plugins that incorrectly run on main thread Key: CB-5175 URL: https://issues.apache.org/jira/browse/CB-5175 Project: Apache Cordova Issue Type: Bug Components: Docs, Plugin Device Orientation, Plugin File, Plugin Media Reporter: Mike Billau Assignee: Mike Billau Priority: Minor After CB-4133 we are able to detect and log when a plugin incorrectly does work on the UI thread instead of a worker thread. We should go back and verify that all of our plugins follow this practice - eat your own dogfood type of thing. We know there are problems with: Android: file, compass iOS: media Docs: Need to verify plugin author guide is still valid -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CB-6363) The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:
[ https://issues.apache.org/jira/browse/CB-6363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Clelland closed CB-6363. Resolution: Duplicate The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor: - Key: CB-6363 URL: https://issues.apache.org/jira/browse/CB-6363 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin InAppBrowser Affects Versions: 3.3.0, 3.4.0 Environment: Cordova 3.3 or 3.4 Xcode 5.0.1. Test on Ipad 2, Iphone 3GS Reporter: Gilles Benzerrouk Labels: InAppBrowser, crash, ios5, ios6 Original Estimate: 3h Remaining Estimate: 3h When i try to launch the InAppBrowser with : var ref =window.open(urlCt, '_blank','location=yes,closebuttoncaption=Fermer,EnableViewPortScale=yes'); InAppBrowser crash. Here the log on Xcode 5.0.1 2014-03-26 08:48:38.480 ParisFood[405:707] -[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10 2014-03-26 08:48:38.485 ParisFood[405:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10' *** First throw call stack: (0x30fc588f 0x37303259 0x30fc8a9b 0x30fc7915 0x30f22650 0x49409 0x47bfd 0x43f8f 0x43bc5 0x223c9 0x21cef 0x21899 0x21a7f 0x21991 0x30f241fb 0x318e1747 0x30f99ad3 0x30f9929f 0x30f98045 0x30f1b4a5 0x30f1b36d 0x32f95439 0x3067ecd5 0x2808f 0x28050) terminate called throwing an exception Before on cordova 2.9 everything was working well !!! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CB-6365) The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:
[ https://issues.apache.org/jira/browse/CB-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Clelland closed CB-6365. Resolution: Duplicate The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor: - Key: CB-6365 URL: https://issues.apache.org/jira/browse/CB-6365 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin InAppBrowser Affects Versions: 3.3.0, 3.4.0 Environment: Cordova 3.3 or 3.4 Xcode 5.0.1. Test on Ipad 2, Iphone 3GS Reporter: Gilles Benzerrouk Labels: InAppBrowser, crash, ios5, ios6 Original Estimate: 3h Remaining Estimate: 3h When i try to launch the InAppBrowser with : var ref =window.open(urlCt, '_blank','location=yes,closebuttoncaption=Fermer,EnableViewPortScale=yes'); InAppBrowser crash. Here the log on Xcode 5.0.1 2014-03-26 08:48:38.480 ParisFood[405:707] -[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10 2014-03-26 08:48:38.485 ParisFood[405:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10' *** First throw call stack: (0x30fc588f 0x37303259 0x30fc8a9b 0x30fc7915 0x30f22650 0x49409 0x47bfd 0x43f8f 0x43bc5 0x223c9 0x21cef 0x21899 0x21a7f 0x21991 0x30f241fb 0x318e1747 0x30f99ad3 0x30f9929f 0x30f98045 0x30f1b4a5 0x30f1b36d 0x32f95439 0x3067ecd5 0x2808f 0x28050) terminate called throwing an exception Before on cordova 2.9 everything was working well !!! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CB-6362) The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:
[ https://issues.apache.org/jira/browse/CB-6362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Clelland closed CB-6362. Resolution: Duplicate The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor: - Key: CB-6362 URL: https://issues.apache.org/jira/browse/CB-6362 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin InAppBrowser Affects Versions: 3.3.0, 3.4.0 Environment: Cordova 3.3 or 3.4 Xcode 5.0.1. Test on Ipad 2, Iphone 3GS Reporter: Gilles Benzerrouk Labels: InAppBrowser, crash, ios5, ios6 Original Estimate: 3h Remaining Estimate: 3h When i try to launch the InAppBrowser with : var ref =window.open(urlCt, '_blank','location=yes,closebuttoncaption=Fermer,EnableViewPortScale=yes'); InAppBrowser crash. Here the log on Xcode 5.0.1 2014-03-26 08:48:38.480 ParisFood[405:707] -[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10 2014-03-26 08:48:38.485 ParisFood[405:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10' *** First throw call stack: (0x30fc588f 0x37303259 0x30fc8a9b 0x30fc7915 0x30f22650 0x49409 0x47bfd 0x43f8f 0x43bc5 0x223c9 0x21cef 0x21899 0x21a7f 0x21991 0x30f241fb 0x318e1747 0x30f99ad3 0x30f9929f 0x30f98045 0x30f1b4a5 0x30f1b36d 0x32f95439 0x3067ecd5 0x2808f 0x28050) terminate called throwing an exception Before on cordova 2.9 everything was working well !!! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CB-6361) The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:
[ https://issues.apache.org/jira/browse/CB-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Clelland closed CB-6361. Resolution: Duplicate The InAppBrowser crash on IOS 6.1 and IOS 5.1 NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor: - Key: CB-6361 URL: https://issues.apache.org/jira/browse/CB-6361 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin InAppBrowser Affects Versions: 3.3.0, 3.4.0 Environment: Cordova 3.3 or 3.4 Xcode 5.0.1. Test on Ipad 2, Iphone 3GS Reporter: Gilles Benzerrouk Labels: InAppBrowser, crash, ios5, ios6 Original Estimate: 3h Remaining Estimate: 3h When i try to launch the InAppBrowser with : var ref =window.open(urlCt, '_blank','location=yes,closebuttoncaption=Fermer,EnableViewPortScale=yes'); InAppBrowser crash. Here the log on Xcode 5.0.1 2014-03-26 08:48:38.480 ParisFood[405:707] -[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10 2014-03-26 08:48:38.485 ParisFood[405:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UILabel setMinimumScaleFactor:]: unrecognized selector sent to instance 0xecb7b10' *** First throw call stack: (0x30fc588f 0x37303259 0x30fc8a9b 0x30fc7915 0x30f22650 0x49409 0x47bfd 0x43f8f 0x43bc5 0x223c9 0x21cef 0x21899 0x21a7f 0x21991 0x30f241fb 0x318e1747 0x30f99ad3 0x30f9929f 0x30f98045 0x30f1b4a5 0x30f1b36d 0x32f95439 0x3067ecd5 0x2808f 0x28050) terminate called throwing an exception Before on cordova 2.9 everything was working well !!! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Clelland reassigned CB-6359:
Assignee: Ian Clelland
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On Mac
Cordova info
Current Node Version
v0.10.25
Current Cordova CLI Version
3.4.0-0.1.0
Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
Reporter: Ralph S Theart
Assignee: Ian Clelland
Labels: android, capture
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I
already know its not something related to my set up or my code. Out of the
*10* devices one specific feature seems to fail on one specific device
(Galaxy Note 3). When you capture video and try to resolve the URI you will
always get error core 5 every single time no matter what changes you make or
conditions. Here is the code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed
the file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities. I'm more than happy to help with any testing...I built up a
rigorous excel sheet full of tests among which are all of the media type
api's. I did this because resolveLocalFileSystemURL has become a problem
child for me since 3.4 I have already submitted 3 bugs 1 of which was solved
and actually made it to the 1.0.1 File-System update. The 2nd one is solved
now too. I wouldn't care if the device this was happening to was old and was
on an older firmware like 4.0.3 but this is a popular device especially in
our database any help would be appreciated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949698#comment-13949698
]
Ian Clelland commented on CB-6359:
--
Ralph, this looks to be a very similar issue to CB-6300; where the
media-capture plugin picks its own temporary directory for files, which may be
different than the one that file wants to use.
Since the file systems are properly sandboxed now, the File plugin won't
resolve a file that doesn't reside inside one of the registered file systems.
I'm going to update media-capture to use the same path as file uses for
temporary files, which will make the dev versions of the two plugins compatible.
In the meantime, can you try installing the
{{org.apache.cordova.file-system-roots}} plugin? That plugin registers a number
of new file systems, including alternate cache directories. It should get your
app working, but I'd definitely like to know if it doesn't.
Thanks.
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On Mac
Cordova info
Current Node Version
v0.10.25
Current Cordova CLI Version
3.4.0-0.1.0
Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
Reporter: Ralph S Theart
Assignee: Ian Clelland
Labels: android, capture
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I
already know its not something related to my set up or my code. Out of the
*10* devices one specific feature seems to fail on one specific device
(Galaxy Note 3). When you capture video and try to resolve the URI you will
always get error core 5 every single time no matter what changes you make or
conditions. Here is the code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed
the file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities. I'm more than happy to help with any testing...I built up a
rigorous excel sheet full of tests among which are all of the media type
api's. I did this because resolveLocalFileSystemURL has become a problem
child for me since 3.4 I have already submitted 3 bugs 1 of which was solved
and actually made it to the 1.0.1 File-System update. The 2nd one is solved
now too. I wouldn't care if the device this was happening to was old and was
on an older firmware like 4.0.3 but this is a popular device especially in
our database any help would be appreciated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949707#comment-13949707
]
Ralph S Theart commented on CB-6359:
sure should I rm the current file system plugin first before installing
org.apache.cordova.file-system-roots?
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On Mac
Cordova info
Current Node Version
v0.10.25
Current Cordova CLI Version
3.4.0-0.1.0
Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
Reporter: Ralph S Theart
Assignee: Ian Clelland
Labels: android, capture
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I
already know its not something related to my set up or my code. Out of the
*10* devices one specific feature seems to fail on one specific device
(Galaxy Note 3). When you capture video and try to resolve the URI you will
always get error core 5 every single time no matter what changes you make or
conditions. Here is the code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed
the file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities. I'm more than happy to help with any testing...I built up a
rigorous excel sheet full of tests among which are all of the media type
api's. I did this because resolveLocalFileSystemURL has become a problem
child for me since 3.4 I have already submitted 3 bugs 1 of which was solved
and actually made it to the 1.0.1 File-System update. The 2nd one is solved
now too. I wouldn't care if the device this was happening to was old and was
on an older firmware like 4.0.3 but this is a popular device especially in
our database any help would be appreciated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949714#comment-13949714
]
Ian Clelland commented on CB-6359:
--
No, install it alongside file -- file-system-roots extends file. It registers
new file system locations that your app can use. One of those should cover
{{file:/storage/extSdCard}}.
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On Mac
Cordova info
Current Node Version
v0.10.25
Current Cordova CLI Version
3.4.0-0.1.0
Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
Reporter: Ralph S Theart
Assignee: Ian Clelland
Labels: android, capture
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I
already know its not something related to my set up or my code. Out of the
*10* devices one specific feature seems to fail on one specific device
(Galaxy Note 3). When you capture video and try to resolve the URI you will
always get error core 5 every single time no matter what changes you make or
conditions. Here is the code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed
the file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities. I'm more than happy to help with any testing...I built up a
rigorous excel sheet full of tests among which are all of the media type
api's. I did this because resolveLocalFileSystemURL has become a problem
child for me since 3.4 I have already submitted 3 bugs 1 of which was solved
and actually made it to the 1.0.1 File-System update. The 2nd one is solved
now too. I wouldn't care if the device this was happening to was old and was
on an older firmware like 4.0.3 but this is a popular device especially in
our database any help would be appreciated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949718#comment-13949718
]
Ian Clelland commented on CB-6359:
--
Looks like the first thing to do is to get media-capture to return the
new-style file entry objects. After that, getting it to place files in the same
temporary directory as file does should solve this.
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On Mac
Cordova info
Current Node Version
v0.10.25
Current Cordova CLI Version
3.4.0-0.1.0
Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
Reporter: Ralph S Theart
Assignee: Ian Clelland
Labels: android, capture
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I
already know its not something related to my set up or my code. Out of the
*10* devices one specific feature seems to fail on one specific device
(Galaxy Note 3). When you capture video and try to resolve the URI you will
always get error core 5 every single time no matter what changes you make or
conditions. Here is the code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed
the file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities. I'm more than happy to help with any testing...I built up a
rigorous excel sheet full of tests among which are all of the media type
api's. I did this because resolveLocalFileSystemURL has become a problem
child for me since 3.4 I have already submitted 3 bugs 1 of which was solved
and actually made it to the 1.0.1 File-System update. The 2nd one is solved
now too. I wouldn't care if the device this was happening to was old and was
on an older firmware like 4.0.3 but this is a popular device especially in
our database any help would be appreciated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6337) Print nice error when cordova-cli hits various expected things
[ https://issues.apache.org/jira/browse/CB-6337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949726#comment-13949726 ] ASF GitHub Bot commented on CB-6337: Github user stevengill commented on the pull request: https://github.com/apache/cordova-cli/pull/150#issuecomment-38840114 Hey Josh, I will merge this in Print nice error when cordova-cli hits various expected things -- Key: CB-6337 URL: https://issues.apache.org/jira/browse/CB-6337 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.4.0 Reporter: Josh Soref Assignee: Josh Soref CB-5782 introduced a way to silence stack traces for expected failures, but it missed some spots. This is a first pass against things in CLI itself -- it doesn't cover errors coming from plugman. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5082) add BB10 support in doPlatform()
[ https://issues.apache.org/jira/browse/CB-5082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949737#comment-13949737 ] ASF GitHub Bot commented on CB-5082: Github user martincgg commented on the pull request: https://github.com/apache/cordova-cli/pull/152#issuecomment-38841084 Fixed: - No more tabs. - Brand misspelled - Included new line at the end. The cordova info command is used to get information from the dev environment, information to ask for help, or report an issue, summary of what the project contains, get information; getting relevant information about the environment, that's its only cases of use. Set a variable with 'process.env.CORDOVA_BBTOOLS' is required to provide good usage at some blackberry libraries that requires to run functions. That variable is settled and used during the js file execution, but when the control is returned to terminal, the variable is not present to be used in the terminal or by any other js file. I've made several test under Windows 7, 8 and Ubuntu, try to access to the variable with another js file, or using the terminal command (SET (Windows) or EXPORT(Linux Mac)) to list all current variables, that one it never appears in the list. Anyway, I've added logic to deal with. If the variable is present is not going to change it, not at all. If is not present is going to set the value, and then at the end of all blackberry operations it will erase it, with this in any usage case it won't affect any other process. Hi, @jsoref , What do you think about this? by the way, thanks a lot for the feedback add BB10 support in doPlatform() Key: CB-5082 URL: https://issues.apache.org/jira/browse/CB-5082 Project: Apache Cordova Issue Type: Sub-task Components: CLI Reporter: Marcel Kinard Assignee: Martin Gonzalez Priority: Minor -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949747#comment-13949747
]
Ralph S Theart commented on CB-6359:
ok maybe I missed something but media capture continues to return
file:/storage/extSdCard/DCIM/Camera/20140327_141754.mp4 may be I missed a step?
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On Mac
Cordova info
Current Node Version
v0.10.25
Current Cordova CLI Version
3.4.0-0.1.0
Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
Reporter: Ralph S Theart
Assignee: Ian Clelland
Labels: android, capture
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I
already know its not something related to my set up or my code. Out of the
*10* devices one specific feature seems to fail on one specific device
(Galaxy Note 3). When you capture video and try to resolve the URI you will
always get error core 5 every single time no matter what changes you make or
conditions. Here is the code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed
the file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities. I'm more than happy to help with any testing...I built up a
rigorous excel sheet full of tests among which are all of the media type
api's. I did this because resolveLocalFileSystemURL has become a problem
child for me since 3.4 I have already submitted 3 bugs 1 of which was solved
and actually made it to the 1.0.1 File-System update. The 2nd one is solved
now too. I wouldn't care if the device this was happening to was old and was
on an older firmware like 4.0.3 but this is a popular device especially in
our database any help would be appreciated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949758#comment-13949758
]
Ian Clelland commented on CB-6359:
--
No, that's what I'd expect to happen right now -- media capture will still
return that location, but if you have the file-system-roots plugin installed,
then resolveLocalFileSystemURL should be able to resolve that properly, rather
than failing with an ENCODING_ERR.
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On Mac
Cordova info
Current Node Version
v0.10.25
Current Cordova CLI Version
3.4.0-0.1.0
Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
Reporter: Ralph S Theart
Assignee: Ian Clelland
Labels: android, capture
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I
already know its not something related to my set up or my code. Out of the
*10* devices one specific feature seems to fail on one specific device
(Galaxy Note 3). When you capture video and try to resolve the URI you will
always get error core 5 every single time no matter what changes you make or
conditions. Here is the code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed
the file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities. I'm more than happy to help with any testing...I built up a
rigorous excel sheet full of tests among which are all of the media type
api's. I did this because resolveLocalFileSystemURL has become a problem
child for me since 3.4 I have already submitted 3 bugs 1 of which was solved
and actually made it to the 1.0.1 File-System update. The 2nd one is solved
now too. I wouldn't care if the device this was happening to was old and was
on an older firmware like 4.0.3 but this is a popular device especially in
our database any help would be appreciated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CB-5744) Unable to build Hello World application for Kindle Fire HDX tablet using PhoneGap 3.3.0
[ https://issues.apache.org/jira/browse/CB-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Gill resolved CB-5744. Resolution: Fixed Unable to build Hello World application for Kindle Fire HDX tablet using PhoneGap 3.3.0 --- Key: CB-5744 URL: https://issues.apache.org/jira/browse/CB-5744 Project: Apache Cordova Issue Type: Bug Components: Amazon FireOS Affects Versions: 3.3.0 Environment: Mac OS 10.8.5 Reporter: Jack Braidwood I'm using PhoneGap 3.3.0 along with the Amazon WebView SDK to attempt to build a Hello World application for my Kindle Fire 7 HDX tablet. I have the Android 4.4.2, 4.2.2, and 2.2 SDKs installed. I have been able to successfully build, install, and run several PhoneGap applications on my Nexus 7 Android tablet as well as the Android emulator. However the amazon-fireos build always fails with an Unhandled 'error' event. $ cordova create hello com.example.hello HelloWorld Creating a new cordova project with name HelloWorld and id com.example.hello at location /Users/jack/phonegap/hello $ cd hello $ cordova platform add amazon-fireos Checking Amazon FireOS requirements... Checking if awv_interface.jar exists... in framework/libs folder Creating amazon-fireos project... Preparing amazon-fireos project $ cordova build Generating config.xml from defaults for platform amazon-fireos Preparing amazon-fireos project Compiling app on platform amazon-fireos via command /Users/jack/phonegap/hello/platforms/amazon-fireos/cordova/build events.js:72 throw er; // Unhandled 'error' event ^ Error: spawn EACCES at errnoException (child_process.js:980:11) at Process.ChildProcess._handle.onexit (child_process.js:771:34) It looks like someone was having a similar problem (https://issues.apache.org/jira/browse/CB-4403) on BlackBerry that ended up being an environment variable issue. There are only two jar files in the WebView SDK (awv_android_factory.jar and awv_interface.jar). I tried adding both the path to the jar files to the PATH variable and both jars to the CLASSPATH, but it didn't appear to have any effect. export PATH=$PATH:/Users/jack/Downloads/awv_api export CLASSPATH=$CLASSPATH:/Users/jack/Downloads/awv_api/awv_interface.jar:/Users/jack/Downloads/awv_api/awv_android_factory.jar:. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-6002) create package validation doesn't match error report
[
https://issues.apache.org/jira/browse/CB-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Gill updated CB-6002:
---
Assignee: Archana Naik
create package validation doesn't match error report
Key: CB-6002
URL: https://issues.apache.org/jira/browse/CB-6002
Project: Apache Cordova
Issue Type: Bug
Components: Amazon FireOS
Affects Versions: 3.3.0
Reporter: Josh Soref
Assignee: Archana Naik
Priority: Minor
{quote}
{{exports.createProject = function(project_path, package_name, project_name,
project_template_dir, use_shared_project, use_cli_template) \{}}
...
{{if
(\!/\[a-zA-Z0-9_]+\.\[a-zA-Z0-9_](.\[a-zA-Z0-9_])*/.test(package_name)) \{}}
{{return Q.reject('Package name must look like: com.company.Name');}}
{{\}}}
...
{quote}
The code is checking for {{com.company}} but the error message suggests
{{com.company.Name}} -- If you want to test for {{com.company.Name}} then the
*{{\*}}* should be a *{{+}}*.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6366) Automate Downloading the Amazon WebView SDK from the Amazon Developer Portal.
Steve Gill created CB-6366: -- Summary: Automate Downloading the Amazon WebView SDK from the Amazon Developer Portal. Key: CB-6366 URL: https://issues.apache.org/jira/browse/CB-6366 Project: Apache Cordova Issue Type: Bug Components: Amazon FireOS Reporter: Steve Gill Assignee: Archana Naik It would be nice if this was an automated step instead of manual! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949808#comment-13949808
]
Ralph S Theart commented on CB-6359:
no it continues to fail with
{code}
window.resolveLocalFileSystemURL(file:///storage/extSdCard/DCIM/Camera/20140327_141754.mp4,function(){
//never gets here
},function(){
//continues to fail error
Error Coede: (5) Error Message: Unknown Error
});
{code}
anything I have to add in the cofig.xml file?
do I have to call window.resolveLocalFileSystemURL() another way?
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On Mac
Cordova info
Current Node Version
v0.10.25
Current Cordova CLI Version
3.4.0-0.1.0
Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
Reporter: Ralph S Theart
Assignee: Ian Clelland
Labels: android, capture
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I
already know its not something related to my set up or my code. Out of the
*10* devices one specific feature seems to fail on one specific device
(Galaxy Note 3). When you capture video and try to resolve the URI you will
always get error core 5 every single time no matter what changes you make or
conditions. Here is the code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed
the file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities. I'm more than happy to help with any testing...I built up a
rigorous excel sheet full of tests among which are all of the media type
api's. I did this because resolveLocalFileSystemURL has become a problem
child for me since 3.4 I have already submitted 3 bugs 1 of which was solved
and actually made it to the 1.0.1 File-System update. The 2nd one is solved
now too. I wouldn't care if the device this was happening to was old and was
on an older firmware like 4.0.3 but this is a popular device especially in
our database any help would be appreciated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph S Theart updated CB-6359:
---
Description:
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I already
know its not something related to my set up or my code. Out of the *10* devices
one specific feature seems to fail on one specific device (Galaxy Note 3). When
you capture video and try to resolve the URI you will always get error core 5
every single time no matter what changes you make or conditions. Here is the
code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed the
file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities? I have built up a rigorous excel sheet full of tests among which
are all of the media type api's. I did this because resolveLocalFileSystemURL
has become a problem child for me since 3.4 I have already submitted 3 bugs 1
of which was solved and actually made it to the 1.0.1 File-System update. The
2nd one is solved now too. I wouldn't care if the device this was happening to
was old and was on an older firmware like 4.0.3 but this is a popular device
especially in our database any help would be appreciated.
was:
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I already
know its not something related to my set up or my code. Out of the *10* devices
one specific feature seems to fail on one specific device (Galaxy Note 3). When
you capture video and try to resolve the URI you will always get error core 5
every single time no matter what changes you make or conditions. Here is the
code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed the
file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities. I'm more than happy to help with any testing...I built up a
rigorous excel sheet full of tests among which are all of the media type api's.
I did this because resolveLocalFileSystemURL has become a problem child for me
since 3.4 I have already submitted 3 bugs 1 of which was solved and actually
made it to the 1.0.1 File-System update. The 2nd one is solved now too. I
wouldn't care if the device this was happening to was old and was on an older
firmware like 4.0.3 but this is a popular device especially in our database any
help would be appreciated.
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On
[jira] [Commented] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949934#comment-13949934
]
Ralph S Theart commented on CB-6359:
also I am on current version=0.2.8 is this latest?...thanks again for your
help Ian.
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On Mac
Cordova info
Current Node Version
v0.10.25
Current Cordova CLI Version
3.4.0-0.1.0
Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
Reporter: Ralph S Theart
Assignee: Ian Clelland
Labels: android, capture
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I
already know its not something related to my set up or my code. Out of the
*10* devices one specific feature seems to fail on one specific device
(Galaxy Note 3). When you capture video and try to resolve the URI you will
always get error core 5 every single time no matter what changes you make or
conditions. Here is the code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed
the file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities? I have built up a rigorous excel sheet full of tests among
which are all of the media type api's. I did this because
resolveLocalFileSystemURL has become a problem child for me since 3.4 I have
already submitted 3 bugs 1 of which was solved and actually made it to the
1.0.1 File-System update. The 2nd one is solved now too. I wouldn't care if
the device this was happening to was old and was on an older firmware like
4.0.3 but this is a popular device especially in our database any help would
be appreciated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6338) Improve error for missing template
[
https://issues.apache.org/jira/browse/CB-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949986#comment-13949986
]
ASF subversion and git services commented on CB-6338:
-
Commit da34130e063da5d4e4c5ab96cb75d1e47e3a7581 in cordova-cli's branch
refs/heads/master from [~jsoref]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=da34130 ]
CB-6338 Improve error for missing template
Fix create test to properly lie about lib/dir
Improve error for missing template
--
Key: CB-6338
URL: https://issues.apache.org/jira/browse/CB-6338
Project: Apache Cordova
Issue Type: Bug
Components: CLI
Affects Versions: 3.4.0
Reporter: Josh Soref
Assignee: Josh Soref
Priority: Minor
Today when you try to create a project using a template whose path doesn't
exist (typically due to a typo), you get:
{quote}
cordova create /tmp/xxxq a a
'\{id:id,name:name,lib:\{www:\{uri:/tmp/xxqrtc,id:custom,version:0}}}'
Creating a new cordova project with name a and id a at location
/tmp/xxxq
Using custom www assets from /tmp/xxqrtc
cp: no such file or directory: /tmp/xxqrtc/*
{quote}
The * isn't really appropriate, what doesn't exist is the template directory,
not *.
{quote}
cordova create /tmp/xxxq a a
'\{id:id,name:name,lib:\{www:\{uri:/tmp/xxqrtc,id:custom,version:0}}}'
Creating a new cordova project with name a and id a at location
/tmp/xxxq
Using custom www assets from /tmp/xxqrtc
Could not find directory: /tmp/xxqrtc
{quote}
If people don't think this should be handled by cli, I can host the code
outside it, but...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6337) Print nice error when cordova-cli hits various expected things
[ https://issues.apache.org/jira/browse/CB-6337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949985#comment-13949985 ] ASF subversion and git services commented on CB-6337: - Commit 4f4dc29af98d8080507c0d6fe0015cec780fd701 in cordova-cli's branch refs/heads/master from [~jsoref] [ https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=4f4dc29 ] CB-6337 Print nice error when cordova-cli hits various expected things Add missing CordovaError requires Reduce specificity of jasmine toThrow() expectations Print nice error when cordova-cli hits various expected things -- Key: CB-6337 URL: https://issues.apache.org/jira/browse/CB-6337 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.4.0 Reporter: Josh Soref Assignee: Josh Soref CB-5782 introduced a way to silence stack traces for expected failures, but it missed some spots. This is a first pass against things in CLI itself -- it doesn't cover errors coming from plugman. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6357) platform check should install each platform to determine if they're functional and their version number
[ https://issues.apache.org/jira/browse/CB-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949995#comment-13949995 ] ASF subversion and git services commented on CB-6357: - Commit 4bc9e7017d61a5c3e02ba7a2d2037a5e4f21e38c in cordova-cli's branch refs/heads/master from [~jsoref] [ https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=4bc9e70 ] CB-6357 platform check - install each platform to determine working + version number platform check should install each platform to determine if they're functional and their version number --- Key: CB-6357 URL: https://issues.apache.org/jira/browse/CB-6357 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.5.0 Reporter: Josh Soref Assignee: Josh Soref Currently `cordova platform check` has a few behaviors which are not necessarily ideal: 1. It relies on the platforms.js file to have valid versions which match what is actually in the cached ~/.cordova/lib space. 2. If a platform is installed for which there's a newer version which won't install (e.g. you're on Windows and you have iOS installed), it could tell you that there's an upgrade available, however, you won't be able to install it. We'd like to fix these limitations by having platform check actually run the version script against a live project. This should mean that there will not be any false positives: what you see is what you really could get. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6357) platform check should install each platform to determine if they're functional and their version number
[ https://issues.apache.org/jira/browse/CB-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950002#comment-13950002 ] ASF GitHub Bot commented on CB-6357: Github user stevengill commented on the pull request: https://github.com/apache/cordova-cli/pull/153#issuecomment-38866049 I've merged this in. Hopefully this gets closed in a few minutes by asf script platform check should install each platform to determine if they're functional and their version number --- Key: CB-6357 URL: https://issues.apache.org/jira/browse/CB-6357 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.5.0 Reporter: Josh Soref Assignee: Josh Soref Currently `cordova platform check` has a few behaviors which are not necessarily ideal: 1. It relies on the platforms.js file to have valid versions which match what is actually in the cached ~/.cordova/lib space. 2. If a platform is installed for which there's a newer version which won't install (e.g. you're on Windows and you have iOS installed), it could tell you that there's an upgrade available, however, you won't be able to install it. We'd like to fix these limitations by having platform check actually run the version script against a live project. This should mean that there will not be any false positives: what you see is what you really could get. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6357) platform check should install each platform to determine if they're functional and their version number
[ https://issues.apache.org/jira/browse/CB-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949996#comment-13949996 ] ASF subversion and git services commented on CB-6357: - Commit 69856ced27c10a89c82392b3226e84976cfaf73f in cordova-cli's branch refs/heads/master from [~jsoref] [ https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=69856ce ] CB-6357 platform check: sort output platform check should install each platform to determine if they're functional and their version number --- Key: CB-6357 URL: https://issues.apache.org/jira/browse/CB-6357 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.5.0 Reporter: Josh Soref Assignee: Josh Soref Currently `cordova platform check` has a few behaviors which are not necessarily ideal: 1. It relies on the platforms.js file to have valid versions which match what is actually in the cached ~/.cordova/lib space. 2. If a platform is installed for which there's a newer version which won't install (e.g. you're on Windows and you have iOS installed), it could tell you that there's an upgrade available, however, you won't be able to install it. We'd like to fix these limitations by having platform check actually run the version script against a live project. This should mean that there will not be any false positives: what you see is what you really could get. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6357) platform check should install each platform to determine if they're functional and their version number
[ https://issues.apache.org/jira/browse/CB-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1394#comment-1394 ] ASF subversion and git services commented on CB-6357: - Commit 22e5826a3c780f2b6cfcd4dfc6cf624e1073a2be in cordova-cli's branch refs/heads/master from [~jsoref] [ https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=22e5826 ] CB-6357 minor style changes platform check should install each platform to determine if they're functional and their version number --- Key: CB-6357 URL: https://issues.apache.org/jira/browse/CB-6357 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.5.0 Reporter: Josh Soref Assignee: Josh Soref Currently `cordova platform check` has a few behaviors which are not necessarily ideal: 1. It relies on the platforms.js file to have valid versions which match what is actually in the cached ~/.cordova/lib space. 2. If a platform is installed for which there's a newer version which won't install (e.g. you're on Windows and you have iOS installed), it could tell you that there's an upgrade available, however, you won't be able to install it. We'd like to fix these limitations by having platform check actually run the version script against a live project. This should mean that there will not be any false positives: what you see is what you really could get. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6337) Print nice error when cordova-cli hits various expected things
[ https://issues.apache.org/jira/browse/CB-6337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1395#comment-1395 ] ASF GitHub Bot commented on CB-6337: Github user stevengill commented on the pull request: https://github.com/apache/cordova-cli/pull/150#issuecomment-38865992 Merged in. I believe this will automatically get closed soon Print nice error when cordova-cli hits various expected things -- Key: CB-6337 URL: https://issues.apache.org/jira/browse/CB-6337 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.4.0 Reporter: Josh Soref Assignee: Josh Soref CB-5782 introduced a way to silence stack traces for expected failures, but it missed some spots. This is a first pass against things in CLI itself -- it doesn't cover errors coming from plugman. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6357) platform check should install each platform to determine if they're functional and their version number
[ https://issues.apache.org/jira/browse/CB-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949998#comment-13949998 ] ASF subversion and git services commented on CB-6357: - Commit bdb34e6b9a430536e1b4777f271349175f890491 in cordova-cli's branch refs/heads/master from [~jsoref] [ https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=bdb34e6 ] CB-6357 platform: fix indentation platform check should install each platform to determine if they're functional and their version number --- Key: CB-6357 URL: https://issues.apache.org/jira/browse/CB-6357 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.5.0 Reporter: Josh Soref Assignee: Josh Soref Currently `cordova platform check` has a few behaviors which are not necessarily ideal: 1. It relies on the platforms.js file to have valid versions which match what is actually in the cached ~/.cordova/lib space. 2. If a platform is installed for which there's a newer version which won't install (e.g. you're on Windows and you have iOS installed), it could tell you that there's an upgrade available, however, you won't be able to install it. We'd like to fix these limitations by having platform check actually run the version script against a live project. This should mean that there will not be any false positives: what you see is what you really could get. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6357) platform check should install each platform to determine if they're functional and their version number
[ https://issues.apache.org/jira/browse/CB-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950008#comment-13950008 ] ASF GitHub Bot commented on CB-6357: Github user asfgit closed the pull request at: https://github.com/apache/cordova-cli/pull/153 platform check should install each platform to determine if they're functional and their version number --- Key: CB-6357 URL: https://issues.apache.org/jira/browse/CB-6357 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.5.0 Reporter: Josh Soref Assignee: Josh Soref Currently `cordova platform check` has a few behaviors which are not necessarily ideal: 1. It relies on the platforms.js file to have valid versions which match what is actually in the cached ~/.cordova/lib space. 2. If a platform is installed for which there's a newer version which won't install (e.g. you're on Windows and you have iOS installed), it could tell you that there's an upgrade available, however, you won't be able to install it. We'd like to fix these limitations by having platform check actually run the version script against a live project. This should mean that there will not be any false positives: what you see is what you really could get. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6337) Print nice error when cordova-cli hits various expected things
[ https://issues.apache.org/jira/browse/CB-6337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950009#comment-13950009 ] ASF GitHub Bot commented on CB-6337: Github user asfgit closed the pull request at: https://github.com/apache/cordova-cli/pull/150 Print nice error when cordova-cli hits various expected things -- Key: CB-6337 URL: https://issues.apache.org/jira/browse/CB-6337 Project: Apache Cordova Issue Type: Bug Components: CLI Affects Versions: 3.4.0 Reporter: Josh Soref Assignee: Josh Soref CB-5782 introduced a way to silence stack traces for expected failures, but it missed some spots. This is a first pass against things in CLI itself -- it doesn't cover errors coming from plugman. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6296) [CLI] dual interface in create function
[ https://issues.apache.org/jira/browse/CB-6296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950014#comment-13950014 ] ASF subversion and git services commented on CB-6296: - Commit 4d03b4970e771cac3d505a5a83166e5247a7d327 in cordova-cli's branch refs/heads/master from [~stevegill] [ https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=4d03b49 ] Revert [CB-6296] implemented tests for return interface of create function This reverts commit 79e571953c2d3459b459c02eb50e753308fd453d. [CLI] dual interface in create function --- Key: CB-6296 URL: https://issues.apache.org/jira/browse/CB-6296 Project: Apache Cordova Issue Type: Sub-task Components: CLI Reporter: Lorin Beer Assignee: Lorin Beer callback/promise interface in prepare.js. See top level issue for description. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-5455) Build Script crashes when using Amazon APIs
[ https://issues.apache.org/jira/browse/CB-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Gill updated CB-5455: --- Assignee: Archana Naik Build Script crashes when using Amazon APIs --- Key: CB-5455 URL: https://issues.apache.org/jira/browse/CB-5455 Project: Apache Cordova Issue Type: Bug Components: Amazon FireOS Reporter: Joe Bowser Assignee: Archana Naik See CB-5255, I ran into the same issue when testing FireOS. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-6245) Tools Release March 28, 2014
[ https://issues.apache.org/jira/browse/CB-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Gill updated CB-6245: --- Summary: Tools Release March 28, 2014 (was: Tools Release March 25, 2014) Tools Release March 28, 2014 Key: CB-6245 URL: https://issues.apache.org/jira/browse/CB-6245 Project: Apache Cordova Issue Type: Task Components: CLI, Plugman Reporter: Steve Gill Assignee: Steve Gill Following steps at https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6245) Tools Release March 28, 2014
[ https://issues.apache.org/jira/browse/CB-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950102#comment-13950102 ] Steve Gill commented on CB-6245: Both tools are passing now when running npm test. Cordova install and uninstall was tested for ios, android, blackberry10, amazon-fireos and firefoxos. No issues. Tools Release March 28, 2014 Key: CB-6245 URL: https://issues.apache.org/jira/browse/CB-6245 Project: Apache Cordova Issue Type: Task Components: CLI, Plugman Reporter: Steve Gill Assignee: Steve Gill Following steps at https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5520) Should we add DEBUG=1 to Preprocessor Macros-Debug ?
[
https://issues.apache.org/jira/browse/CB-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950127#comment-13950127
]
Shazron Abdullah commented on CB-5520:
--
Did some experimenting. If we want to extract settings to a .xcconfig file, the
corresponding setting in the Target must be removed. A Target setting overrides
all. This of course requires a new template, and ths removal may exclude
back-patching for previous Cordova versions by plugman.
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-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950253#comment-13950253 ] Cesidio DiBenedetto commented on CB-5294: - Hey all, I've been experiencing this issue as well so I wrote a Cordova FileChooser plugin to a band-aid for the time being. Basically, in Android 4.4(KitKat), as mentioned in previous comments, the file dialog is not opened. However the onclick event is still fired on input type=file so you can call the FileChooser plugin to open a file dialog and upon selection, you can set a variable that contains the full path to the file. At this point, you can use the FileTransfer plugin to upload to your server and hook into the onprogress event to show progress. This plugin is mainly configured for Android 4.4 so I would recommend to continue to use the native file dialogs for earlier versions of Android. There might be issues with the plugin as I have not fully tested all possible scenarios on many devices, but I have installed it on a Nexus 5 and it worked fine. https://github.com/cdibened/filechooser File input element not opening file picker in Android 4.4 - Key: CB-5294 URL: https://issues.apache.org/jira/browse/CB-5294 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.1.0 Environment: Android 4.4 (emulator and Nexus 5) Reporter: Paul Kane Assignee: Joe Bowser The file input field doesn't respond when clicked/tapped in Android 4.4. Works fine in previous Android versions. This is regardless of whether the Target Level is set to 18 or 19. To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only modification I made to the default (placeholder) index.html file was adding a form element with a single input type=file element inside. Clicking the Choose File button does nothing. No Logcat output or errors. Normally at this point a dialogue would open allowing me to select an image from the gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-6343) FileTransfer failed to upload image
[
https://issues.apache.org/jira/browse/CB-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
glmnbeyond updated CB-6343:
---
Component/s: iOS
FileTransfer failed to upload image
---
Key: CB-6343
URL: https://issues.apache.org/jira/browse/CB-6343
Project: Apache Cordova
Issue Type: Bug
Components: iOS, mobile-spec, Plugin Camera, Plugin File Transfer
Affects Versions: 3.3.0
Environment: org.apache.cordova.file-transfer version=0.4.3-dev
Reporter: glmnbeyond
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to Camera and Choose File
4) Click Upload Image
Results:
upload failed:
{code:1,source:{color:red}blob:file:///d5393bda-79b0-470c-8a1d-73e828c2f473{color},target:http://cordova-filetransfer.jitsu.com/upload,http_status:null,body:null}
Expected:
upload complete
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6343) FileTransfer failed to upload image
[
https://issues.apache.org/jira/browse/CB-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950260#comment-13950260
]
glmnbeyond commented on CB-6343:
Sorry, I forgot to mention it's in iOS.
FileTransfer failed to upload image
---
Key: CB-6343
URL: https://issues.apache.org/jira/browse/CB-6343
Project: Apache Cordova
Issue Type: Bug
Components: iOS, mobile-spec, Plugin Camera, Plugin File Transfer
Affects Versions: 3.3.0
Environment: org.apache.cordova.file-transfer version=0.4.3-dev
Reporter: glmnbeyond
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to Camera and Choose File
4) Click Upload Image
Results:
upload failed:
{code:1,source:{color:red}blob:file:///d5393bda-79b0-470c-8a1d-73e828c2f473{color},target:http://cordova-filetransfer.jitsu.com/upload,http_status:null,body:null}
Expected:
upload complete
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6343) FileTransfer failed to upload image
[
https://issues.apache.org/jira/browse/CB-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950264#comment-13950264
]
Ian Clelland commented on CB-6343:
--
It looks like a real (that is, webview-generated) blob URL; I suspect that the
problem would be that our native code can't actually read the contents.
I'll have to look into the interaction between camera and file to see when that
conversion to blob happens, and whether we can either stop it from happening,
or intercept it in the file-transfer JS and stream the contents back to
something that can cross the bridge, like a regular file.
FileTransfer failed to upload image
---
Key: CB-6343
URL: https://issues.apache.org/jira/browse/CB-6343
Project: Apache Cordova
Issue Type: Bug
Components: iOS, mobile-spec, Plugin Camera, Plugin File Transfer
Affects Versions: 3.3.0
Environment: org.apache.cordova.file-transfer version=0.4.3-dev
Reporter: glmnbeyond
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to Camera and Choose File
4) Click Upload Image
Results:
upload failed:
{code:1,source:{color:red}blob:file:///d5393bda-79b0-470c-8a1d-73e828c2f473{color},target:http://cordova-filetransfer.jitsu.com/upload,http_status:null,body:null}
Expected:
upload complete
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6359) resolveLocalFileSystemURL continues to be inconsistent, now fails specifically on Galaxy Note 3 when capturing video only
[
https://issues.apache.org/jira/browse/CB-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950269#comment-13950269
]
Ian Clelland commented on CB-6359:
--
0.2.8 is the latest released version of cordova-plugin-media-capture. File is
at 1.0.1 (but there are some fixes in the dev branch), and file-system-roots is
on 0.2.0-dev (the only published version)
Does your device have an SD card installed? That will (currently) affect the
location of temporary files; I'm wondering if that's the chief difference
between the Galaxy Note and your other 9 devices.
One other thing to try, if you still have file-system-roots installed, is to
put this into your config.xml file:
{code}
preference name=AndroidExtraFilesystems
value=files,files-external,documents,sdcard,cache,cache-external,root /
{code}
That will also cause it to install the root filesystem into your app, which
will let the File plugin access all of the files on the device (subject to
actual filesystem permissions, of course).
resolveLocalFileSystemURL continues to be inconsistent, now fails
specifically on Galaxy Note 3 when capturing video only
-
Key: CB-6359
URL: https://issues.apache.org/jira/browse/CB-6359
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin Media Capture
Affects Versions: 3.4.0
Environment: On Mac
Cordova info
Current Node Version
v0.10.25
Current Cordova CLI Version
3.4.0-0.1.0
Testing with: Samsung Galaxy Note 3 (Android)...the device is NOT rooted.
Reporter: Ralph S Theart
Assignee: Ian Clelland
Labels: android, capture
Ok this is a very strange bug. Some background first though. I have 10 test
devices at my house so I can test the apps I make. Of the 10 devices 8 are
android. My app works across the board on all of them flawlessly. So I
already know its not something related to my set up or my code. Out of the
*10* devices one specific feature seems to fail on one specific device
(Galaxy Note 3). When you capture video and try to resolve the URI you will
always get error core 5 every single time no matter what changes you make or
conditions. Here is the code.
{code}
navigator.device.capture.captureVideo(function(mediaFiles){
var mediaFilePath = mediaFiles[0].fullPath;
window.resolveLocalFileSystemURL(mediaFilePath, function(){
///never gets this far
}, function(error){
console.log(error.code);
*Always fails with error code 5*
});
}, function(error){
var msg = 'Messages captureVideo():: An error
occurred during video capture: ' + error.code;
console.log(msg, null, 'Uh oh!');
});
{code}
For this device and this specific scenario the path returned by capture is
always something like this:
*file:/storage/extSdCard/DCIM/Camera/20140327_104747.mp4* yes I noticed
the file:/ and have even tried replacing it with file:/// and it still
continues to fail.
btw ...I have a lot of devices I test with with...do you guys have these kind
of facilities? I have built up a rigorous excel sheet full of tests among
which are all of the media type api's. I did this because
resolveLocalFileSystemURL has become a problem child for me since 3.4 I have
already submitted 3 bugs 1 of which was solved and actually made it to the
1.0.1 File-System update. The 2nd one is solved now too. I wouldn't care if
the device this was happening to was old and was on an older firmware like
4.0.3 but this is a popular device especially in our database any help would
be appreciated.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6347) Camera-Copy Image failed !
[ https://issues.apache.org/jira/browse/CB-6347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950278#comment-13950278 ] glmnbeyond commented on CB-6347: Hi [~iclelland], I think your commit fixed this problem. After I patched CB-6352, the test can pass and there is no JSON error any more. Many thanks to your :) Camera-Copy Image failed ! - Key: CB-6347 URL: https://issues.apache.org/jira/browse/CB-6347 Project: Apache Cordova Issue Type: Bug Components: iOS, mobile-spec, Plugin Camera, Plugin File Affects Versions: 3.4.0 Environment: org.apache.cordova.camera version: 0.2.9-dev Reporter: glmnbeyond Assignee: Ian Clelland Steps to reproduce it: 1) Using createmobilespec.sh to create mobilespec project 2) Load mobile-spec tests 3) Navigate to Camera and getPicture() 4) Click Copy Image Results: Copy image succeeded, but no results got outputted! Expected: FileEntry.copyTo success! If I try catch the function log, there is an exception says TypeError: JSON.stringify cannot serialize cyclic structures -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CB-6347) Camera-Copy Image failed !
[ https://issues.apache.org/jira/browse/CB-6347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950278#comment-13950278 ] glmnbeyond edited comment on CB-6347 at 3/28/14 2:11 AM: - Hi [~iclelland], I think your commit fixed this problem. After I patched CB-6352, the test can pass and there is no JSON error any more. Many thanks to you :) was (Author: glmnbeyond): Hi [~iclelland], I think your commit fixed this problem. After I patched CB-6352, the test can pass and there is no JSON error any more. Many thanks to your :) Camera-Copy Image failed ! - Key: CB-6347 URL: https://issues.apache.org/jira/browse/CB-6347 Project: Apache Cordova Issue Type: Bug Components: iOS, mobile-spec, Plugin Camera, Plugin File Affects Versions: 3.4.0 Environment: org.apache.cordova.camera version: 0.2.9-dev Reporter: glmnbeyond Assignee: Ian Clelland Steps to reproduce it: 1) Using createmobilespec.sh to create mobilespec project 2) Load mobile-spec tests 3) Navigate to Camera and getPicture() 4) Click Copy Image Results: Copy image succeeded, but no results got outputted! Expected: FileEntry.copyTo success! If I try catch the function log, there is an exception says TypeError: JSON.stringify cannot serialize cyclic structures -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6367) Camera plugin failed to resize image to the specified target width and target height
glmnbeyond created CB-6367: -- Summary: Camera plugin failed to resize image to the specified target width and target height Key: CB-6367 URL: https://issues.apache.org/jira/browse/CB-6367 Project: Apache Cordova Issue Type: Bug Components: iOS, mobile-spec, Plugin Camera Affects Versions: 3.4.0 Environment: Cordova-ios 3.5.0-dev org.apache.cordova.camera 0.2.9-dev Device: iPod touch 5th iOS7.0.3 Reporter: glmnbeyond Steps to reproduce it: 1) Using createmobilespec.sh to create mobilespec project 2) Load mobile-spec tests 3) Navigate to Camera 4) Set targetWidth as 50 and target height as 200.Leave other options as default. 5) Click getPicture 6) Fetch the captured picture from device(mobilespec/tmp/cdv_photo_00x.jpg) Results: The dimensions of the captured image is 50x50 Expected: The dimensions of the captured image is 50x200 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-6347) Camera-Copy Image failed !
[ https://issues.apache.org/jira/browse/CB-6347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Clelland resolved CB-6347. -- Resolution: Fixed Great to hear -- thanks for testing that out again! Closing this issue. Camera-Copy Image failed ! - Key: CB-6347 URL: https://issues.apache.org/jira/browse/CB-6347 Project: Apache Cordova Issue Type: Bug Components: iOS, mobile-spec, Plugin Camera, Plugin File Affects Versions: 3.4.0 Environment: org.apache.cordova.camera version: 0.2.9-dev Reporter: glmnbeyond Assignee: Ian Clelland Steps to reproduce it: 1) Using createmobilespec.sh to create mobilespec project 2) Load mobile-spec tests 3) Navigate to Camera and getPicture() 4) Click Copy Image Results: Copy image succeeded, but no results got outputted! Expected: FileEntry.copyTo success! If I try catch the function log, there is an exception says TypeError: JSON.stringify cannot serialize cyclic structures -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6368) FileReader readAsBinaryString can't work in Android.
puchen created CB-6368: -- Summary: FileReader readAsBinaryString can't work in Android. Key: CB-6368 URL: https://issues.apache.org/jira/browse/CB-6368 Project: Apache Cordova Issue Type: Bug Components: Plugin File Affects Versions: 3.4.0 Environment: Android 4.0.4 Reporter: puchen Run spec test, at spec.86 of 'Run File Tests', got error message D/CordovaLog(7621): : Line 1 : Uncaught SyntaxError: Unexpected token ILLEGAL E/Web Console(7621): Uncaught SyntaxError: Unexpected token ILLEGAL at :1 Only Android 1.Can't get the success callback. When cordova called 'public PluginResult(Status status, byte[] data, boolean binaryString) ' method, the bytes encoded to string, and assigned to 'encodedMessage'. Then cordova sent the pluginResult, and called pluginResult.getMessage() in encodeAsJsMessage method.So the problem appeared, the callback result is the String type but can't be JSONObject.quote. Then cordova called callbackFromNative method in cordova.js, the 'callback.success.apply' worked error, the Cordova Log showed 'Uncaught SyntaxError: Unexpected token ILLEGAL'. The reason is 'readAsBinaryString' returned a binary string but can't be quoted, caused the js layer syntax error. 2.If we can get the success callback, but the result is not expected in spec.86, because 'Base64.encodeToString' can't return the correct result in PluginResult.java. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6369) InAppBrowser-CSS/JS Injection-openWithScript test failed!
glmnbeyond created CB-6369: -- Summary: InAppBrowser-CSS/JS Injection-openWithScript test failed! Key: CB-6369 URL: https://issues.apache.org/jira/browse/CB-6369 Project: Apache Cordova Issue Type: Bug Components: iOS, mobile-spec, Plugin InAppBrowser Affects Versions: 3.4.0 Environment: Cordova-ios 3.5.0-dev org.apache.cordova.inappbrowser 0.3.3-dev Reporter: glmnbeyond Steps to reproduce it: 1) Using createmobilespec.sh to create mobilespec project 2) Load mobile-spec tests 3) Navigate to In App Browser and CSS / JS Injection section 4) Test Script File Injection(callback) Script Literal Injection and Script Literal Injection(callback) Results: The actual test results don't match with the descriptions of expected test results. Expected: The actual test results match with the descriptions of expected test results. For example, the expected test result of Script Literal Injection (callback) should be open successfully in InAppBrowser with the text Script literal successfully injected and alert dialog with the text Results verified. instead of open successfully in InAppBrowser with text InAppBrowser - Script / Style Injection Test and alert dialog with the text Results verified. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-6369) InAppBrowser-CSS/JS Injection-openWithScript test failed!
[
https://issues.apache.org/jira/browse/CB-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
glmnbeyond updated CB-6369:
---
Description:
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to In App Browser and CSS / JS Injection section
4) Test Script File Injection(callback) Script Literal Injection and
Script Literal Injection(callback)
Results:
The actual test results don't match with the descriptions of expected test
results.
Expected:
The actual test results match with the descriptions of expected test results.
For example, the expected test result of Script Literal Injection (callback)
should be
open successfully in InAppBrowser with the text {color:read}Script literal
successfully injected{color} and alert dialog with the text Results
verified. instead of open successfully in InAppBrowser with text
{color:read}InAppBrowser - Script / Style Injection Test{color} and alert
dialog with the text Results verified.
was:
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to In App Browser and CSS / JS Injection section
4) Test Script File Injection(callback) Script Literal Injection and
Script Literal Injection(callback)
Results:
The actual test results don't match with the descriptions of expected test
results.
Expected:
The actual test results match with the descriptions of expected test results.
For example, the expected test result of Script Literal Injection (callback)
should be
open successfully in InAppBrowser with the text Script literal successfully
injected and alert dialog with the text Results verified. instead of open
successfully in InAppBrowser with text InAppBrowser - Script / Style Injection
Test and alert dialog with the text Results verified.
InAppBrowser-CSS/JS Injection-openWithScript test failed!
---
Key: CB-6369
URL: https://issues.apache.org/jira/browse/CB-6369
Project: Apache Cordova
Issue Type: Bug
Components: iOS, mobile-spec, Plugin InAppBrowser
Affects Versions: 3.4.0
Environment: Cordova-ios 3.5.0-dev
org.apache.cordova.inappbrowser 0.3.3-dev
Reporter: glmnbeyond
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to In App Browser and CSS / JS Injection section
4) Test Script File Injection(callback) Script Literal Injection and
Script Literal Injection(callback)
Results:
The actual test results don't match with the descriptions of expected test
results.
Expected:
The actual test results match with the descriptions of expected test results.
For example, the expected test result of Script Literal Injection
(callback) should be
open successfully in InAppBrowser with the text {color:read}Script literal
successfully injected{color} and alert dialog with the text Results
verified. instead of open successfully in InAppBrowser with text
{color:read}InAppBrowser - Script / Style Injection Test{color} and alert
dialog with the text Results verified.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CB-6369) InAppBrowser-CSS/JS Injection-openWithScript test failed!
[
https://issues.apache.org/jira/browse/CB-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
glmnbeyond updated CB-6369:
---
Description:
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to In App Browser and CSS / JS Injection section
4) Test Script File Injection(callback) Script Literal Injection and
Script Literal Injection(callback)
Results:
The actual test results don't match with the descriptions of expected test
results.
Expected:
The actual test results match with the descriptions of expected test results.
For example, the expected test result of Script Literal Injection (callback)
should be
open successfully in InAppBrowser with the text {color:green}Script literal
successfully injected{color} and alert dialog with the text Results
verified. instead of open successfully in InAppBrowser with text
{color:red}InAppBrowser - Script / Style Injection Test{color} and alert
dialog with the text Results verified.
was:
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to In App Browser and CSS / JS Injection section
4) Test Script File Injection(callback) Script Literal Injection and
Script Literal Injection(callback)
Results:
The actual test results don't match with the descriptions of expected test
results.
Expected:
The actual test results match with the descriptions of expected test results.
For example, the expected test result of Script Literal Injection (callback)
should be
open successfully in InAppBrowser with the text {color:read}Script literal
successfully injected{color} and alert dialog with the text Results
verified. instead of open successfully in InAppBrowser with text
{color:read}InAppBrowser - Script / Style Injection Test{color} and alert
dialog with the text Results verified.
InAppBrowser-CSS/JS Injection-openWithScript test failed!
---
Key: CB-6369
URL: https://issues.apache.org/jira/browse/CB-6369
Project: Apache Cordova
Issue Type: Bug
Components: iOS, mobile-spec, Plugin InAppBrowser
Affects Versions: 3.4.0
Environment: Cordova-ios 3.5.0-dev
org.apache.cordova.inappbrowser 0.3.3-dev
Reporter: glmnbeyond
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to In App Browser and CSS / JS Injection section
4) Test Script File Injection(callback) Script Literal Injection and
Script Literal Injection(callback)
Results:
The actual test results don't match with the descriptions of expected test
results.
Expected:
The actual test results match with the descriptions of expected test results.
For example, the expected test result of Script Literal Injection
(callback) should be
open successfully in InAppBrowser with the text {color:green}Script literal
successfully injected{color} and alert dialog with the text Results
verified. instead of open successfully in InAppBrowser with text
{color:red}InAppBrowser - Script / Style Injection Test{color} and alert
dialog with the text Results verified.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6369) InAppBrowser-CSS/JS Injection-openWithScript test failed!
[
https://issues.apache.org/jira/browse/CB-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950329#comment-13950329
]
ASF GitHub Bot commented on CB-6369:
GitHub user lmnbeyond opened a pull request:
https://github.com/apache/cordova-mobile-spec/pull/53
CB-6369:Update the descriptions of expected results for InAppBrowser ope...
...nWithScript tests.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/lmnbeyond/cordova-mobile-spec CB-6369
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cordova-mobile-spec/pull/53.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 #53
commit aebd633d5c8f68ce5f648734778df5a4dd11ba9b
Author: liumn li...@polyvi.com
Date: 2014-03-28T03:34:51Z
CB-6369:Update the descriptions of expected results for InAppBrowser
openWithScript tests.
InAppBrowser-CSS/JS Injection-openWithScript test failed!
---
Key: CB-6369
URL: https://issues.apache.org/jira/browse/CB-6369
Project: Apache Cordova
Issue Type: Bug
Components: iOS, mobile-spec, Plugin InAppBrowser
Affects Versions: 3.4.0
Environment: Cordova-ios 3.5.0-dev
org.apache.cordova.inappbrowser 0.3.3-dev
Reporter: glmnbeyond
Steps to reproduce it:
1) Using createmobilespec.sh to create mobilespec project
2) Load mobile-spec tests
3) Navigate to In App Browser and CSS / JS Injection section
4) Test Script File Injection(callback) Script Literal Injection and
Script Literal Injection(callback)
Results:
The actual test results don't match with the descriptions of expected test
results.
Expected:
The actual test results match with the descriptions of expected test results.
For example, the expected test result of Script Literal Injection
(callback) should be
open successfully in InAppBrowser with the text {color:green}Script literal
successfully injected{color} and alert dialog with the text Results
verified. instead of open successfully in InAppBrowser with text
{color:red}InAppBrowser - Script / Style Injection Test{color} and alert
dialog with the text Results verified.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
