[jira] [Commented] (CB-2293) File Transfer of picture fails on every other picture
[
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571369#comment-13571369
]
Andrew Grieve commented on CB-2293:
---
According to this post:
http://android-developers.blogspot.ca/2011/09/androids-http-clients.html
This bug is supposed to be fixed in Android 2.2. I guess some vendor versions
still have the bug though :(.
One solution is to switch to HttpClient, another is to figure out which phones
to disable connection: keep-alive for. Or maybe the problem is that we're
explicitly setting the keep-alive header in FileTransfer.
Amrit, are you able to play around and see if just removing the explicit
setting of the header works? Or maybe removing our call to InputStream.close()?
File Transfer of picture fails on every other picture
-
Key: CB-2293
URL: https://issues.apache.org/jira/browse/CB-2293
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.2.0, 2.3.0
Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as
a Samsung Galaxy S3(Android 4.1.1)
Reporter: Amrit Kahlon
Assignee: Andrew Grieve
Attachments: cordova-2.4.0rc1.jar
When uploading pictures using the File Transfer function on android, the
first picture will upload fine. Then the second upload will give the
following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from
connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
{target:http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2api_key=xsource=androidapp-2.2.1,source:file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392,code:3}
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto
failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by:
libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at
[jira] [Resolved] (CB-1701) FileTransfer response UTF-8 Bug
[
https://issues.apache.org/jira/browse/CB-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Grieve resolved CB-1701.
---
Resolution: Fixed
Assuming this is fixed. Please re-open if problem still occurs on Cordova 2.2
or greater
FileTransfer response UTF-8 Bug
Key: CB-1701
URL: https://issues.apache.org/jira/browse/CB-1701
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.1.0
Environment: Android, Eclipse
Reporter: Paul Poirel
Assignee: Andrew Grieve
Priority: Minor
I am using the FileTransfer API to upload a picture to a .ashx service (.NET).
Everything is fine, except that the response (FileUploadResult.response) is
not correctly encoded. It appears like a UTF8 string encoded as ISO.
Here are the logs from Eclipse debug console (LogCat) :
10-23 00:21:39.580: D/FileTransfer(24513): upload
file:///mnt/sdcard/AgoraStockPictures/740aze1350954367223.jpg to
http://*/upload-photo.ashx
10-23 00:21:39.580: D/FileTransfer(24513): fileKey: fileData
10-23 00:21:39.580: D/FileTransfer(24513): fileName: 740aze1350954367223.jpg
10-23 00:21:39.580: D/FileTransfer(24513): mimeType: image/jpeg
10-23 00:21:39.580: D/FileTransfer(24513): params:
{lastPicture:true,idproduit:teststock2224388212,token:9876543,login:teststock}
10-23 00:21:39.580: D/FileTransfer(24513): trustEveryone: false
10-23 00:21:39.580: D/FileTransfer(24513): chunkedMode: true
10-23 00:21:39.580: D/FileTransfer(24513): headers: null
10-23 00:21:39.580: D/FileTransfer(24513): String Length: 424
10-23 00:21:39.580: D/FileTransfer(24513): Content Length: 91341
10-23 00:21:40.910: D/FileTransfer(24513): got response from server
10-23 00:21:40.910: D/FileTransfer(24513):
[{data:{},errors:{etat:-93,libelle:L\u0027image existe déjà .}}]
10-23 00:21:40.910: D/FileTransfer(24513): ** About to return a result
from upload
And the result (in an alert or in console.log) is :
{etat:-93,libelle:L'image existe déjà .}
The expected result is : {etat:-93,libelle:L'image existe déjà .}
When I test the server whith a html form on chrome, I get the correct result.
Plus, the result looks like UTF8 displayed as ISO, so I believe that the
server is sending the UTF8 encoded response, and that it is a client-side
issue.
Here are the HTTP headers from the response :
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 197
Content-Type: text/plain; charset=UTF-8
Content-Encoding: gzip
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
Accepts-Encoding: gzip
Access-Control-Allow-Origin: *
X-Powered-By: ASP.NET
Date: Tue, 23 Oct 2012 10:28:33 GMT
Note : this might be related to the issue #CB-920, which was about the POST
params encoding.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files
[ https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571437#comment-13571437 ] Andrew Grieve commented on CB-285: -- I like the idea of switching PERSISTENT to be internal-only. The W3C spec intends this area to be sandboxed to the app, so shouldn't be on the sdcard. I think we need more than just an APP constant though, as there are many places where an app might want to put things. For iOS, You'd minimally want: 1. Application bundle, 2. Application_Home The other locations are all subdirectories of Application_Home, so not a big deal if we don't have constants for them For Android, You'd minimally want: 1. Assets directory (seems like a parallel to iOS Application Bundle) 2. Application data on internal storage (/data/data/$PACKAGE_NAME/files) 3. Application cache on internal storage (/data/data/$PACKAGE_NAME/cache) 4. External root: (/sdcard) We could maybe combine #2 and #3 into a single one that gave you /data/data/$PACKAGE_NAME, and document that Android wants files in the files and cache directories. The Ideal iOS constants: 1. PERSISTENT changes from Application_Home/Documents -- Application_Home/Library/CdvPersistentStorage 2. TEMPORARY changes from Application_Home/tmp -- Application_Home/tmp/CdvTemporaryStorage 3. APP_ASSETS -- Application bundle 4. APP_DATA -- Application_Home The main reason for changing #1 is that iCloud treats Documents directory specially The main reason for adding subdirs under Library/tmp is that it keeps the storage areas separate from the rest of the app (apps that have native components won't interfere with the webview's storage area). The ideal Android constants: 1. PERSISTENT -- /data/data/$PACKAGE_NAME/files/CdvPersistentStorage 2. TEMPORARY -- /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage 3. APP_ASSETS -- assets directory 4. APP_DATA -- /data/data/$PACKAGE_NAME 5. EXTERNAL_APP_DATA -- /sdcard/Android/data/$PACKAGE_NAME 6. EXTERNAL_ROOT -- /sdcard I even think there would be merit in adding more constants (e.g. DOCUMENTS, android resources) going forward, but one step at a time... == Transitioning to these new constants == TEMPORARY: Use the new path right away. No need to transition since the files there are temporary anyways. PERSISTENT (iOS): - If new location directory exists, use that. - Else, if any files exist in the legacy location, use the legacy location - Else, use the new path. PERSISTENT (Android): - PERSISTENT is currently /sdcard, so files will always exist :( In both cases, add a PERSISTENT_NEW constant to allow them to move their files over. In Cordova 3.0, change PERSISTENT to be PERSISTENT_NEW, and add PERSISTENT_LEGACY (in case apps have still not switched). Side issue: The spec says PERSISTENT and TEMPORARY are constants on the window object (ugh). So far though, Cordova has exposed them not as globals, but instead as LocalFileSystem.PERSISTENT and LocalFileSystem.TEMPORARY. I like the idea of exposing them on LocalFileSystem, but we should also put PERSISTENT and TEMPORARY on the window. Add property returning root path of PhoneGap files -- Key: CB-285 URL: https://issues.apache.org/jira/browse/CB-285 Project: Apache Cordova Issue Type: Improvement Components: CordovaJS Affects Versions: 1.4.0 Environment: Both PhoneGap SDK and PhoneGap Build Reporter: Ashley Gullen Assignee: Andrew Grieve Labels: features There needs to be a property in PhoneGap that returns the root path to the general files added to the PhoneGap project (i.e. the directory index.html is in). For example, if I add 'music.mp3' to my project, in Android it will be located in: /android_asset/www/music.mp3 On iOS after being built with PhoneGap Build it will be located in some path like this: /var/mobile/Applications/app_ID/name.app/www/music.mp3 However, there does not appear to be a programmatic way to determine both app_ID and name.app. This has two side effects: 1. Paths to audio for Media must be hard-coded separately depending on the platform, which is inconvenient. 2. Paths to audio for Media cannot be known if developing a framework that uses PhoneGap. Since a framework does not know the App ID or name in advance, it's impossible for the framework to determine the correct path. This is actively blocking audio from working on iOS in PhoneGap projects exported by Construct 2 (www.scirra.com), a HTML5 game creator. Also, it seems like kind of an important function to make available anyway, since hard-coding paths for each platform is a pain. This PhoneGap Support thread led to this issue:
[jira] [Comment Edited] (CB-285) Add property returning root path of PhoneGap files
[ https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571437#comment-13571437 ] Andrew Grieve edited comment on CB-285 at 2/5/13 4:54 PM: -- I like the idea of switching PERSISTENT to be internal-only. The W3C spec intends this area to be sandboxed to the app, so shouldn't be on the sdcard. I think we need more than just an APP constant though, as there are many places where an app might want to put things. For iOS, You'd minimally want: 1. Application bundle, 2. Application_Home The other locations are all subdirectories of Application_Home, so not a big deal if we don't have constants for them For Android, You'd minimally want: 1. Assets directory (seems like a parallel to iOS Application Bundle) 2. Application data on internal storage (/data/data/$PACKAGE_NAME/files) 3. Application cache on internal storage (/data/data/$PACKAGE_NAME/cache) 4. External root: (/sdcard) We could maybe combine #2 and #3 into a single one that gave you /data/data/$PACKAGE_NAME, and document that Android wants files in the files and cache directories. The Ideal iOS constants: 1. PERSISTENT changes from Application_Home/Documents -- Application_Home/Library/CdvPersistentStorage 2. TEMPORARY changes from Application_Home/tmp -- Application_Home/tmp/CdvTemporaryStorage 3. APP_ASSETS -- Application bundle 4. APP_DATA -- Application_Home The main reason for changing #1 is that iCloud treats Documents directory specially The main reason for adding subdirs under Library/tmp is that it keeps the storage areas separate from the rest of the app (apps that have native components won't interfere with the webview's storage area). The ideal Android constants: 1. PERSISTENT -- /data/data/$PACKAGE_NAME/files/CdvPersistentStorage 2. TEMPORARY -- /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage 3. APP_ASSETS -- assets directory 4. APP_DATA -- /data/data/$PACKAGE_NAME 5. EXTERNAL_APP_DATA -- /sdcard/Android/data/$PACKAGE_NAME 6. EXTERNAL_ROOT -- /sdcard I even think there would be merit in adding more constants (e.g. DOCUMENTS, android resources) going forward, but one step at a time... == Transitioning to these new constants == TEMPORARY: Use the new path right away. No need to transition since the files there are temporary anyways. PERSISTENT (iOS): - If new location directory exists, use that. - Else, if any files exist in the legacy location, use the legacy location - Else, use the new path. PERSISTENT (Android): - PERSISTENT is currently /sdcard, so files will always exist :( - Is there a way to detect new installs so that we can switch over for new installs at least? In both cases, add a PERSISTENT_NEW constant to allow them to move their files over. In Cordova 3.0, change PERSISTENT to be PERSISTENT_NEW, and add PERSISTENT_LEGACY (in case apps have still not switched). Side issue: The spec says PERSISTENT and TEMPORARY are constants on the window object (ugh). So far though, Cordova has exposed them not as globals, but instead as LocalFileSystem.PERSISTENT and LocalFileSystem.TEMPORARY. I like the idea of exposing them on LocalFileSystem, but we should also put PERSISTENT and TEMPORARY on the window. was (Author: agrieve): I like the idea of switching PERSISTENT to be internal-only. The W3C spec intends this area to be sandboxed to the app, so shouldn't be on the sdcard. I think we need more than just an APP constant though, as there are many places where an app might want to put things. For iOS, You'd minimally want: 1. Application bundle, 2. Application_Home The other locations are all subdirectories of Application_Home, so not a big deal if we don't have constants for them For Android, You'd minimally want: 1. Assets directory (seems like a parallel to iOS Application Bundle) 2. Application data on internal storage (/data/data/$PACKAGE_NAME/files) 3. Application cache on internal storage (/data/data/$PACKAGE_NAME/cache) 4. External root: (/sdcard) We could maybe combine #2 and #3 into a single one that gave you /data/data/$PACKAGE_NAME, and document that Android wants files in the files and cache directories. The Ideal iOS constants: 1. PERSISTENT changes from Application_Home/Documents -- Application_Home/Library/CdvPersistentStorage 2. TEMPORARY changes from Application_Home/tmp -- Application_Home/tmp/CdvTemporaryStorage 3. APP_ASSETS -- Application bundle 4. APP_DATA -- Application_Home The main reason for changing #1 is that iCloud treats Documents directory specially The main reason for adding subdirs under Library/tmp is that it keeps the storage areas separate from the rest of the app (apps that have native components won't interfere with the webview's storage area). The ideal Android constants: 1. PERSISTENT -- /data/data/$PACKAGE_NAME/files/CdvPersistentStorage
[jira] [Commented] (CB-2226) FileTransfer.abort -- successfully aborting actually calls the error callback. Nothing ever gets called for the success callback.
[ https://issues.apache.org/jira/browse/CB-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571567#comment-13571567 ] Andrew Grieve commented on CB-2226: --- Android's the same story I think. FileTransfer.abort -- successfully aborting actually calls the error callback. Nothing ever gets called for the success callback. - Key: CB-2226 URL: https://issues.apache.org/jira/browse/CB-2226 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Shazron Abdullah Assignee: Shazron Abdullah Priority: Minor Fix For: 2.5.0 See: https://github.com/apache/cordova-ios/blob/adf226876d03723b89b4e3a9d2e9d0cfa8f2eb07/CordovaLib/Classes/CDVFileTransfer.m#L315 The mobile spec tests only calls abort with no parameters, thus this problem was never detected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2293) File Transfer of picture fails on every other picture
[
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571755#comment-13571755
]
Andrew Grieve commented on CB-2293:
---
Great! Thanks for the investigation Amrit!
Found another possibly-related SO question:
http://stackoverflow.com/questions/12319194/android-httpurlconnection-throwing-eofexception
Right at the bottom they suggest that maybe toggling useChunkedMode will have
an effect.
Another thing from the previous SO question suggested removing the .close()
calls when reading the response, or removing the conn.disconnect() call right
at the end of the method.
Are you able to see if these help?
File Transfer of picture fails on every other picture
-
Key: CB-2293
URL: https://issues.apache.org/jira/browse/CB-2293
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.2.0, 2.3.0
Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as
a Samsung Galaxy S3(Android 4.1.1)
Reporter: Amrit Kahlon
Assignee: Andrew Grieve
Attachments: cordova-2.4.0rc1.jar
When uploading pictures using the File Transfer function on android, the
first picture will upload fine. Then the second upload will give the
following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from
connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
{target:http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2api_key=xsource=androidapp-2.2.1,source:file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392,code:3}
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto
failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by:
libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendto(Posix.java:146)
01-21 13:48:02.555: E/FileTransfer(8894): at
[jira] [Commented] (CB-2227) Move mapping of module-symbol into individual plugins
[
https://issues.apache.org/jira/browse/CB-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13572095#comment-13572095
]
Andrew Grieve commented on CB-2227:
---
Nope, the majority of the changes are still in the symbolmapping branch. I'll
merge close this once 2.4 is out.
Move mapping of module-symbol into individual plugins
--
Key: CB-2227
URL: https://issues.apache.org/jira/browse/CB-2227
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.4.0
Goals:
- Change from listing module-symbol mapping within common.js platform.js,
to listing this within the plugins themselves.
- Support apps that don't want us to clobber global symbols.
aka, allow module-symbol mapping to be turned off
- Allow retrieval of clobbered globals
- Currently modules save it themselves when they are loaded
- This won't work (reliably) for saving references to globals overridden by
other modules
- This gets in the way of the idea of lazy-loading modules via getters
- Support the use of other module loaders
- So... don't do crazy things at require() time.
Requirements:
Plugins must be able to declare dependencies
Plugins must be able to delay onDeviceReady()
Plugins must be able to run code to initialize
Implementation
modulemapper.js:
clobbers(...)
merges(...)
defaults(...)
mapModules(wnd)
getOriginalSymbol('FileSystem')
Start-up flow:
Parse all modules
common-bootstrap:
Loads list of modules named cordova.*/symbols
Run modulemapper.mapModules(window);
Loads list of modules named cordova.*/main
symbols.js files:
Will make calls to modulemapper instead of exporting {clobbers:}
This make dependencies work by require()ing dependent symbols
We want the to be an evaluated .js file instead of something listed in
plugin.xml
So that it can export based on browser version
Implementation Steps
1. - Expose list of registered modules in scripts/require.js so that we can
loop over them
2. - Write modulemapper.js (and have unit tests, of course)
3. - Add logic to bootstrap.js that calls into modulemapper
create $PLUGIN_NAME/symbols.js files for each plugin within cordova.
4. - Add logic to bootstrap.js that calls into modulemapper
5. - Create main.js files for those that currently have logic in their
platform.js files
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files
[
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13572179#comment-13572179
]
Andrew Grieve commented on CB-285:
--
Yes. Definitely want to allow users to chose make the decision of where their
files go. Android has no iCloud equivalent, but instead has a shared
file-system for things like music photos.
So, here's another proposal: Instead of adding non-standard constants to
requestFileSystem(), we add a new (non-standard) API:
LocalFileSystem.getAppDirectory(callback)
// gets a (read-only) DirectoryEntry for the www directory.
LocalFileSystem.getDirectoryForPurpose({
sandboxed: true || false,
persistence: 'temporary' || 'cache' || 'device_persistent' || 'persistent',
category: 'data' || 'documents'
}, success);
sandboxed: will be ignored for iOS. For Android it will toggle between external
an internal storage.
- Defaults to true.
- If non-sandboxed is unavailable (iOS), fall-back to true.
persistence:
- on Android, 'temporary' == 'cache', but on iOS they are different.
- on Android, 'device_persistent' == 'persistent', but on iOS one has iCloud
enabled and the other does not.
category:
- Defaults to 'data'
- persistence == 'temporary' or 'cache' == this value is ignored.
- Android sandboxed == true == files/ directory
- 'data' iOS persistence == 'persistent' == Application_Home/Library
- 'data' iOS persistence == 'device_persistent' ==
Application_Home/Library/NoCloud (and we set the extended attr on this
directory to make it unsynced.
- 'data' Android == files/ subdirectory of app storage (based on sandboxed
value)
- 'documents' iOS persistence == 'persistent' ==
Application_Home/Documents
- 'documents' iOS persistence == 'device_persistent' ==
Application_Home/Documents/NoCloud
- 'documents' Android == /sdcard
Add property returning root path of PhoneGap files
--
Key: CB-285
URL: https://issues.apache.org/jira/browse/CB-285
Project: Apache Cordova
Issue Type: Improvement
Components: CordovaJS
Affects Versions: 1.4.0
Environment: Both PhoneGap SDK and PhoneGap Build
Reporter: Ashley Gullen
Assignee: Andrew Grieve
Labels: features
There needs to be a property in PhoneGap that returns the root path to the
general files added to the PhoneGap project (i.e. the directory index.html is
in). For example, if I add 'music.mp3' to my project, in Android it will be
located in:
/android_asset/www/music.mp3
On iOS after being built with PhoneGap Build it will be located in some path
like this:
/var/mobile/Applications/app_ID/name.app/www/music.mp3
However, there does not appear to be a programmatic way to determine both
app_ID and name.app.
This has two side effects:
1. Paths to audio for Media must be hard-coded separately depending on the
platform, which is inconvenient.
2. Paths to audio for Media cannot be known if developing a framework that
uses PhoneGap. Since a framework does not know the App ID or name in
advance, it's impossible for the framework to determine the correct path.
This is actively blocking audio from working on iOS in PhoneGap projects
exported by Construct 2 (www.scirra.com), a HTML5 game creator. Also, it
seems like kind of an important function to make available anyway, since
hard-coding paths for each platform is a pain.
This PhoneGap Support thread led to this issue:
http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2214) Refactor JS files to be more ready to move into their own repositories
[ https://issues.apache.org/jira/browse/CB-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570653#comment-13570653 ] Andrew Grieve commented on CB-2214: --- Proposal via google docs: https://docs.google.com/document/d/1Evzu8qliwxBWGj9-U8ea1rvrbd-jokmN4Dti8AGAXdU/edit# Refactor JS files to be more ready to move into their own repositories -- Key: CB-2214 URL: https://issues.apache.org/jira/browse/CB-2214 Project: Apache Cordova Issue Type: Bug Components: CordovaJS Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.4.0 Refer to ML discussion: http://callback.markmail.org/thread/xnhpidbnxg5ps7zr This task is specifically to move files around. Instead of having : lib/$PLATFORM/plugin We will have: plugin/PLUGIN_NAME/PLATFORM Changing of common.js / platform.js is *not* a part of this issue, but instead will be a follow-up (requires more thought) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2293) File Transfer of picture fails on every other picture
[
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570799#comment-13570799
]
Andrew Grieve commented on CB-2293:
---
Just tried making my own sample app that does camera uploads, and I'm able to
upload multiple images just fine. Ran it on the 4.0.3 emulator. Do you know if
this bug repros on any of the emulators?
File Transfer of picture fails on every other picture
-
Key: CB-2293
URL: https://issues.apache.org/jira/browse/CB-2293
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.2.0, 2.3.0
Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as
a Samsung Galaxy S3(Android 4.1.1)
Reporter: Amrit Kahlon
Assignee: Andrew Grieve
Attachments: cordova-2.4.0rc1.jar
When uploading pictures using the File Transfer function on android, the
first picture will upload fine. Then the second upload will give the
following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from
connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
{target:http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2api_key=xsource=androidapp-2.2.1,source:file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392,code:3}
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto
failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by:
libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendto(Posix.java:146)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:473)
01-21 13:48:02.555: E/FileTransfer(8894): ... 9 more
01-21 13:48:02.575: D/CordovaLog(8894): error:
[jira] [Commented] (CB-2293) File Transfer of picture fails on every other picture
[
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13570864#comment-13570864
]
Andrew Grieve commented on CB-2293:
---
I don't have either of those phones to test with :(.
Another stab-in-the-dark is that it's this bug:
http://stackoverflow.com/questions/3352424/httpurlconnection-openconnection-fails-second-time
You could try adding System.setProperty(http.keepAlive, false); to your
start-up somewhere, and also delete the:
conn.setRequestProperty(Connection, Keep-Alive);
line from FileTransfer.java
File Transfer of picture fails on every other picture
-
Key: CB-2293
URL: https://issues.apache.org/jira/browse/CB-2293
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.2.0, 2.3.0
Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as
a Samsung Galaxy S3(Android 4.1.1)
Reporter: Amrit Kahlon
Assignee: Andrew Grieve
Attachments: cordova-2.4.0rc1.jar
When uploading pictures using the File Transfer function on android, the
first picture will upload fine. Then the second upload will give the
following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from
connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
{target:http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2api_key=xsource=androidapp-2.2.1,source:file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392,code:3}
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto
failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by:
libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendto(Posix.java:146)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
01-21 13:48:02.555: E/FileTransfer(8894): at
[jira] [Resolved] (CB-2285) No more activities from Cordova
[ https://issues.apache.org/jira/browse/CB-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-2285. --- Resolution: Not A Problem Hmm, so from your description, you were doing a page navigation at the same time as launching the InAppBrowser. Probably this use-case is not worth fixing, as I don't think it would ever make sense. No more activities from Cordova --- Key: CB-2285 URL: https://issues.apache.org/jira/browse/CB-2285 Project: Apache Cordova Issue Type: Bug Components: iOS, Mac Affects Versions: 2.3.0, 2.4.0 Environment: OSX - iOS 6 tested Reporter: fabian boulegue Assignee: Andrew Grieve Labels: inAppBrowser, notification I use it for iOS (6), i builded a app with inAppBrowser as well then some Notifications. From time to time, if i switched the pages and used some of the Browser and Notifications it comes to a point where no more activities by Cordova can be handle. If i then click on the Notification button nothing happens (also no console output) anyone a idea whats wrong (normally on first try all of the functions work great.) If i should submit any more informations please ask for would be great to have a fix for that -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-2276) Refactor to eliminate casts of viewControlled - CDVViewController
[ https://issues.apache.org/jira/browse/CB-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve updated CB-2276: -- Fix Version/s: (was: 2.4.0) 2.5.0 Refactor to eliminate casts of viewControlled - CDVViewController -- Key: CB-2276 URL: https://issues.apache.org/jira/browse/CB-2276 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.5.0 Any functionality needed by plugins from the CDVViewController should be exposed through CDVCommandDelegate. This will make it more clear which symbols will not change, and which are meant to be private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1793) Fix Objective-C unit tests
[ https://issues.apache.org/jira/browse/CB-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-1793. --- Resolution: Cannot Reproduce I ran these recently and only the Contact ones failed (they are TODO:implement me tests) Fix Objective-C unit tests -- Key: CB-1793 URL: https://issues.apache.org/jira/browse/CB-1793 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.2.0 Reporter: Shazron Abdullah Assignee: Shazron Abdullah Fix For: 2.4.0 2 suites failed (CDVLocalStorage, FileTransfer). ContactTests failures are expected. 4 CDVLocalStorageTests failed: Test Suite 'CDVLocalStorageTests' started at 2012-10-31 22:37:53 + Test Case '-[CDVLocalStorageTests testBackupAndRestore]' started. 2012-10-31 15:37:53.833 CordovaLibApp[17467:c07] Multi-tasking - Device: YES, App: YES 2012-10-31 15:37:53.837 CordovaLibApp[17467:c07] Deprecated: BackupWebStorage boolean property is a string property now (none, local, cloud). A boolean value of 'true' will be mapped to 'cloud'. Consult the docs: http://docs.cordova.io/en/edge/guide_project-settings_ios_index.md.html#Project%20Settings%20for%20iOS 2012-10-31 15:37:53.992 CordovaLibApp[17467:c07] -[__NSCFBoolean isEqualToString:]: unrecognized selector sent to instance 0x288a95c Unknown.m:0: error: -[CDVLocalStorageTests testBackupAndRestore] : -[__NSCFBoolean isEqualToString:]: unrecognized selector sent to instance 0x288a95c Test Case '-[CDVLocalStorageTests testBackupAndRestore]' failed (0.164 seconds). Test Case '-[CDVLocalStorageTests testVerifyAndFixDatabaseLocations_changeRequired1]' started. 2012-10-31 15:37:53.995 CordovaLibApp[17467:c07] Multi-tasking - Device: YES, App: YES 2012-10-31 15:37:53.996 CordovaLibApp[17467:c07] Deprecated: BackupWebStorage boolean property is a string property now (none, local, cloud). A boolean value of 'true' will be mapped to 'cloud'. Consult the docs: http://docs.cordova.io/en/edge/guide_project-settings_ios_index.md.html#Project%20Settings%20for%20iOS 2012-10-31 15:37:53.999 CordovaLibApp[17467:c07] -[__NSCFBoolean isEqualToString:]: unrecognized selector sent to instance 0x288a95c Unknown.m:0: error: -[CDVLocalStorageTests testVerifyAndFixDatabaseLocations_changeRequired1] : -[__NSCFBoolean isEqualToString:]: unrecognized selector sent to instance 0x288a95c Test Case '-[CDVLocalStorageTests testVerifyAndFixDatabaseLocations_changeRequired1]' failed (0.017 seconds). Test Case '-[CDVLocalStorageTests testVerifyAndFixDatabaseLocations_changeRequired2]' started. 2012-10-31 15:37:54.012 CordovaLibApp[17467:c07] Multi-tasking - Device: YES, App: YES 2012-10-31 15:37:54.015 CordovaLibApp[17467:c07] Deprecated: BackupWebStorage boolean property is a string property now (none, local, cloud). A boolean value of 'true' will be mapped to 'cloud'. Consult the docs: http://docs.cordova.io/en/edge/guide_project-settings_ios_index.md.html#Project%20Settings%20for%20iOS 2012-10-31 15:37:54.018 CordovaLibApp[17467:c07] -[__NSCFBoolean isEqualToString:]: unrecognized selector sent to instance 0x288a95c Unknown.m:0: error: -[CDVLocalStorageTests testVerifyAndFixDatabaseLocations_changeRequired2] : -[__NSCFBoolean isEqualToString:]: unrecognized selector sent to instance 0x288a95c Test Case '-[CDVLocalStorageTests testVerifyAndFixDatabaseLocations_changeRequired2]' failed (0.007 seconds). Test Case '-[CDVLocalStorageTests testVerifyAndFixDatabaseLocations_noChangeRequired]' started. 2012-10-31 15:37:54.033 CordovaLibApp[17467:c07] Multi-tasking - Device: YES, App: YES 2012-10-31 15:37:54.034 CordovaLibApp[17467:c07] Deprecated: BackupWebStorage boolean property is a string property now (none, local, cloud). A boolean value of 'true' will be mapped to 'cloud'. Consult the docs: http://docs.cordova.io/en/edge/guide_project-settings_ios_index.md.html#Project%20Settings%20for%20iOS 2012-10-31 15:37:54.037 CordovaLibApp[17467:c07] -[__NSCFBoolean isEqualToString:]: unrecognized selector sent to instance 0x288a95c Unknown.m:0: error: -[CDVLocalStorageTests testVerifyAndFixDatabaseLocations_noChangeRequired] : -[__NSCFBoolean isEqualToString:]: unrecognized selector sent to instance 0x288a95c Test Case '-[CDVLocalStorageTests testVerifyAndFixDatabaseLocations_noChangeRequired]' failed (0.005 seconds). Test Suite 'CDVLocalStorageTests' finished at 2012-10-31 22:37:54 +. Executed 4 tests, with 4 failures (4 unexpected) in 0.193 (0.208) seconds FileTransfer failed in test_upload_chunked. Actually it hangs since we are trying to upload to Apache.org (which we can't upload to of course) - ideally it should timeout quickly and fail, and not hang. -- This message is automatically generated
[jira] [Updated] (CB-2275) Explicitly initialize NSURLCache in the project template
[ https://issues.apache.org/jira/browse/CB-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve updated CB-2275: -- Fix Version/s: (was: 2.4.0) 2.5.0 Explicitly initialize NSURLCache in the project template Key: CB-2275 URL: https://issues.apache.org/jira/browse/CB-2275 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.5.0 According to this article: http://twobitlabs.com/2012/01/ios-ipad-iphone-nsurlcache-uiwebview-memory-utilization/ This should help with memory usage issues, as well as boost performance across runs if the app loads resources from the internet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-2180) Convert iOS project template to use ARC
[ https://issues.apache.org/jira/browse/CB-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve updated CB-2180: -- Description: CordovaLib uses ARC, but the project template has ARC turned off. This is so that existing plugins will not break when installed. Consensus from linked to ML thread is to wait until we switch to using CLI as the supported way of making a project before switching the project template. Convert iOS project template to use ARC --- Key: CB-2180 URL: https://issues.apache.org/jira/browse/CB-2180 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.4.0 CordovaLib uses ARC, but the project template has ARC turned off. This is so that existing plugins will not break when installed. Consensus from linked to ML thread is to wait until we switch to using CLI as the supported way of making a project before switching the project template. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-1547) onReset and onHandleOpenUrl are wrongly called when there are two CDVWebViews present at the same time.
[ https://issues.apache.org/jira/browse/CB-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve updated CB-1547: -- Fix Version/s: (was: 2.4.0) 2.5.0 onReset and onHandleOpenUrl are wrongly called when there are two CDVWebViews present at the same time. --- Key: CB-1547 URL: https://issues.apache.org/jira/browse/CB-1547 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: Master Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.5.0 The issue here is that we are using NSNotificationCenter to broadcast listen to events, but plugins to not restrict to their associated webview. We can fix this by not using NotificationCenter, or by restricting the listener to the webview object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-1518) FileTransfer.download progress events has this.lengthComputable = false when response is gzipped on iOS
[ https://issues.apache.org/jira/browse/CB-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve updated CB-1518: -- Fix Version/s: (was: 2.4.0) 2.5.0 FileTransfer.download progress events has this.lengthComputable = false when response is gzipped on iOS --- Key: CB-1518 URL: https://issues.apache.org/jira/browse/CB-1518 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.2.0 Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.5.0 As far as I can tell, there is no way to track the actual bytes downloaded except for changing network stacks to something like ASI's. Lame other option #1: Re-gzip the response locally to approximate. Lame other option #2: Send a second request HEAD request without accept-encoding header (while the first request is in progress), and that will tell us the expected non-compressed length. This option is actually reasonable I think. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-1594) CDVViewController leaks
[ https://issues.apache.org/jira/browse/CB-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve updated CB-1594: -- Fix Version/s: (was: 2.4.0) 2.5.0 CDVViewController leaks --- Key: CB-1594 URL: https://issues.apache.org/jira/browse/CB-1594 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: Master Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.5.0 Noticed when running the iOS unit tests that the retain count for CDVViewController is unreasonably high, and that dealloc is never called for it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-2207) Xcode sometimes does not pick up changes to www/
[
https://issues.apache.org/jira/browse/CB-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Grieve updated CB-2207:
--
Fix Version/s: (was: 2.4.0)
2.5.0
Xcode sometimes does not pick up changes to www/
Key: CB-2207
URL: https://issues.apache.org/jira/browse/CB-2207
Project: Apache Cordova
Issue Type: Bug
Components: iOS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.5.0
Pretty annoying when you make changes and click Play and your changes aren't
there. I think we can fix this by changing the project template's custom
build step from:
touch -cm ${PROJECT_DIR}/www
to:
rm -rf $BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME/www
exec cp -R www $BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME/www
Any objections?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2293) File Tranfer of picture fails on every other picture
[
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566638#comment-13566638
]
Andrew Grieve commented on CB-2293:
---
Yeah, I don't know what to look for if there's nothing obvious.
Amrit, are you also hitting an Apache server? Possible the issue is
httpd-specific.
There's now a new RC with the fix for bufferSize vs amountRead available here
in case you want to double check that it's still broken:
https://dl.dropbox.com/u/6648754/cordova-2.4.0rc2/cordova-2.4.0rc2/cordova-android.zip
I'm currently out of ideas :(
File Tranfer of picture fails on every other picture
Key: CB-2293
URL: https://issues.apache.org/jira/browse/CB-2293
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.2.0, 2.3.0
Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as
a Samsung Galaxy S3(Android 4.1.1)
Reporter: Amrit Kahlon
Assignee: Joe Bowser
Attachments: cordova-2.4.0rc1.jar
When uploading pictures using the File Transfer function on android, the
first picture will upload fine. Then the second upload will give the
following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from
connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
{target:http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2api_key=xsource=androidapp-2.2.1,source:file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392,code:3}
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto
failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by:
libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendto(Posix.java:146)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
01-21 13:48:02.555: E/FileTransfer(8894): at
[jira] [Created] (CB-2305) Add InAppBrowser.executeScript() / InAppBrowser.insertCSS API
Andrew Grieve created CB-2305:
-
Summary: Add InAppBrowser.executeScript() / InAppBrowser.insertCSS
API
Key: CB-2305
URL: https://issues.apache.org/jira/browse/CB-2305
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS
Reporter: Andrew Grieve
Priority: Minor
Maybe base it off of:
http://developer.chrome.com/extensions/tabs.html#method-executeScript
http://developer.chrome.com/extensions/tabs.html#method-insertCSS
(we can probably implement insertCSS all in JS by using executeScript)
var wnd = window.open('local.html', '_blank', 'location=yes');
wnd.executeScript({runAt:'document_start', file:'extra.js'}, function(result) {
alert(result); // result = (result of last statement).
});
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-2306) FileTransfer.download does not support file:/// URLs on Android
Andrew Grieve created CB-2306:
-
Summary: FileTransfer.download does not support file:/// URLs on
Android
Key: CB-2306
URL: https://issues.apache.org/jira/browse/CB-2306
Project: Apache Cordova
Issue Type: Bug
Components: Android
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
This was recently fixed for iOS. Likely what users want here is to use the
Entry.copyTo API instead, but some have tried this, so it's worth reporting.
I started on a fix for this by mapping it to copyTo on the JS side:
argscheck.checkArgs('ssFF*', 'FileTransfer.download', arguments);
// Convert transfers from file:/// into File.copyTo calls.
if ('' + (/^.*?:/.exec(source)) == 'file:') {
var parts = /(.*)\/(.*?)$/.exec(target);
exec(successCallback, errorCallback, File, copyTo,
[source.slice(7), parts[1], parts[2]]);
return;
}
This still failed the mobile spec test though due to /android_asset/ paths not
being resolved on the native side. We may want to add /android_asset/
resolution into resolveLocalFileSystemURI as well...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2227) Move mapping of module-symbol into individual plugins
[
https://issues.apache.org/jira/browse/CB-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13565751#comment-13565751
]
Andrew Grieve commented on CB-2227:
---
This is now complete and just needs to be merged.
Move mapping of module-symbol into individual plugins
--
Key: CB-2227
URL: https://issues.apache.org/jira/browse/CB-2227
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.4.0
Goals:
- Change from listing module-symbol mapping within common.js platform.js,
to listing this within the plugins themselves.
- Support apps that don't want us to clobber global symbols.
aka, allow module-symbol mapping to be turned off
- Allow retrieval of clobbered globals
- Currently modules save it themselves when they are loaded
- This won't work (reliably) for saving references to globals overridden by
other modules
- This gets in the way of the idea of lazy-loading modules via getters
- Support the use of other module loaders
- So... don't do crazy things at require() time.
Requirements:
Plugins must be able to declare dependencies
Plugins must be able to delay onDeviceReady()
Plugins must be able to run code to initialize
Implementation
modulemapper.js:
clobbers(...)
merges(...)
defaults(...)
mapModules(wnd)
getOriginalSymbol('FileSystem')
Start-up flow:
Parse all modules
common-bootstrap:
Loads list of modules named cordova.*/symbols
Run modulemapper.mapModules(window);
Loads list of modules named cordova.*/main
symbols.js files:
Will make calls to modulemapper instead of exporting {clobbers:}
This make dependencies work by require()ing dependent symbols
We want the to be an evaluated .js file instead of something listed in
plugin.xml
So that it can export based on browser version
Implementation Steps
1. - Expose list of registered modules in scripts/require.js so that we can
loop over them
2. - Write modulemapper.js (and have unit tests, of course)
3. - Add logic to bootstrap.js that calls into modulemapper
create $PLUGIN_NAME/symbols.js files for each plugin within cordova.
4. - Add logic to bootstrap.js that calls into modulemapper
5. - Create main.js files for those that currently have logic in their
platform.js files
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2293) File Tranfer of picture fails on every other picture
[
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566099#comment-13566099
]
Andrew Grieve commented on CB-2293:
---
Hey Drew! Thanks for helping out here! Is your stack trace the same?
File Tranfer of picture fails on every other picture
Key: CB-2293
URL: https://issues.apache.org/jira/browse/CB-2293
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.2.0, 2.3.0
Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as
a Samsung Galaxy S3(Android 4.1.1)
Reporter: Amrit Kahlon
Assignee: Joe Bowser
Attachments: cordova-2.4.0rc1.jar
When uploading pictures using the File Transfer function on android, the
first picture will upload fine. Then the second upload will give the
following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from
connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
{target:http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2api_key=xsource=androidapp-2.2.1,source:file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392,code:3}
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto
failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by:
libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendto(Posix.java:146)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:473)
01-21 13:48:02.555: E/FileTransfer(8894): ... 9 more
01-21 13:48:02.575: D/CordovaLog(8894): error:
[jira] [Commented] (CB-2301) EXC_BAD_ACCESS on resume/wake on iOS device
[ https://issues.apache.org/jira/browse/CB-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13564708#comment-13564708 ] Andrew Grieve commented on CB-2301: --- hmm, from the screenshot, it looks like the UI thread is waiting on the web thread lock. I'm not sure if this is significant or not though. I don't have any good guidance on how to debug this though :(. Best guess is to try and delete parts of your app until you figure out what exactly it is that is triggering the crash. EXC_BAD_ACCESS on resume/wake on iOS device --- Key: CB-2301 URL: https://issues.apache.org/jira/browse/CB-2301 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.2.0 Environment: iPhone 5 running iOS 6.0.2 and Phonegap 2.2.0. (Xcode 4.5.2 on Mountain Lion) Reporter: Ross Holdway Assignee: Shazron Abdullah Priority: Critical Labels: cordova, ios, phonegap I have implemented a websocket connection (using socket.io) within my app which it uses to communicate with the server. On locking and waking the device, it disconnects and reconnects correctly, but on leaving the device locked for 1 minute or longer when unlocking, the application will crash sometimes instantly, or sometimes after reconnecting with the server. If I do the same, but run my app within mobile Safari, it does not crash, leading me to believe this is an issue with Phonegap/Cordova. On app crash, within Xcode I get within WebThread - WebCore::ThreadTImers::sharedTimerFiredInternal() an EXC_BAD_ACCESS (code=1) error Screenshot of crash state in Xcode -http://pictat.com/i/2013/1/28/24904screenshot.jpg Hopefully someone will have an idea as to what could be causing this, or recommend some tests for me to run etc because I'm really clueless on how to proceed with fixing this! Many Thanks, Ross -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2285) No more activities from Cordova
[ https://issues.apache.org/jira/browse/CB-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562772#comment-13562772 ] Andrew Grieve commented on CB-2285: --- Okay, thanks for checking this out for me. I'll take a look today. No more activities from Cordova --- Key: CB-2285 URL: https://issues.apache.org/jira/browse/CB-2285 Project: Apache Cordova Issue Type: Bug Components: iOS, Mac Affects Versions: 2.3.0, 2.4.0 Environment: OSX - iOS 6 tested Reporter: fabian boulegue Assignee: Shazron Abdullah Labels: inAppBrowser, notification I use it for iOS (6), i builded a app with inAppBrowser as well then some Notifications. From time to time, if i switched the pages and used some of the Browser and Notifications it comes to a point where no more activities by Cordova can be handle. If i then click on the Notification button nothing happens (also no console output) anyone a idea whats wrong (normally on first try all of the functions work great.) If i should submit any more informations please ask for would be great to have a fix for that -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1807) Android navigator.connection.type is not equal to navigator.network.connection.type
[ https://issues.apache.org/jira/browse/CB-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562775#comment-13562775 ] Andrew Grieve commented on CB-1807: --- Hmm, sorry, I don't know what you beem by 6-15. What I'm wondering is: 1. Does this problem happen only on your samsung gt-i9300, or are you able to reproduce it on any emulators/other devices (and if so, which ones) 2. What OS version does your gt-i9300 run? e.g. 2.3.0, 4.0, etc. Android navigator.connection.type is not equal to navigator.network.connection.type --- Key: CB-1807 URL: https://issues.apache.org/jira/browse/CB-1807 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.2.0 Reporter: Thejaswi Puthraya Assignee: Andrew Grieve Fix For: 2.3.0 Attachments: index.html As per the documentation and example navigator.connection.type is what was previously navigator.network.connection.type. Before Cordova 2.2.0, the Connection object existed at: navigator.network.connection. To match the spec, this was changed to navigator.connection in 2.2.0. navigator.network.connection still exists, but is now deprecated and will be removed in a future release. But in the file that I am enclosing to reproduce the bug, navigator.connection.type is always (irrespective of connection) 'unknown'(0) though navigator.network.connection.type returns the correct value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2285) No more activities from Cordova
[ https://issues.apache.org/jira/browse/CB-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562790#comment-13562790 ] Andrew Grieve commented on CB-2285: --- Was able to repro by following your video. When I updated the version of CordovaLib to what's at master though, the problem went away. There was again one InAppBrowser-related fix between rc1 and master, so possible that it fixed the underlying issue. I'll leave this open until you can confirm that it's fixed. Maybe try again when rc2 is out. All I did was Deleted the CordovaLib in your project and copied in the CordovaLib from master. No more activities from Cordova --- Key: CB-2285 URL: https://issues.apache.org/jira/browse/CB-2285 Project: Apache Cordova Issue Type: Bug Components: iOS, Mac Affects Versions: 2.3.0, 2.4.0 Environment: OSX - iOS 6 tested Reporter: fabian boulegue Assignee: Andrew Grieve Labels: inAppBrowser, notification I use it for iOS (6), i builded a app with inAppBrowser as well then some Notifications. From time to time, if i switched the pages and used some of the Browser and Notifications it comes to a point where no more activities by Cordova can be handle. If i then click on the Notification button nothing happens (also no console output) anyone a idea whats wrong (normally on first try all of the functions work great.) If i should submit any more informations please ask for would be great to have a fix for that -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2293) File Tranfer of picture fails on every other picture
[
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13563224#comment-13563224
]
Andrew Grieve commented on CB-2293:
---
Heh, first result when searching for the error is another Cordova user with the
same problem :(.
http://stackoverflow.com/questions/12643238/epipe-broken-pipe-bug-while-using-filetransfer-plugin-with-cordova-2-0
File Tranfer of picture fails on every other picture
Key: CB-2293
URL: https://issues.apache.org/jira/browse/CB-2293
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.2.0, 2.3.0
Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as
a Samsung Galaxy S3(Android 4.1.1)
Reporter: Amrit Kahlon
Assignee: Joe Bowser
When uploading pictures using the File Transfer function on android, the
first picture will upload fine. Then the second upload will give the
following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from
connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
{target:http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2api_key=xsource=androidapp-2.2.1,source:file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392,code:3}
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto
failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by:
libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendto(Posix.java:146)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:473)
01-21 13:48:02.555: E/FileTransfer(8894): ... 9 more
01-21 13:48:02.575: D/CordovaLog(8894): error:
[jira] [Commented] (CB-2293) File Tranfer of picture fails on every other picture
[
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13563237#comment-13563237
]
Andrew Grieve commented on CB-2293:
---
Soo... pretty hard bug to work on because it's not easy to reproduce. But,
looking at the line that's throwing an exception, I have a theory as to what's
wrong, and I'm wondering if you'd be able to try it out to see if it fixes the
problem.
On line 372 of FileTransfer.java, I think:
dos.write(buffer, 0, bufferSize);
should say:
dos.write(buffer, 0, bytesRead);
I'll likely commit this anyways, since it's a pretty obvious bug, but would
also love to know if it fixes your app.
File Tranfer of picture fails on every other picture
Key: CB-2293
URL: https://issues.apache.org/jira/browse/CB-2293
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.2.0, 2.3.0
Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as
a Samsung Galaxy S3(Android 4.1.1)
Reporter: Amrit Kahlon
Assignee: Joe Bowser
When uploading pictures using the File Transfer function on android, the
first picture will upload fine. Then the second upload will give the
following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from
connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
{target:http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2api_key=xsource=androidapp-2.2.1,source:file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392,code:3}
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto
failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by:
libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendto(Posix.java:146)
01-21 13:48:02.555: E/FileTransfer(8894): at
[jira] [Commented] (CB-2293) File Tranfer of picture fails on every other picture
[
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13563295#comment-13563295
]
Andrew Grieve commented on CB-2293:
---
Hmm, I'm guessing you're using cordova in the form a .jar then? try this
(attaching jar with the change to this bug)
File Tranfer of picture fails on every other picture
Key: CB-2293
URL: https://issues.apache.org/jira/browse/CB-2293
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.2.0, 2.3.0
Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as
a Samsung Galaxy S3(Android 4.1.1)
Reporter: Amrit Kahlon
Assignee: Joe Bowser
Attachments: cordova-2.4.0rc1.jar
When uploading pictures using the File Transfer function on android, the
first picture will upload fine. Then the second upload will give the
following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from
connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
{target:http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2api_key=xsource=androidapp-2.2.1,source:file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392,code:3}
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto
failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by:
libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendto(Posix.java:146)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:473)
01-21 13:48:02.555: E/FileTransfer(8894): ... 9 more
01-21 13:48:02.575: D/CordovaLog(8894): error:
[jira] [Updated] (CB-2293) File Tranfer of picture fails on every other picture
[
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Grieve updated CB-2293:
--
Attachment: cordova-2.4.0rc1.jar
File Tranfer of picture fails on every other picture
Key: CB-2293
URL: https://issues.apache.org/jira/browse/CB-2293
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.2.0, 2.3.0
Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as
a Samsung Galaxy S3(Android 4.1.1)
Reporter: Amrit Kahlon
Assignee: Joe Bowser
Attachments: cordova-2.4.0rc1.jar
When uploading pictures using the File Transfer function on android, the
first picture will upload fine. Then the second upload will give the
following error:
01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from
connection.
01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.io.Streams.readAsciiLine(Streams.java:203)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
01-21 13:48:02.545: W/FileTransfer(8894): at
libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
01-21 13:48:02.545: W/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.545: W/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894):
{target:http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2api_key=xsource=androidapp-2.2.1,source:file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392,code:3}
01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto
failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:475)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.io.DataOutputStream.write(DataOutputStream.java:98)
01-21 13:48:02.555: E/FileTransfer(8894): at
org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
01-21 13:48:02.555: E/FileTransfer(8894): at
java.lang.Thread.run(Thread.java:856)
01-21 13:48:02.555: E/FileTransfer(8894): Caused by:
libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendtoBytes(Native Method)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.Posix.sendto(Posix.java:146)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
01-21 13:48:02.555: E/FileTransfer(8894): at
libcore.io.IoBridge.sendto(IoBridge.java:473)
01-21 13:48:02.555: E/FileTransfer(8894): ... 9 more
01-21 13:48:02.575: D/CordovaLog(8894): error:
{code:3,source:file:///storage/sdcard0/Android/data/com.hockeycommunity.hc_app/cache/resize.jpg?1358804880392,target:http://xxx.xxx./api/photo_uploads/create?version=2api_key=xxxsource=androidapp-2.2.1,http_status:null}
01-21 13:48:02.575: I/Web Console(8894): error:
[jira] [Commented] (CB-2225) User-Agent changes in the CordovaWebView after using InAppBrowser
[ https://issues.apache.org/jira/browse/CB-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13561846#comment-13561846 ] Andrew Grieve commented on CB-2225: --- The first fix wasn't working properly (was applying the PDF fix to all requests). Here's the follow-up fix: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=b8f7515bdb840be4619ecee2f6ed71a0a57dbad1 User-Agent changes in the CordovaWebView after using InAppBrowser - Key: CB-2225 URL: https://issues.apache.org/jira/browse/CB-2225 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Shazron Abdullah Assignee: Andrew Grieve Fix For: 2.4.0 Attachments: www-cb-2102.zip See CB-2102. Attached www-cb-2102.zip which I tested with Cordova 2.3.0. Repro: 1. On the main index.html, touch the UserAgent button, observe that the UA has a numbered suffix (correct) 2. Touch the About link to go to the About page 3. On the About page, touch the UserAgent button, observe that the UA has a numbered suffix (correct, it's the same as in (1)) 4. Touch the English link, this will load a PDF in the InAppBrowser 5. Touch the Done button in the InAppBrowser to dismiss it 6. Now you are back to the About page, touch the UserAgent button again, and note that the UA is not the same as expected in (3) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2271) Creating multiple CDVViewControllers at once only fires deviceready once
[ https://issues.apache.org/jira/browse/CB-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-2271. --- Resolution: Fixed We now serialize initial webview loads behind-the-scenes. Fix commit: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=be6e4d3cce3b5d3d5682b62a63d0e402a059e7a8 Creating multiple CDVViewControllers at once only fires deviceready once Key: CB-2271 URL: https://issues.apache.org/jira/browse/CB-2271 Project: Apache Cordova Issue Type: Bug Components: iOS Environment: Reproducible on iPad/iPhone 5.0 and 6.0 simulator Reporter: Mike Kwan Assignee: Andrew Grieve Fix For: 2.3.0 Steps taken to reproduce: 1. Create custom container view controller 2. In viewDidLoad add two CDVViewControllers as childViewControllers and hook up view hierarchy appropriately 3. deviceready will fire for startPage on the first CDVViewController but not for the second Workaround: Add the second CDVViewController after some delay (e.g. 1 second) Image: http://localhostr.com/9JszfWk9b7Pa More info: After some investigation, the problem seems to be a manifestation of a race condition where the address of the CDVViewController passes in the user-agent is clobbered. This means sometimes one CDVViewController will get deviceready and at other times the other one will (but never both). I believe this is another case where someone has reproduced this bug: http://stackoverflow.com/questions/13082330/phonegap-cordova-with-multiple-cdvviewcontroller Attachments (minimal example reproducing bug and workaround): http://localhostr.com/5x4AsO1oFonU -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-2271) Creating multiple CDVViewControllers at once only fires deviceready once
[ https://issues.apache.org/jira/browse/CB-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve updated CB-2271: -- Fix Version/s: (was: 2.3.0) 2.4.0 Creating multiple CDVViewControllers at once only fires deviceready once Key: CB-2271 URL: https://issues.apache.org/jira/browse/CB-2271 Project: Apache Cordova Issue Type: Bug Components: iOS Environment: Reproducible on iPad/iPhone 5.0 and 6.0 simulator Reporter: Mike Kwan Assignee: Andrew Grieve Fix For: 2.4.0 Steps taken to reproduce: 1. Create custom container view controller 2. In viewDidLoad add two CDVViewControllers as childViewControllers and hook up view hierarchy appropriately 3. deviceready will fire for startPage on the first CDVViewController but not for the second Workaround: Add the second CDVViewController after some delay (e.g. 1 second) Image: http://localhostr.com/9JszfWk9b7Pa More info: After some investigation, the problem seems to be a manifestation of a race condition where the address of the CDVViewController passes in the user-agent is clobbered. This means sometimes one CDVViewController will get deviceready and at other times the other one will (but never both). I believe this is another case where someone has reproduced this bug: http://stackoverflow.com/questions/13082330/phonegap-cordova-with-multiple-cdvviewcontroller Attachments (minimal example reproducing bug and workaround): http://localhostr.com/5x4AsO1oFonU -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1807) Android navigator.connection.type is not equal to navigator.network.connection.type
[ https://issues.apache.org/jira/browse/CB-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13562262#comment-13562262 ] Andrew Grieve commented on CB-1807: --- What OS / device are you using? Android navigator.connection.type is not equal to navigator.network.connection.type --- Key: CB-1807 URL: https://issues.apache.org/jira/browse/CB-1807 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.2.0 Reporter: Thejaswi Puthraya Assignee: Andrew Grieve Fix For: 2.3.0 Attachments: index.html As per the documentation and example navigator.connection.type is what was previously navigator.network.connection.type. Before Cordova 2.2.0, the Connection object existed at: navigator.network.connection. To match the spec, this was changed to navigator.connection in 2.2.0. navigator.network.connection still exists, but is now deprecated and will be removed in a future release. But in the file that I am enclosing to reproduce the bug, navigator.connection.type is always (irrespective of connection) 'unknown'(0) though navigator.network.connection.type returns the correct value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2235) FileTransfer spec test failing on iOS5
[ https://issues.apache.org/jira/browse/CB-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13560882#comment-13560882 ] Andrew Grieve commented on CB-2235: --- Fix commit: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=db22768362823bf6f84cbaead6c03dd1764f60b2 FileTransfer spec test failing on iOS5 -- Key: CB-2235 URL: https://issues.apache.org/jira/browse/CB-2235 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Andrew Grieve Assignee: Max Woghiren Fix For: 2.4.0 I'm seeing all tests passing on iOS 6 simulator, but 4 tests failing on iOS5 simulator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CB-2235) FileTransfer spec test failing on iOS5
[ https://issues.apache.org/jira/browse/CB-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve closed CB-2235. - FileTransfer spec test failing on iOS5 -- Key: CB-2235 URL: https://issues.apache.org/jira/browse/CB-2235 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Andrew Grieve Assignee: Max Woghiren Fix For: 2.4.0 I'm seeing all tests passing on iOS 6 simulator, but 4 tests failing on iOS5 simulator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files
[ https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559719#comment-13559719 ] Andrew Grieve commented on CB-285: -- I'd like to list out all of the potential storage areas, and then let's talk about whether we should map them to a requestLocalFilesystem constant. Android (http://developer.android.com/guide/topics/data/data-storage.html): - Resources.raw - no URL mapping - read-only - no subdirectories - iteration through reflection only? - Assets directory - file://android_assets (URL mapping works only for initial page load?) - read-only - includes www directory - Internal app storage - file:///data/data/$PACKAGE_NAME/files - read-write - Use Context.openFileOutput / Context.fileList - Internal cache - file:///data/data/$PACKAGE_NAME/cache - Context.getCacheDir() - External app storage: - file:///sdcard/Android/data/$PACKAGE_NAME/files - or this?: content://com.android.htmlfileprovider/ - Context.getExternalFilesDir() - Requires WRITE_EXTERNAL_STORAGE permission - External cache - file:///sdcard/Android/data/$PACKAGE_NAME/cache - Context.getExternalCacheDir() - Requires WRITE_EXTERNAL_STORAGE permission - External root (Root sdcard) - file:///sdcard - Context.getExternalFilesDir(null) or Environment.getExternalStorageDirectory() - Requires WRITE_EXTERNAL_STORAGE permission - External media (shared files) - file:///sdcard/Music / Photos / etc. - Context.getExternalFilesDir(Environment.DIRECTORY_PICTURES) - Requires WRITE_EXTERNAL_STORAGE permission Complicated enough? :P Looking at our current implementation of requestLocalFilesystem(), we use: PERSISTENT == External root if sdcard is mounted, Internal app storage otherwise (minus the /files suffix) TEMPORARY == External cache if sdcard is mounted, Internal cache otherwise. I'll dig into iOS next. Add property returning root path of PhoneGap files -- Key: CB-285 URL: https://issues.apache.org/jira/browse/CB-285 Project: Apache Cordova Issue Type: Improvement Components: CordovaJS Affects Versions: 1.4.0 Environment: Both PhoneGap SDK and PhoneGap Build Reporter: Ashley Gullen Assignee: Andrew Grieve Labels: features There needs to be a property in PhoneGap that returns the root path to the general files added to the PhoneGap project (i.e. the directory index.html is in). For example, if I add 'music.mp3' to my project, in Android it will be located in: /android_asset/www/music.mp3 On iOS after being built with PhoneGap Build it will be located in some path like this: /var/mobile/Applications/app_ID/name.app/www/music.mp3 However, there does not appear to be a programmatic way to determine both app_ID and name.app. This has two side effects: 1. Paths to audio for Media must be hard-coded separately depending on the platform, which is inconvenient. 2. Paths to audio for Media cannot be known if developing a framework that uses PhoneGap. Since a framework does not know the App ID or name in advance, it's impossible for the framework to determine the correct path. This is actively blocking audio from working on iOS in PhoneGap projects exported by Construct 2 (www.scirra.com), a HTML5 game creator. Also, it seems like kind of an important function to make available anyway, since hard-coding paths for each platform is a pain. This PhoneGap Support thread led to this issue: http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CB-285) Add property returning root path of PhoneGap files
[ https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559719#comment-13559719 ] Andrew Grieve edited comment on CB-285 at 1/22/13 5:37 PM: --- I'd like to list out all of the potential storage areas, and then let's talk about whether we should map them to a requestLocalFilesystem constant. Android (http://developer.android.com/guide/topics/data/data-storage.html): *Resources.raw* - no URL mapping - read-only - no subdirectories - iteration through reflection only? *Assets directory* - file://android_assets (URL mapping works only for initial page load?) - read-only - includes www directory *Internal app storage* - file:///data/data/$PACKAGE_NAME/files - read-write - Use Context.openFileOutput / Context.fileList *Internal cache* - file:///data/data/$PACKAGE_NAME/cache - Context.getCacheDir() *External app storage* - file:///sdcard/Android/data/$PACKAGE_NAME/files - or this?: content://com.android.htmlfileprovider/ - Context.getExternalFilesDir() - Requires WRITE_EXTERNAL_STORAGE permission *External cache* - file:///sdcard/Android/data/$PACKAGE_NAME/cache - Context.getExternalCacheDir() - Requires WRITE_EXTERNAL_STORAGE permission *External root (Root sdcard)* - file:///sdcard - Context.getExternalFilesDir(null) or Environment.getExternalStorageDirectory() - Requires WRITE_EXTERNAL_STORAGE permission *External media (shared files)* - file:///sdcard/Music / Photos / etc. - Context.getExternalFilesDir(Environment.DIRECTORY_PICTURES) - Requires WRITE_EXTERNAL_STORAGE permission Complicated enough? :P Looking at our current implementation of requestLocalFilesystem(), we use: PERSISTENT == External root if sdcard is mounted, Internal app storage otherwise (minus the /files suffix) TEMPORARY == External cache if sdcard is mounted, Internal cache otherwise. I'll dig into iOS next. was (Author: agrieve): I'd like to list out all of the potential storage areas, and then let's talk about whether we should map them to a requestLocalFilesystem constant. Android (http://developer.android.com/guide/topics/data/data-storage.html): - Resources.raw - no URL mapping - read-only - no subdirectories - iteration through reflection only? - Assets directory - file://android_assets (URL mapping works only for initial page load?) - read-only - includes www directory - Internal app storage - file:///data/data/$PACKAGE_NAME/files - read-write - Use Context.openFileOutput / Context.fileList - Internal cache - file:///data/data/$PACKAGE_NAME/cache - Context.getCacheDir() - External app storage: - file:///sdcard/Android/data/$PACKAGE_NAME/files - or this?: content://com.android.htmlfileprovider/ - Context.getExternalFilesDir() - Requires WRITE_EXTERNAL_STORAGE permission - External cache - file:///sdcard/Android/data/$PACKAGE_NAME/cache - Context.getExternalCacheDir() - Requires WRITE_EXTERNAL_STORAGE permission - External root (Root sdcard) - file:///sdcard - Context.getExternalFilesDir(null) or Environment.getExternalStorageDirectory() - Requires WRITE_EXTERNAL_STORAGE permission - External media (shared files) - file:///sdcard/Music / Photos / etc. - Context.getExternalFilesDir(Environment.DIRECTORY_PICTURES) - Requires WRITE_EXTERNAL_STORAGE permission Complicated enough? :P Looking at our current implementation of requestLocalFilesystem(), we use: PERSISTENT == External root if sdcard is mounted, Internal app storage otherwise (minus the /files suffix) TEMPORARY == External cache if sdcard is mounted, Internal cache otherwise. I'll dig into iOS next. Add property returning root path of PhoneGap files -- Key: CB-285 URL: https://issues.apache.org/jira/browse/CB-285 Project: Apache Cordova Issue Type: Improvement Components: CordovaJS Affects Versions: 1.4.0 Environment: Both PhoneGap SDK and PhoneGap Build Reporter: Ashley Gullen Assignee: Andrew Grieve Labels: features There needs to be a property in PhoneGap that returns the root path to the general files added to the PhoneGap project (i.e. the directory index.html is in). For example, if I add 'music.mp3' to my project, in Android it will be located in: /android_asset/www/music.mp3 On iOS after being built with PhoneGap Build it will be located in some path like this: /var/mobile/Applications/app_ID/name.app/www/music.mp3 However, there does not appear to be a programmatic way to determine both app_ID and name.app. This has two side effects: 1. Paths to audio for Media must be hard-coded separately depending on the platform, which is inconvenient. 2. Paths to audio for Media
[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files
[ https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559932#comment-13559932 ] Andrew Grieve commented on CB-285: -- iOS (http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html) *Application Bundle* - [[NSBundle mainBundle] bundlePath] - Read-only *Application_Home/Documents* - For user-data. - Backed up by iCloud, where each file is shown as an entry. *Application_Home/Documents/Inbox* - Can't create or write files, but *can* delete read files. - Used for receiving files from Mail.app *Application_Home/Library* - Backed up by iCloud unless com.apple.MobileBackup attribute is set. - All files shown as a single entry in iCloud *Application_Home/Library/Application Support* - Same as /Library it looks like... *Application_Home/Library/Caches* - Not backed up by iCloud *Application_Home/tmp* - Not backed up by iCloud - Get this via NSTemporaryDirectory() (it's /var/folders/ when on simulator) Application_Home == /var/mobile/Applications/app id/. Retrieve it with NSHomeDirectory() PERSISTENT == Application_Home/Documents TEMPORARY == Application_Home/tmp Add property returning root path of PhoneGap files -- Key: CB-285 URL: https://issues.apache.org/jira/browse/CB-285 Project: Apache Cordova Issue Type: Improvement Components: CordovaJS Affects Versions: 1.4.0 Environment: Both PhoneGap SDK and PhoneGap Build Reporter: Ashley Gullen Assignee: Andrew Grieve Labels: features There needs to be a property in PhoneGap that returns the root path to the general files added to the PhoneGap project (i.e. the directory index.html is in). For example, if I add 'music.mp3' to my project, in Android it will be located in: /android_asset/www/music.mp3 On iOS after being built with PhoneGap Build it will be located in some path like this: /var/mobile/Applications/app_ID/name.app/www/music.mp3 However, there does not appear to be a programmatic way to determine both app_ID and name.app. This has two side effects: 1. Paths to audio for Media must be hard-coded separately depending on the platform, which is inconvenient. 2. Paths to audio for Media cannot be known if developing a framework that uses PhoneGap. Since a framework does not know the App ID or name in advance, it's impossible for the framework to determine the correct path. This is actively blocking audio from working on iOS in PhoneGap projects exported by Construct 2 (www.scirra.com), a HTML5 game creator. Also, it seems like kind of an important function to make available anyway, since hard-coding paths for each platform is a pain. This PhoneGap Support thread led to this issue: http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2285) No more activities from Cordova
[ https://issues.apache.org/jira/browse/CB-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559985#comment-13559985 ] Andrew Grieve commented on CB-2285: --- There were a couple of bridge / InAppBrowser-related bugs that were fixed since the release of 2.3.0. Would you mind testing your code against master? If not, 2.4.0 will be out soon (likely next week), so we can have a look after that. No more activities from Cordova --- Key: CB-2285 URL: https://issues.apache.org/jira/browse/CB-2285 Project: Apache Cordova Issue Type: Bug Components: iOS, Mac Affects Versions: 2.3.0 Environment: OSX - iOS 6 tested Reporter: fabian boulegue Assignee: Shazron Abdullah Labels: inAppBrowser, notification I use it for iOS (6), i builded a app with inAppBrowser as well then some Notifications. From time to time, if i switched the pages and used some of the Browser and Notifications it comes to a point where no more activities by Cordova can be handle. If i then click on the Notification button nothing happens (also no console output) anyone a idea whats wrong (normally on first try all of the functions work great.) If i should submit any more informations please ask for would be great to have a fix for that -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-975) camera.getPicture crashes app on iPad3 when capturing multiple images
[
https://issues.apache.org/jira/browse/CB-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558814#comment-13558814
]
Andrew Grieve commented on CB-975:
--
Hey Lucas, just to confirm: Have you confirmed that you app crashes with your
code and nothing else? I've tried similar code in empty projects before without
being able to repro the problem, so my theory is that the problem may be
related to other things that are in the app. e.g. maybe some CSS / DOM layout
triggers it.
camera.getPicture crashes app on iPad3 when capturing multiple images
-
Key: CB-975
URL: https://issues.apache.org/jira/browse/CB-975
Project: Apache Cordova
Issue Type: Bug
Components: iOS
Affects Versions: 1.7.0, 1.8.1, 1.9.0, 2.0.0
Environment: iOS 5.1.1
iPad 3 (device is not jailbbroken or anything special, stock standard)
Built on PhoneGap Build service
iPhone 4s
Reporter: Andrew Smith
Assignee: Shazron Abdullah
Priority: Critical
Labels: camera, memory
I have a page which allows users to capture multiple images, one after the
other. Somewhere between the second and fifth capture, the application
crashes. Restarting the device and closing other apps makes no difference as
to how long it takes to crash.
-deleted-I have not been able to test on an iPhone.-deleted-
Update: can confirm it happens on iPhone 4S too.
I have tried with both FILE_URI and DATA_URL, with no noticeable change.
Here is my pared down code which exhibits the detailed behaviour. This
method is called from an onclick event on a DIV element.
{code:javascript}
ModFormCommon.AddPhoto = function () {
if (!navigator.camera) {
alert(Photos are not supported on this device);
return;
}
navigator.camera.getPicture(
function( data ) {
alert(Photo taken: + data.length);
},
function (sMessage) {
alert(Photo error: + sMessage);
},
{
quality: 25,
//destinationType: Camera.DestinationType.FILE_URI
destinationType: Camera.DestinationType.DATA_URL
});
};
{code}
The Crashlog is sometimes proceeded by a low memory warning, but not always,
so don't know that it's relevant.
Crashlog is as follows:
Incident Identifier: F8CD8A48-0989-479C-AC7E-4CBF31BAE737
CrashReporter Key: f491a35dbb4b6f2e7c0d29faeee7feaf7813f4c8
Hardware Model: iPad3,3
Process: MDC [809]
Path:
/var/mobile/Applications/CC253554-F6B5-4E8F-BC83-27F34241AE80/MDC.app/MDC
Identifier: MDC
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2012-06-28 11:53:53.141 +1000
OS Version: iPhone OS 5.1.1 (9B206)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x
Crashed Thread: 10
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0:
0 libsystem_kernel.dylib0x35034004 0x35033000 + 4100
1 libsystem_kernel.dylib0x350341fa 0x35033000 + 4602
2 CoreFoundation0x32b413ec 0x32ab4000 + 578540
3 CoreFoundation0x32b400ea 0x32ab4000 + 573674
4 CoreFoundation0x32ac349e 0x32ab4000 + 62622
5 CoreFoundation0x32ac3366 0x32ab4000 + 62310
6 GraphicsServices 0x32c10432 0x32c0c000 + 17458
7 UIKit 0x350a2cce 0x35071000 + 203982
8 MDC 0x24c8 0x1000 + 5320
9 MDC 0x2444 0x1000 + 5188
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib0x350343a8 0x35033000 + 5032
1 libdispatch.dylib 0x31298f04 0x31295000 + 16132
2 libdispatch.dylib 0x31298c22 0x31295000 + 15394
Thread 2 name: WebThread
Thread 2:
0 libsystem_kernel.dylib0x35034004 0x35033000 + 4100
1 libsystem_kernel.dylib0x350341fa 0x35033000 + 4602
2 CoreFoundation0x32b413ec 0x32ab4000 + 578540
3 CoreFoundation0x32b40124 0x32ab4000 + 573732
4 CoreFoundation0x32ac349e 0x32ab4000 + 62622
5 CoreFoundation0x32ac3366 0x32ab4000 + 62310
6 WebCore 0x35861c9c 0x357b8000 + 695452
7 libsystem_c.dylib 0x31f2b72e 0x31f1d000 + 59182
8 libsystem_c.dylib 0x31f2b5e8 0x31f1d000 + 58856
Thread 3 name:
[jira] [Commented] (CB-2165) The saveToPhotoAlbum option for Camera.getPicture does not work with Cordova 2.2/Android
[
https://issues.apache.org/jira/browse/CB-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558815#comment-13558815
]
Andrew Grieve commented on CB-2165:
---
I don't think we should support this since it's not how most people expect
boolean parameters to work. In all browser APIs, false == true. For example:
adsf = document.createElement('input');
adsf.checked
false
adsf.checked = false
false
adsf.checked
true
If you think this is biting a lot of people, then maybe we could check that
people pass in the correct types and throw an exception instead of coercing
them to booleans.
The saveToPhotoAlbum option for Camera.getPicture does not work with
Cordova 2.2/Android
--
Key: CB-2165
URL: https://issues.apache.org/jira/browse/CB-2165
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS
Affects Versions: 2.2.0
Environment: Cordova 2.2, Android 2.3.4
Reporter: Thomas Dinger
Assignee: Andrew Grieve
Priority: Minor
The following JS call results in a call to the success function when the
picture is taken, but the picture is not added to the photo library.
01-08 09:27:53.470: D/CordovaLog(4089): getPicture() {
01-08 09:27:53.470: D/CordovaLog(4089): targetHeight: 600,
01-08 09:27:53.470: D/CordovaLog(4089): targetWidth: 600,
01-08 09:27:53.470: D/CordovaLog(4089): saveToPhotoAlbum: true,
01-08 09:27:53.470: D/CordovaLog(4089): quality: 50,
01-08 09:27:53.470: D/CordovaLog(4089): destinationType: 1,
01-08 09:27:53.470: D/CordovaLog(4089): mediaType: 0,
01-08 09:27:53.470: D/CordovaLog(4089): encodingType: 0,
01-08 09:27:53.470: D/CordovaLog(4089): allowEdit: false,
01-08 09:27:53.470: D/CordovaLog(4089): sourceType: 1
01-08 09:27:53.470: D/CordovaLog(4089): }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-622) FileTransfer interface should provide progress monitoring
[ https://issues.apache.org/jira/browse/CB-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558824#comment-13558824 ] Andrew Grieve commented on CB-622: -- gzip encoding is almost certainly the problem. There's another bug just for this: https://issues.apache.org/jira/browse/CB-1518 It's unfortunately a low priority right now, so no one is working on it. If you'd like to take a stab at fixing it though, that would be awesome! If not, two ideas to help here: -Would using XHR2 address your use-case? -Might be able to disable gzip by setting the Accept-Encoding header to an empty string. FileTransfer interface should provide progress monitoring - Key: CB-622 URL: https://issues.apache.org/jira/browse/CB-622 Project: Apache Cordova Issue Type: Improvement Components: Android, BlackBerry, iOS, WP7 Affects Versions: 1.7.0 Environment: Checked docs for iOS and Android, and in general. Reporter: Brion Vibber Assignee: Andrew Grieve Priority: Minor Labels: FileTransfer, file Fix For: 2.2.0 The FileTransfer upload and download interface seems to provide no way to monitor progress of the upload/download, other than waiting for the entire transfer to complete or fail. Being able to pass another callback for progress monitoring could be a useful interface, this might get called with a byte count or something. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2207) Xcode sometimes does not pick up changes to www/
[
https://issues.apache.org/jira/browse/CB-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558865#comment-13558865
]
Andrew Grieve commented on CB-2207:
---
I've found rsync to be slow when used local-local, and it won't remove files
in the destination.
But!
Perhaps even better would be to use hard links. Would require a bit more of a
script since it doesn't look like cp has a flag for this.
Xcode sometimes does not pick up changes to www/
Key: CB-2207
URL: https://issues.apache.org/jira/browse/CB-2207
Project: Apache Cordova
Issue Type: Bug
Components: iOS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.4.0
Pretty annoying when you make changes and click Play and your changes aren't
there. I think we can fix this by changing the project template's custom
build step from:
touch -cm ${PROJECT_DIR}/www
to:
rm -rf $BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME/www
exec cp -R www $BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME/www
Any objections?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2180) Convert iOS project template to use ARC
[ https://issues.apache.org/jira/browse/CB-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558873#comment-13558873 ] Andrew Grieve commented on CB-2180: --- ML thread: http://callback.markmail.org/thread/tskkqinboyp5cjdg Convert iOS project template to use ARC --- Key: CB-2180 URL: https://issues.apache.org/jira/browse/CB-2180 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.4.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-2275) Explicitly initialize NSURLCache in the project template
Andrew Grieve created CB-2275: - Summary: Explicitly initialize NSURLCache in the project template Key: CB-2275 URL: https://issues.apache.org/jira/browse/CB-2275 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.4.0 According to this article: http://twobitlabs.com/2012/01/ios-ipad-iphone-nsurlcache-uiwebview-memory-utilization/ This should help with memory usage issues, as well as boost performance across runs if the app loads resources from the internet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-2276) Refactor to eliminate casts of viewControlled - CDVViewController
Andrew Grieve created CB-2276: - Summary: Refactor to eliminate casts of viewControlled - CDVViewController Key: CB-2276 URL: https://issues.apache.org/jira/browse/CB-2276 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.4.0 Any functionality needed by plugins from the CDVViewController should be exposed through CDVCommandDelegate. This will make it more clear which symbols will not change, and which are meant to be private. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2227) Move mapping of module-symbol into individual plugins
[
https://issues.apache.org/jira/browse/CB-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558940#comment-13558940
]
Andrew Grieve commented on CB-2227:
---
Initial work is now done merged:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=1aa3643deaa9f14970806277d5f651f3cd78caa9
What is left is to move other plugins over to using modulemapper (File plugin
is the only one using it atm)
Move mapping of module-symbol into individual plugins
--
Key: CB-2227
URL: https://issues.apache.org/jira/browse/CB-2227
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.4.0
Goals:
- Change from listing module-symbol mapping within common.js platform.js,
to listing this within the plugins themselves.
- Support apps that don't want us to clobber global symbols.
aka, allow module-symbol mapping to be turned off
- Allow retrieval of clobbered globals
- Currently modules save it themselves when they are loaded
- This won't work (reliably) for saving references to globals overridden by
other modules
- This gets in the way of the idea of lazy-loading modules via getters
- Support the use of other module loaders
- So... don't do crazy things at require() time.
Requirements:
Plugins must be able to declare dependencies
Plugins must be able to delay onDeviceReady()
Plugins must be able to run code to initialize
Implementation
modulemapper.js:
clobbers(...)
merges(...)
defaults(...)
mapModules(wnd)
getOriginalSymbol('FileSystem')
Start-up flow:
Parse all modules
common-bootstrap:
Loads list of modules named cordova.*/symbols
Run modulemapper.mapModules(window);
Loads list of modules named cordova.*/main
symbols.js files:
Will make calls to modulemapper instead of exporting {clobbers:}
This make dependencies work by require()ing dependent symbols
We want the to be an evaluated .js file instead of something listed in
plugin.xml
So that it can export based on browser version
Implementation Steps
1. - Expose list of registered modules in scripts/require.js so that we can
loop over them
2. - Write modulemapper.js (and have unit tests, of course)
3. - Add logic to bootstrap.js that calls into modulemapper
create $PLUGIN_NAME/symbols.js files for each plugin within cordova.
4. - Add logic to bootstrap.js that calls into modulemapper
5. - Create main.js files for those that currently have logic in their
platform.js files
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1957) InAppBrowser - video/audio does not stop playing when browser is closed
[ https://issues.apache.org/jira/browse/CB-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-1957. --- Resolution: Fixed Glad to hear it! Marking as closed again then. InAppBrowser - video/audio does not stop playing when browser is closed --- Key: CB-1957 URL: https://issues.apache.org/jira/browse/CB-1957 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Shazron Abdullah Assignee: Andrew Grieve Fix For: 2.3.0 Attachments: video.html Repro: 1. Load a YouTube video (with audio track) in the InAppBrowser, play it 2. Close InAppBrowser Expected result: Audio stops playing Actual result: Audio continues playing The simple fix is to loadHTMLString:nil on the InAppBrowser UIWebView when the view disappears, but the real reason is probably because the UIWebView instance has not been released. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2279) Mobile-Spec does not run on Android 2.x
[ https://issues.apache.org/jira/browse/CB-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559102#comment-13559102 ] Andrew Grieve commented on CB-2279: --- This is from Braden's ArrayBuffer work, but he's out sick today. I can fix if you'd like. I think it's a one-liner in exec.js Mobile-Spec does not run on Android 2.x --- Key: CB-2279 URL: https://issues.apache.org/jira/browse/CB-2279 Project: Apache Cordova Issue Type: Bug Components: Android, CordovaJS Affects Versions: 2.4.0 Reporter: Joe Bowser Priority: Blocker Fix For: 2.4.0 This is self-explanatory. Run Mobile Spec Automatic Tests! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2235) FileTransfer spec test failing on iOS5
[ https://issues.apache.org/jira/browse/CB-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559152#comment-13559152 ] Andrew Grieve commented on CB-2235: --- Committed your one fix: https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=commit;h=9cf7235ef0db1492944913212c9abca3fd1a25f5 My guess is the the reason the three remaining tests are failing for me (on IOS5 but not 6) is white-list related. Here's my whitelist: access origin=apache.org*/ access origin=audio.ibeat.org*/ access origin=cordova-filetransfer.jitsu.com*/ access origin=whatheaders.com*/ FileTransfer spec test failing on iOS5 -- Key: CB-2235 URL: https://issues.apache.org/jira/browse/CB-2235 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Andrew Grieve Assignee: Max Woghiren Fix For: 2.4.0 I'm seeing all tests passing on iOS 6 simulator, but 4 tests failing on iOS5 simulator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2190) FileTransfer does not request more time than the 5 second limit when placed in background.
[ https://issues.apache.org/jira/browse/CB-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558248#comment-13558248 ] Andrew Grieve commented on CB-2190: --- I think what you suggests sounds good. If you're willing, please file a pull requests by following the instructions here: http://wiki.apache.org/cordova/ContributorWorkflow FileTransfer does not request more time than the 5 second limit when placed in background. -- Key: CB-2190 URL: https://issues.apache.org/jira/browse/CB-2190 Project: Apache Cordova Issue Type: Improvement Components: iOS Affects Versions: 2.2.0 Environment: iOS 6.0.1, Cordova 2.2.0. Reporter: Leif Ullman Assignee: Shazron Abdullah Attachments: CDVFileTransfer.h, CDVFileTransfer.m I've been running into an issue using FileTransfer on iOS that cropped up as part of my upgrade to Cordova 2.2. Previously I had been on PhoneGap 1.2 (a long time between upgrades I know). When using the 1.2 version, I could start a filetransfer upload (using sample code from here: http://docs.phonegap.com/en/2.2.0/cordova_media_capture_capture.md.html#Capture) and it would continue to run if I returned to the home screen or if I locked the device. Now it appears that suspending the app will cause a FileTransferError to occur with error code 3 and error message The request timed out. After trading some emails with Shazron, he pointed out that the limit to finish up background tasks is 5 seconds. If the task will take longer, the app has to request more time -- and FileTransfer does not do this currently (although the CDVLocalStorage plugin in onResignActive does: https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVLocalStorage.m#L378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CB-2271) Creating multiple CDVViewControllers at once only fires deviceready once
[ https://issues.apache.org/jira/browse/CB-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve reassigned CB-2271: - Assignee: Andrew Grieve (was: Shazron Abdullah) Creating multiple CDVViewControllers at once only fires deviceready once Key: CB-2271 URL: https://issues.apache.org/jira/browse/CB-2271 Project: Apache Cordova Issue Type: Bug Components: iOS Environment: Reproducible on iPad/iPhone 5.0 and 6.0 simulator Reporter: Mike Kwan Assignee: Andrew Grieve Fix For: 2.3.0 Steps taken to reproduce: 1. Create custom container view controller 2. In viewDidLoad add two CDVViewControllers as childViewControllers and hook up view hierarchy appropriately 3. deviceready will fire for startPage on the first CDVViewController but not for the second Workaround: Add the second CDVViewController after some delay (e.g. 1 second) Image: http://localhostr.com/9JszfWk9b7Pa More info: After some investigation, the problem seems to be a manifestation of a race condition where the address of the CDVViewController passes in the user-agent is clobbered. This means sometimes one CDVViewController will get deviceready and at other times the other one will (but never both). I believe this is another case where someone has reproduced this bug: http://stackoverflow.com/questions/13082330/phonegap-cordova-with-multiple-cdvviewcontroller Attachments (minimal example reproducing bug and workaround): http://localhostr.com/5x4AsO1oFonU -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2225) User-Agent changes in the CordovaWebView after using InAppBrowser
[ https://issues.apache.org/jira/browse/CB-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557264#comment-13557264 ] Andrew Grieve commented on CB-2225: --- Did some research with this: -Does the UA always for each PDF open, or only the first PDF load -Only the first time -Can we load pdfs in an iframe, does this trigger the bug? -PDFs *do* load in iframes, but don't trigger the bug. -Can we detect PDF loads? -They have a nil URL in their request object when webViewDidStartLoad is called, but not webViewDidFinishLoad nor shouldLoad -It's likely that we could identify a PDF in our NSURLProtocol handler, but only if we proxy the request So..., some possible Solutions: #1 - After loading first page, load a background UIWebView with a PDF (maybe even use data URL) #2 - Detect PDF load (via the nil URL), and let it load *without* changing the user-agent. - Make sure the load works by temporarily adding the URL to the container's whitelist - If the user tries to navigate anywhere else with the UIWebView, close it and make a new one - This method still messes things up if there are more than one active CDV webviews #3 - Block all PDF loads - Not sure this is easy to do without proxying every request, which has other side-effects I think the first option is probably the best for starters, it's possible the the UA bug is triggered from some sub-system being loaded the first time a PDF is loaded, and so doing it every time will cause the app to use more memory than it requires. Maybe we could have a user-pref that would allow the bug work-around to be disabled if they are sure that their app can't be used to navigate to a PDF, or if they don't use a whitelist anyways. User-Agent changes in the CordovaWebView after using InAppBrowser - Key: CB-2225 URL: https://issues.apache.org/jira/browse/CB-2225 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Shazron Abdullah Assignee: Andrew Grieve Fix For: 2.4.0 Attachments: www-cb-2102.zip See CB-2102. Attached www-cb-2102.zip which I tested with Cordova 2.3.0. Repro: 1. On the main index.html, touch the UserAgent button, observe that the UA has a numbered suffix (correct) 2. Touch the About link to go to the About page 3. On the About page, touch the UserAgent button, observe that the UA has a numbered suffix (correct, it's the same as in (1)) 4. Touch the English link, this will load a PDF in the InAppBrowser 5. Touch the Done button in the InAppBrowser to dismiss it 6. Now you are back to the About page, touch the UserAgent button again, and note that the UA is not the same as expected in (3) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2165) The saveToPhotoAlbum option for Camera.getPicture does not work with Cordova 2.2/Android
[
https://issues.apache.org/jira/browse/CB-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13557274#comment-13557274
]
Andrew Grieve commented on CB-2165:
---
FYI - I changed this last code last week when trying to shrink our code via
argscheck:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commitdiff;h=b9f5ebd4f6e82cd3e26997aed9065dec268f34a3
I just checked now, and my change doesn't address the case of strings being
passed in.
The API before allowed booleans or numbers, but with numbers translated
anything = 0 to false. Pretty non-standard... I didn't want to change the
logic in my refactoring though, so that's why there are number comparisons
there.
I think what we should do here is just use !!param. This is the behaviour
browser APIs have. This would be the string false would be interpreted as
true, but that's what browsers do.
The saveToPhotoAlbum option for Camera.getPicture does not work with
Cordova 2.2/Android
--
Key: CB-2165
URL: https://issues.apache.org/jira/browse/CB-2165
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS
Affects Versions: 2.2.0
Environment: Cordova 2.2, Android 2.3.4
Reporter: Thomas Dinger
Assignee: Simon MacDonald
Priority: Minor
The following JS call results in a call to the success function when the
picture is taken, but the picture is not added to the photo library.
01-08 09:27:53.470: D/CordovaLog(4089): getPicture() {
01-08 09:27:53.470: D/CordovaLog(4089): targetHeight: 600,
01-08 09:27:53.470: D/CordovaLog(4089): targetWidth: 600,
01-08 09:27:53.470: D/CordovaLog(4089): saveToPhotoAlbum: true,
01-08 09:27:53.470: D/CordovaLog(4089): quality: 50,
01-08 09:27:53.470: D/CordovaLog(4089): destinationType: 1,
01-08 09:27:53.470: D/CordovaLog(4089): mediaType: 0,
01-08 09:27:53.470: D/CordovaLog(4089): encodingType: 0,
01-08 09:27:53.470: D/CordovaLog(4089): allowEdit: false,
01-08 09:27:53.470: D/CordovaLog(4089): sourceType: 1
01-08 09:27:53.470: D/CordovaLog(4089): }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2165) The saveToPhotoAlbum option for Camera.getPicture does not work with Cordova 2.2/Android
[
https://issues.apache.org/jira/browse/CB-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Grieve resolved CB-2165.
---
Resolution: Fixed
true will now be treated as true, but beware that false will be treated as
true as well.
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=50be7a3c5f4115fde47de2fd8226d14412ce61d2
The saveToPhotoAlbum option for Camera.getPicture does not work with
Cordova 2.2/Android
--
Key: CB-2165
URL: https://issues.apache.org/jira/browse/CB-2165
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS
Affects Versions: 2.2.0
Environment: Cordova 2.2, Android 2.3.4
Reporter: Thomas Dinger
Assignee: Andrew Grieve
Priority: Minor
The following JS call results in a call to the success function when the
picture is taken, but the picture is not added to the photo library.
01-08 09:27:53.470: D/CordovaLog(4089): getPicture() {
01-08 09:27:53.470: D/CordovaLog(4089): targetHeight: 600,
01-08 09:27:53.470: D/CordovaLog(4089): targetWidth: 600,
01-08 09:27:53.470: D/CordovaLog(4089): saveToPhotoAlbum: true,
01-08 09:27:53.470: D/CordovaLog(4089): quality: 50,
01-08 09:27:53.470: D/CordovaLog(4089): destinationType: 1,
01-08 09:27:53.470: D/CordovaLog(4089): mediaType: 0,
01-08 09:27:53.470: D/CordovaLog(4089): encodingType: 0,
01-08 09:27:53.470: D/CordovaLog(4089): allowEdit: false,
01-08 09:27:53.470: D/CordovaLog(4089): sourceType: 1
01-08 09:27:53.470: D/CordovaLog(4089): }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2225) User-Agent changes in the CordovaWebView after using InAppBrowser
[ https://issues.apache.org/jira/browse/CB-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-2225. --- Resolution: Fixed I went with option #2 for now. Fix commit: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=07a223ee65add7e5e6ff108a77fbc684dad79914 There's some notes in CDVInAppBrowser about the work-around. Here they are: This work-around makes the following assumptions: 1. The app has only a single Cordova Webview. If not, then the app should take it upon themselves to load a PDF in the background as a part of their start-up flow. 2. That the PDF does not require any additional network requests. We change the user-agent here back to that of the CDVViewController, so requests from it must pass through its white-list. This *does* break PDFs that contain links to other remote PDF/websites. User-Agent changes in the CordovaWebView after using InAppBrowser - Key: CB-2225 URL: https://issues.apache.org/jira/browse/CB-2225 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Shazron Abdullah Assignee: Andrew Grieve Fix For: 2.4.0 Attachments: www-cb-2102.zip See CB-2102. Attached www-cb-2102.zip which I tested with Cordova 2.3.0. Repro: 1. On the main index.html, touch the UserAgent button, observe that the UA has a numbered suffix (correct) 2. Touch the About link to go to the About page 3. On the About page, touch the UserAgent button, observe that the UA has a numbered suffix (correct, it's the same as in (1)) 4. Touch the English link, this will load a PDF in the InAppBrowser 5. Touch the Done button in the InAppBrowser to dismiss it 6. Now you are back to the About page, touch the UserAgent button again, and note that the UA is not the same as expected in (3) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CB-1957) InAppBrowser - video/audio does not stop playing when browser is closed
[
https://issues.apache.org/jira/browse/CB-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Grieve reopened CB-1957:
---
Assignee: Andrew Grieve (was: Shazron Abdullah)
Yep, let's just re-open. That said - I made a change today to release the
webview when it closes, so that has a chance of fixing this:
https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=blobdiff;f=CordovaLib/Classes/CDVInAppBrowser.m;h=3e1beeae09ffc73a558023662df54fcd22347db7;hp=6c87d45dff6f570d4c2e397f7f19d124e9292202;hb=07a223ee65add7e5e6ff108a77fbc684dad79914;hpb=92fa3e4538f7d96117c507dfb89c4e5d388ec6dd
Maybe you could try and see if this fixes the problem? I'll paste here for you:
- (void)browserExit
{
if (self.callbackId != nil) {
CDVPluginResult* pluginResult = [CDVPluginResult
resultWithStatus:CDVCommandStatus_OK
messageAsDictionary:@
{@type:@exit}];
[pluginResult setKeepCallback:[NSNumber numberWithBool:YES]];
[self.commandDelegate sendPluginResult:pluginResult
callbackId:self.callbackId];
}
/// THIS IS THE NEW PART ///
// Don't recycle the ViewController since it may be consuming a lot of
memory.
// Also - this is required for the PDF/User-Agent bug work-around.
self.inAppBrowserViewController = nil;
}
InAppBrowser - video/audio does not stop playing when browser is closed
---
Key: CB-1957
URL: https://issues.apache.org/jira/browse/CB-1957
Project: Apache Cordova
Issue Type: Bug
Components: iOS
Reporter: Shazron Abdullah
Assignee: Andrew Grieve
Fix For: 2.3.0
Attachments: video.html
Repro:
1. Load a YouTube video (with audio track) in the InAppBrowser, play it
2. Close InAppBrowser
Expected result:
Audio stops playing
Actual result:
Audio continues playing
The simple fix is to loadHTMLString:nil on the InAppBrowser UIWebView when
the view disappears, but the real reason is probably because the UIWebView
instance has not been released.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2208) MobileSpec File tests Crash on Android 4.0.3 intel Emulator
[ https://issues.apache.org/jira/browse/CB-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-2208. --- Resolution: Fixed Added in the try/catch. https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=0311f0db38849bf1e61f1ae721ba2c52521bdd71 MobileSpec File tests Crash on Android 4.0.3 intel Emulator --- Key: CB-2208 URL: https://issues.apache.org/jira/browse/CB-2208 Project: Apache Cordova Issue Type: Bug Components: Android Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.4.0 01-11 14:34:23.028: I/dalvikvm(1465): java.lang.UnsupportedOperationException: Unknown URI: content://media/external/images/media match: 1 01-11 14:34:23.028: I/dalvikvm(1465): at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:168) 01-11 14:34:23.028: I/dalvikvm(1465): at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:136) 01-11 14:34:23.028: I/dalvikvm(1465): at android.content.ContentProviderProxy.delete(ContentProviderNative.java:479) 01-11 14:34:23.028: I/dalvikvm(1465): at android.content.ContentResolver.delete(ContentResolver.java:822) 01-11 14:34:23.028: I/dalvikvm(1465): at org.apache.cordova.FileUtils.notifyDelete(FileUtils.java:242) 01-11 14:34:23.028: I/dalvikvm(1465): at org.apache.cordova.FileUtils.execute(FileUtils.java:186) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2086) Invoke default android file picker for html file input
[ https://issues.apache.org/jira/browse/CB-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13556830#comment-13556830 ] Andrew Grieve commented on CB-2086: --- Looks like there is now a third parameter. Probably just need to add it. http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.1.1_r1/android/webkit/WebChromeClient.java#WebChromeClient Invoke default android file picker for html file input -- Key: CB-2086 URL: https://issues.apache.org/jira/browse/CB-2086 Project: Apache Cordova Issue Type: Wish Components: Android Affects Versions: 2.2.0 Reporter: Mark Dineen Assignee: Andrew Grieve Fix For: 2.4.0 PhoneGap build currently doesn't invoke the Android file picker when a input[type=file] is clicked. This behaviour can (apparently) be overridden with some code changes in Cordova itself. http://tmkmobile.wordpress.com/2012/0... http://stackoverflow.com/questions/59... Can this be introduced? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-2227) Move mapping of module-symbol into individual plugins
Andrew Grieve created CB-2227:
-
Summary: Move mapping of module-symbol into individual plugins
Key: CB-2227
URL: https://issues.apache.org/jira/browse/CB-2227
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.4.0
Goals:
- Change from listing module-symbol mapping within common.js platform.js, to
listing this within the plugins themselves.
- Support apps that don't want us to clobber global symbols.
aka, allow module-symbol mapping to be turned off
- Allow retrieval of clobbered globals
- Currently modules save it themselves when they are loaded
- This won't work (reliably) for saving references to globals overridden by
other modules
- This gets in the way of the idea of lazy-loading modules via getters
- Support the use of other module loaders
- So... don't do crazy things at require() time.
Requirements:
Plugins must be able to declare dependencies
Plugins must be able to delay onDeviceReady()
Plugins must be able to run code to initialize
Implementation
modulemapper.js:
clobbers(...)
merges(...)
defaults(...)
mapModules(wnd)
getOriginalSymbol('FileSystem')
Start-up flow:
Parse all modules
common-bootstrap:
Loads list of modules named cordova.*/symbols
Run modulemapper.mapModules(window);
Loads list of modules named cordova.*/main
symbols.js files:
Will make calls to modulemapper instead of exporting {clobbers:}
This make dependencies work by require()ing dependent symbols
We want the to be an evaluated .js file instead of something listed in
plugin.xml
So that it can export based on browser version
Implementation Steps
1. - Expose list of registered modules in scripts/require.js so that we can
loop over them
2. - Write modulemapper.js (and have unit tests, of course)
3. - Add logic to bootstrap.js that calls into modulemapper
create $PLUGIN_NAME/symbols.js files for each plugin within cordova.
4. - Add logic to bootstrap.js that calls into modulemapper
5. - Create main.js files for those that currently have logic in their
platform.js files
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-2228) Add a command that prepares platform directories, but then doesn't call their build scripts
Andrew Grieve created CB-2228: - Summary: Add a command that prepares platform directories, but then doesn't call their build scripts Key: CB-2228 URL: https://issues.apache.org/jira/browse/CB-2228 Project: Apache Cordova Issue Type: New Feature Components: CLI Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Often it's useful to be able to prepare the platform directories but not build right away. For example, if you want to build via Xcode, or when hacking on CLI just want to see what its doing. Names: cordova prepare ios or cordova stage ios or cordova prebuild ios -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2094) Cordova 2.3.0 not reliably firing deviceready after reload of local files
[ https://issues.apache.org/jira/browse/CB-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-2094. --- Resolution: Fixed Assignee: Andrew Grieve (was: Shazron Abdullah) I think this fixes it: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=ba7edf04ba6403588ba22995c0b9b62d58ceeca8 Please feel free to try out this patch on your local cordova.ios.js version to see if it fixes it for you. I tested by navigating around the mobile spec until it got into the state where deviceready wasn't being fired. Before this change it took a couple of minutes of navigating around, after the change I couldn't repro the bug. When stepping through, I did confirm that the XHR was being sent in JS, but never received in the bridge code. So my assumption is that the browser was trying to be smart and serving a cached result. Cordova 2.3.0 not reliably firing deviceready after reload of local files - Key: CB-2094 URL: https://issues.apache.org/jira/browse/CB-2094 Project: Apache Cordova Issue Type: Bug Components: CordovaJS, iOS Affects Versions: 2.3.0 Reporter: Bob Moore Assignee: Andrew Grieve Labels: Cordova, deviceready, iOS6 Fix For: 2.4.0 Attachments: index.html, MainViewController.h, MainViewController.m, MainViewController.xib I've added a semi transparent home button to the MainViewController which loads the local index.html file within my Cordova 2.30 project. After I've moved on to a remote page, (may be Cordova enabled, may not) and I return with the home button, sometimes deviceready does not fire. It may fire a few times then stop. Once it stops the only way to fix the issue is to send the app to the background (deviceready will now fire) and return. This same technique works fine in Cordova 2.20 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1978) Cordova 2.2 iOS does not work with RequireJS
[ https://issues.apache.org/jira/browse/CB-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-1978. --- Resolution: Fixed Okay, thanks for being patient with us! I've added a test to our suite and fixed the problem for real. If anyone wants to patch their existing 2.3 code to fix the problem, you can change: [self.commandDelegate evalJs:nativeReady]; to: [self.webView stringByEvaluatingJavaScriptFromString:nativeReady]; within: CDVViewController.m - (void)webViewDidFinishLoad:(UIWebView*)theWebView iOS Change: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=fc45dde676274228867949d11359165b5ab22017 Mobile-Spec: https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=commit;h=794d58346a4d72d3215ee3c32c51c70b56b7c1ef Cordova 2.2 iOS does not work with RequireJS Key: CB-1978 URL: https://issues.apache.org/jira/browse/CB-1978 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.1.0, 2.2.0 Environment: Use RequireJS to loading cordova.js http://requirejs.org/ Reporter: Kenichi Yonekawa Assignee: Andrew Grieve Priority: Minor Fix For: Master Attachments: www.tar.gz Cordova does not fire `deviceready` when using RequireJS to loading cordova.js Because, cordova-ios accesses `window.cordova` object at `webViewDidFinishLoad` However, window.cordova is undefined. It occurs JavaScript error. I create monkey patch for my project. it works for me. https://gist.github.com/4159669 So, cordova-2.1.0 has same problem. My monkey patch is here. https://gist.github.com/3824310 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CB-1978) Cordova 2.2 iOS does not work with RequireJS
[ https://issues.apache.org/jira/browse/CB-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve reopened CB-1978: --- Thanks for bringing this to our attention. I'll have a look into it. Would it be possible to upload a hello-world style zip of a project that uses require-js to do the loading? Cordova 2.2 iOS does not work with RequireJS Key: CB-1978 URL: https://issues.apache.org/jira/browse/CB-1978 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.1.0, 2.2.0 Environment: Use RequireJS to loading cordova.js http://requirejs.org/ Reporter: Kenichi Yonekawa Assignee: Andrew Grieve Priority: Minor Fix For: Master Cordova does not fire `deviceready` when using RequireJS to loading cordova.js Because, cordova-ios accesses `window.cordova` object at `webViewDidFinishLoad` However, window.cordova is undefined. It occurs JavaScript error. I create monkey patch for my project. it works for me. https://gist.github.com/4159669 So, cordova-2.1.0 has same problem. My monkey patch is here. https://gist.github.com/3824310 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-2214) Refactor JS files to be more ready to move into their own repositories
Andrew Grieve created CB-2214: - Summary: Refactor JS files to be more ready to move into their own repositories Key: CB-2214 URL: https://issues.apache.org/jira/browse/CB-2214 Project: Apache Cordova Issue Type: Bug Components: CordovaJS Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.4.0 Refer to ML discussion: http://callback.markmail.org/thread/xnhpidbnxg5ps7zr This task is specifically to move files around. Instead of having : lib/$PLATFORM/plugin We will have: plugin/PLUGIN_NAME/PLATFORM Changing of common.js / platform.js is *not* a part of this issue, but instead will be a follow-up (requires more thought) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2213) Add support for native URIs
[ https://issues.apache.org/jira/browse/CB-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553049#comment-13553049 ] Andrew Grieve commented on CB-2213: --- Joe - Wouldn't this map to content:// URIs on Android? Or do we have the ability to convert from content:// to file:// URLs? Never really worked with them on Android... Add support for native URIs --- Key: CB-2213 URL: https://issues.apache.org/jira/browse/CB-2213 Project: Apache Cordova Issue Type: New Feature Components: Android, CordovaJS, iOS Reporter: Max Woghiren Assignee: Max Woghiren Priority: Minor It would be useful to add the ability to access files directly from a device's photo/video library. To do this, support for native URIs is necessary—for instance, iOS's assets-library:// scheme. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse
[ https://issues.apache.org/jira/browse/CB-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-2183. --- Resolution: Fixed Assignee: Andrew Grieve (was: Shazron Abdullah) iOS fix: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=f4e7a2b0d4b62c1669c7ca2f8364ead92f655d55 Added spec test: https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=commit;h=1f8bd78ffc57c8e63a991bfbe393300ad38d7901 [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse -- Key: CB-2183 URL: https://issues.apache.org/jira/browse/CB-2183 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.2.0 Environment: Tested on iOS 5.1 and 6.0 Reporter: William Wong Assignee: Andrew Grieve Priority: Minor Labels: File, FileTransfer Fix For: 2.4.0 When FileTransfer.download() is downloading a file from file:///, NSURLConnection did not return with NSHTTPURLResponse. This will fail for apps that copy files from www/, e.g. apps that initialize its database from a pre-built cache packaged in IPA. In CB-1600 (fixed in 2.2.0), the fix assumes all response must be NSHTTPURLResponse. So when FileTransfer.download() is downloading from a file:/// URL (e.g. copying file from www/ folder to Documents/), FileTransfer assumed the download operation failed and returned 403. Tested if we comment out CB-1600, downloading from file:/// works again. We need to find out a better fix instead of commenting out CB-1600. According to http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html#//apple_ref/doc/uid/1165i, URL of file:/// is supported. You can test FileTransfer.download() by calling it with encodeURI(document.location.href) as the source parameter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-2206) Cordova's FileReader breaks when used with a Blob
Andrew Grieve created CB-2206:
-
Summary: Cordova's FileReader breaks when used with a Blob
Key: CB-2206
URL: https://issues.apache.org/jira/browse/CB-2206
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS
Affects Versions: 2.3.0
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.4.0
The follow code doesn't work as expected, and on iOS causes the app to crash.
var blob = new Blob([new DataView(buf)]);
var f = new FileReader();
f.onload = function(e) {
callback(e.target.result);
};
f.readAsText(blob);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1892) Refactor type-checking code in plugins into a helper method
[
https://issues.apache.org/jira/browse/CB-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Grieve resolved CB-1892.
---
Resolution: Fixed
Some commits ending with:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=790e28572ec70d2956f24c48591ed681ddec5eaf
This applies argscheck to all files that already have type-checking in them
(and so reduces code size).
I'd like to not go overboard with this, so am marking as fixed and do not
intend to introduce it anywhere else.
Refactor type-checking code in plugins into a helper method
---
Key: CB-1892
URL: https://issues.apache.org/jira/browse/CB-1892
Project: Apache Cordova
Issue Type: Improvement
Components: CordovaJS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.4.0
ML Discussion: http://callback.markmail.org/thread/4vgze66wlaaxthsd
The idea is to add a typecheck module along the lines of:
argscheck.checkArgs('noasdf', 'testFunc', arguments);
where n=number, o=object, a=array, s=string, d=date, f=function, *=anything
Side-effects of this change will include:
1. All core plugins will have their callbacks be optional
2. Incorrect types will result in an exception thrown
3. Should reduce the size of cordova.js through removing repetitive code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse
[ https://issues.apache.org/jira/browse/CB-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551183#comment-13551183 ] Andrew Grieve commented on CB-2183: --- To be clear, I do think we should fix this. I'm also wondering though if you can accomplish what you're trying to do using the FileSystem API? [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse -- Key: CB-2183 URL: https://issues.apache.org/jira/browse/CB-2183 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.2.0 Environment: Tested on iOS 5.1 and 6.0 Reporter: William Wong Assignee: Shazron Abdullah Priority: Critical Labels: File, FileTransfer Fix For: 2.4.0 When FileTransfer.download() is downloading a file from file:///, NSURLConnection did not return with NSHTTPURLResponse. This will fail for apps that copy files from www/, e.g. apps that initialize its database from a pre-built cache packaged in IPA. In CB-1600 (fixed in 2.2.0), the fix assumes all response must be NSHTTPURLResponse. So when FileTransfer.download() is downloading from a file:/// URL (e.g. copying file from www/ folder to Documents/), FileTransfer assumed the download operation failed and returned 403. Tested if we comment out CB-1600, downloading from file:/// works again. We need to find out a better fix instead of commenting out CB-1600. According to http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html#//apple_ref/doc/uid/1165i, URL of file:/// is supported. You can test FileTransfer.download() by calling it with encodeURI(document.location.href) as the source parameter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-2207) Xcode sometimes does not pick up changes to www/
Andrew Grieve created CB-2207:
-
Summary: Xcode sometimes does not pick up changes to www/
Key: CB-2207
URL: https://issues.apache.org/jira/browse/CB-2207
Project: Apache Cordova
Issue Type: Bug
Components: iOS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.4.0
Pretty annoying when you make changes and click Play and your changes aren't
there. I think we can fix this by changing the project template's custom build
step from:
touch -cm ${PROJECT_DIR}/www
to:
rm -rf $BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME/www
exec cp -R www $BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME/www
Any objections?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2206) Cordova's FileReader breaks when used with a Blob
[
https://issues.apache.org/jira/browse/CB-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551221#comment-13551221
]
Andrew Grieve commented on CB-2206:
---
The iOS crash happens because of the presence of an \x01 character in the file
path. I don't think this is worth fixing.
Cordova's FileReader breaks when used with a Blob
-
Key: CB-2206
URL: https://issues.apache.org/jira/browse/CB-2206
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS
Affects Versions: 2.3.0
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.4.0
The follow code doesn't work as expected, and on iOS causes the app to crash.
var blob = new Blob([new DataView(buf)]);
var f = new FileReader();
f.onload = function(e) {
callback(e.target.result);
};
f.readAsText(blob);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CB-2168) HTML Escaping on iOS FileReader may be unnecessary
[ https://issues.apache.org/jira/browse/CB-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve reassigned CB-2168: - Assignee: Andrew Grieve (was: Braden Shepherdson) HTML Escaping on iOS FileReader may be unnecessary -- Key: CB-2168 URL: https://issues.apache.org/jira/browse/CB-2168 Project: Apache Cordova Issue Type: Sub-task Components: iOS Affects Versions: 2.3.0 Reporter: Braden Shepherdson Assignee: Andrew Grieve Priority: Minor Fix For: 2.4.0 The iOS FileReader's readAsText handler encodes the result with HTML percent escapes, and the iOS-specific Javascript code decodes it. This platform-specific Javascript code doesn't support slicing. Either the encoding is there for a reason and I'll implement slicing for the iOS JS code, or we can remove the encoding and the unnecessary separate implementation. We need to know why that encoding was added in the first place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-2208) MobileSpec File tests Crash on Android 4.0.3 intel Emulator
Andrew Grieve created CB-2208: - Summary: MobileSpec File tests Crash on Android 4.0.3 intel Emulator Key: CB-2208 URL: https://issues.apache.org/jira/browse/CB-2208 Project: Apache Cordova Issue Type: Bug Components: Android Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.4.0 01-11 14:34:23.028: I/dalvikvm(1465): java.lang.UnsupportedOperationException: Unknown URI: content://media/external/images/media match: 1 01-11 14:34:23.028: I/dalvikvm(1465): at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:168) 01-11 14:34:23.028: I/dalvikvm(1465): at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:136) 01-11 14:34:23.028: I/dalvikvm(1465): at android.content.ContentProviderProxy.delete(ContentProviderNative.java:479) 01-11 14:34:23.028: I/dalvikvm(1465): at android.content.ContentResolver.delete(ContentResolver.java:822) 01-11 14:34:23.028: I/dalvikvm(1465): at org.apache.cordova.FileUtils.notifyDelete(FileUtils.java:242) 01-11 14:34:23.028: I/dalvikvm(1465): at org.apache.cordova.FileUtils.execute(FileUtils.java:186) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2208) MobileSpec File tests Crash on Android 4.0.3 intel Emulator
[ https://issues.apache.org/jira/browse/CB-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551463#comment-13551463 ] Andrew Grieve commented on CB-2208: --- I could just add a try/catch around it in FileUtils.notifyDelete(). I'm not too sure of what this is trying to do though, so not sure if that's the best fix. MobileSpec File tests Crash on Android 4.0.3 intel Emulator --- Key: CB-2208 URL: https://issues.apache.org/jira/browse/CB-2208 Project: Apache Cordova Issue Type: Bug Components: Android Reporter: Andrew Grieve Assignee: Andrew Grieve Priority: Minor Fix For: 2.4.0 01-11 14:34:23.028: I/dalvikvm(1465): java.lang.UnsupportedOperationException: Unknown URI: content://media/external/images/media match: 1 01-11 14:34:23.028: I/dalvikvm(1465): at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:168) 01-11 14:34:23.028: I/dalvikvm(1465): at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:136) 01-11 14:34:23.028: I/dalvikvm(1465): at android.content.ContentProviderProxy.delete(ContentProviderNative.java:479) 01-11 14:34:23.028: I/dalvikvm(1465): at android.content.ContentResolver.delete(ContentResolver.java:822) 01-11 14:34:23.028: I/dalvikvm(1465): at org.apache.cordova.FileUtils.notifyDelete(FileUtils.java:242) 01-11 14:34:23.028: I/dalvikvm(1465): at org.apache.cordova.FileUtils.execute(FileUtils.java:186) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2102) InAppBrowser will not open PDFs on different pages
[ https://issues.apache.org/jira/browse/CB-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551785#comment-13551785 ] Andrew Grieve commented on CB-2102: --- Does your main page reload at any point? The bridge caches the number in the brackets on the first call to exec(), so even if the UA changed afterwards I wouldn't expect the bridge to stop working. InAppBrowser will not open PDFs on different pages -- Key: CB-2102 URL: https://issues.apache.org/jira/browse/CB-2102 Project: Apache Cordova Issue Type: Bug Components: CordovaJS, iOS Affects Versions: 2.3.0 Environment: OSX Mountain Lion, xCode 4.5.2, happens on iPad simulator 5.0, 5.1, 6.0. Reporter: Chad Crowell Assignee: Shazron Abdullah Labels: InAppBrowser, iOS6 Fix For: 2.3.0 Attachments: cdv230 copy.zip, www-cb-2102.zip WWW folder is here: https://dl.dropbox.com/u/119908/www.zip The folder structure here is setup exactly like the much more elaborate website we are wrapping in Cordova as an offline website browser app for my client. This stripped down version exhibits the same problematic behavior. Whichever page you view first, the PDFs on that page open in IAB just fine. Click over to the other page and the PDFs there don't open in IAB. Doesn't matter which page you go to first, the other page always doesn't work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2175) Android build scripts fail when project path contains spaces
[ https://issues.apache.org/jira/browse/CB-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13548508#comment-13548508 ] Andrew Grieve commented on CB-2175: --- Looks like this might be fixed in the 2.3 release. Android build scripts fail when project path contains spaces - Key: CB-2175 URL: https://issues.apache.org/jira/browse/CB-2175 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.2.0 Environment: Mac os Reporter: Adalbert Wysocki Assignee: Joe Bowser Original Estimate: 1h Remaining Estimate: 1h When the project is located in a path with spaces, the clean/debug... cordova build scripts are failing. Fix: double quote paths: clean (L24): bash $CORDOVA_PATH/cordova clean = bash $CORDOVA_PATH/cordova clean cordova (L102) (cd $PROJECT_PATH $1) = (cd $PROJECT_PATH $1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1495) iOS default splash screen images take up several megabytes
[ https://issues.apache.org/jira/browse/CB-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13549297#comment-13549297 ] Andrew Grieve commented on CB-1495: --- Also ran them through ImageOptim. Shrank them by 15% https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=deabeeb6fcb35bac9360b053c8bf902b45e6de4d iOS default splash screen images take up several megabytes -- Key: CB-1495 URL: https://issues.apache.org/jira/browse/CB-1495 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.0.0 Environment: iOS, XCode 4.5, Cordova 2.0.0 Reporter: Brion Vibber Assignee: Shazron Abdullah Priority: Minor Labels: splashscreen Fix For: 2.4.0 Attachments: crushed.zip The default splash screen images for iOS are quite large; the Retina iPad images are 1.5 megabytes for each orientation! $ ls -lh total 8680 -rw-r--r-- 1 brion staff 1.5M Sep 17 15:18 Default-Landscape@2x~ipad.png -rw-r--r-- 1 brion staff 413K Sep 17 15:18 Default-Landscape~ipad.png -rw-r--r-- 1 brion staff 1.5M Sep 17 15:18 Default-Portrait@2x~ipad.png -rw-r--r-- 1 brion staff 412K Sep 17 15:18 Default-Portrait~ipad.png -rw-r--r-- 1 brion staff 342K Sep 17 15:18 Default@2x~iphone.png -rw-r--r-- 1 brion staff92K Sep 17 15:18 Default~iphone.png They should probably be recompressed to be a bit smaller; the gradients in the background may be at issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2160) cordova_plist_to_config_xml fails inexplicably
[ https://issues.apache.org/jira/browse/CB-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-2160. --- Resolution: Fixed The problem was that you had a binary plist instead of a text one. I fixed the script to handle this: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=b4c2ca3056bcf72a2717d8c7b34ec91ea25cc644 Do you recall if you did something special to make yours in binary format? Wondering if we should post this as a known-issue somewhere if this is going to be a common thing. The fix is to run this on the file first: plutil -convert xml1 Cordova.plist cordova_plist_to_config_xml fails inexplicably -- Key: CB-2160 URL: https://issues.apache.org/jira/browse/CB-2160 Project: Apache Cordova Issue Type: Bug Components: Docs, iOS Affects Versions: 2.3.0 Environment: 2.3.0 Reporter: Jesse MacFadyen Assignee: Andrew Grieve Attachments: Cordova.plist Issue CB-1893 has apparently made it so you can update the plist to xml, however the documentation is non-existent, and amounts to the following 1 line in the upgrade guide. 10. Convert your Cordova.plist file to config.xml, by running the script bin/cordova_plist_to_config_xml on your project file. Here is what I get ... jessem-MacBookPro:ios jessem$ ./bin/cordova_plist_to_config_xml /Repos/RisingJ/BetaGap/Generic/HyperLab.xcodeproj Converting /Repos/RisingJ/BetaGap/Generic/Cordova.plist to /Repos/RisingJ/BetaGap/Generic/config.xml. Traceback (most recent call last): File ./bin/cordova_plist_to_config_xml, line 125, in module main(sys.argv[1:]) File ./bin/cordova_plist_to_config_xml, line 115, in main ConvertPlist(plist_file, config_file) File ./bin/cordova_plist_to_config_xml, line 76, in ConvertPlist plist = plistlib.readPlist(src_path) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plistlib.py, line 78, in readPlist rootObject = p.parse(pathOrFile) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plistlib.py, line 406, in parse parser.ParseFile(fileobj) xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 9 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2102) InAppBrowser will not open PDFs on different pages
[ https://issues.apache.org/jira/browse/CB-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13547533#comment-13547533 ] Andrew Grieve commented on CB-2102: --- I tried to reproduce this today on the iOS 6 simulator, but never saw the User-Agent of the Cordova UIWebView change. Does this happen only on-device? Any tips on reproducing the broken behaviour? InAppBrowser will not open PDFs on different pages -- Key: CB-2102 URL: https://issues.apache.org/jira/browse/CB-2102 Project: Apache Cordova Issue Type: Bug Components: CordovaJS, iOS Affects Versions: 2.3.0 Environment: OSX Mountain Lion, xCode 4.5.2, happens on iPad simulator 5.0, 5.1, 6.0. Reporter: Chad Crowell Assignee: Shazron Abdullah Labels: InAppBrowser, iOS6 Fix For: 2.3.0 WWW folder is here: https://dl.dropbox.com/u/119908/www.zip The folder structure here is setup exactly like the much more elaborate website we are wrapping in Cordova as an offline website browser app for my client. This stripped down version exhibits the same problematic behavior. Whichever page you view first, the PDFs on that page open in IAB just fine. Click over to the other page and the PDFs there don't open in IAB. Doesn't matter which page you go to first, the other page always doesn't work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CB-2160) cordova_plist_to_config_xml fails inexplicably
[ https://issues.apache.org/jira/browse/CB-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve reassigned CB-2160: - Assignee: Andrew Grieve (was: Michael Brooks) cordova_plist_to_config_xml fails inexplicably -- Key: CB-2160 URL: https://issues.apache.org/jira/browse/CB-2160 Project: Apache Cordova Issue Type: Bug Components: Docs, iOS Affects Versions: 2.3.0 Environment: 2.3.0 Reporter: Jesse MacFadyen Assignee: Andrew Grieve Issue CB-1893 has apparently made it so you can update the plist to xml, however the documentation is non-existent, and amounts to the following 1 line in the upgrade guide. 10. Convert your Cordova.plist file to config.xml, by running the script bin/cordova_plist_to_config_xml on your project file. Here is what I get ... jessem-MacBookPro:ios jessem$ ./bin/cordova_plist_to_config_xml /Repos/RisingJ/BetaGap/Generic/HyperLab.xcodeproj Converting /Repos/RisingJ/BetaGap/Generic/Cordova.plist to /Repos/RisingJ/BetaGap/Generic/config.xml. Traceback (most recent call last): File ./bin/cordova_plist_to_config_xml, line 125, in module main(sys.argv[1:]) File ./bin/cordova_plist_to_config_xml, line 115, in main ConvertPlist(plist_file, config_file) File ./bin/cordova_plist_to_config_xml, line 76, in ConvertPlist plist = plistlib.readPlist(src_path) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plistlib.py, line 78, in readPlist rootObject = p.parse(pathOrFile) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plistlib.py, line 406, in parse parser.ParseFile(fileobj) xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 9 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2160) cordova_plist_to_config_xml fails inexplicably
[ https://issues.apache.org/jira/browse/CB-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13546122#comment-13546122 ] Andrew Grieve commented on CB-2160: --- Hey Jesse, can you attach your Cordova.plist file? cordova_plist_to_config_xml fails inexplicably -- Key: CB-2160 URL: https://issues.apache.org/jira/browse/CB-2160 Project: Apache Cordova Issue Type: Bug Components: Docs, iOS Affects Versions: 2.3.0 Environment: 2.3.0 Reporter: Jesse MacFadyen Assignee: Andrew Grieve Issue CB-1893 has apparently made it so you can update the plist to xml, however the documentation is non-existent, and amounts to the following 1 line in the upgrade guide. 10. Convert your Cordova.plist file to config.xml, by running the script bin/cordova_plist_to_config_xml on your project file. Here is what I get ... jessem-MacBookPro:ios jessem$ ./bin/cordova_plist_to_config_xml /Repos/RisingJ/BetaGap/Generic/HyperLab.xcodeproj Converting /Repos/RisingJ/BetaGap/Generic/Cordova.plist to /Repos/RisingJ/BetaGap/Generic/config.xml. Traceback (most recent call last): File ./bin/cordova_plist_to_config_xml, line 125, in module main(sys.argv[1:]) File ./bin/cordova_plist_to_config_xml, line 115, in main ConvertPlist(plist_file, config_file) File ./bin/cordova_plist_to_config_xml, line 76, in ConvertPlist plist = plistlib.readPlist(src_path) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plistlib.py, line 78, in readPlist rootObject = p.parse(pathOrFile) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plistlib.py, line 406, in parse parser.ParseFile(fileobj) xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 9 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1807) Android navigator.connection.type is not equal to navigator.network.connection.type
[ https://issues.apache.org/jira/browse/CB-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13543954#comment-13543954 ] Andrew Grieve commented on CB-1807: --- Just tested using the MobileSpec network test page. Turned off wifi, and it changed to none, turned on network and it changed to 4g. This was with a Galaxy Nexus. I think you're best bet is to wait for 2.3 to come out and switch fully over to it, and then file a new bug if it still isn't working right on your device. 2.3 should be release either today or early next week. Android navigator.connection.type is not equal to navigator.network.connection.type --- Key: CB-1807 URL: https://issues.apache.org/jira/browse/CB-1807 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.2.0 Reporter: Thejaswi Puthraya Assignee: Andrew Grieve Fix For: 2.3.0 Attachments: index.html As per the documentation and example navigator.connection.type is what was previously navigator.network.connection.type. Before Cordova 2.2.0, the Connection object existed at: navigator.network.connection. To match the spec, this was changed to navigator.connection in 2.2.0. navigator.network.connection still exists, but is now deprecated and will be removed in a future release. But in the file that I am enclosing to reproduce the bug, navigator.connection.type is always (irrespective of connection) 'unknown'(0) though navigator.network.connection.type returns the correct value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1807) Android navigator.connection.type is not equal to navigator.network.connection.type
[ https://issues.apache.org/jira/browse/CB-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13543193#comment-13543193 ] Andrew Grieve commented on CB-1807: --- No, it should say none in that case. Can you try this out with the 2.3.0rc2 code? It's available here: http://people.apache.org/~steven/ Android navigator.connection.type is not equal to navigator.network.connection.type --- Key: CB-1807 URL: https://issues.apache.org/jira/browse/CB-1807 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.2.0 Reporter: Thejaswi Puthraya Assignee: Andrew Grieve Fix For: 2.3.0 Attachments: index.html As per the documentation and example navigator.connection.type is what was previously navigator.network.connection.type. Before Cordova 2.2.0, the Connection object existed at: navigator.network.connection. To match the spec, this was changed to navigator.connection in 2.2.0. navigator.network.connection still exists, but is now deprecated and will be removed in a future release. But in the file that I am enclosing to reproduce the bug, navigator.connection.type is always (irrespective of connection) 'unknown'(0) though navigator.network.connection.type returns the correct value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1807) Android navigator.connection.type is not equal to navigator.network.connection.type
[ https://issues.apache.org/jira/browse/CB-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13543249#comment-13543249 ] Andrew Grieve commented on CB-1807: --- Okay, thanks for giving that a go. I'll test it out on my device tomorrow. I should also make sure you're not doing any navigations. There was a bug in 2.2 that if you navigate at all the connection API is busted. Fix is here: https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blobdiff;f=framework/src/org/apache/cordova/NetworkManager.java;h=af2fc7d3b4fcd330c1898d8d5792cc83f2081519;hp=5d8791809227877d604c98cf029c26242d9642b8;hb=dc459c84a36f90f2383203ceab56a47341360937;hpb=e51b4897a34c8d4430ad8036cff86f7fd95747b8 Android navigator.connection.type is not equal to navigator.network.connection.type --- Key: CB-1807 URL: https://issues.apache.org/jira/browse/CB-1807 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.2.0 Reporter: Thejaswi Puthraya Assignee: Andrew Grieve Fix For: 2.3.0 Attachments: index.html As per the documentation and example navigator.connection.type is what was previously navigator.network.connection.type. Before Cordova 2.2.0, the Connection object existed at: navigator.network.connection. To match the spec, this was changed to navigator.connection in 2.2.0. navigator.network.connection still exists, but is now deprecated and will be removed in a future release. But in the file that I am enclosing to reproduce the bug, navigator.connection.type is always (irrespective of connection) 'unknown'(0) though navigator.network.connection.type returns the correct value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2101) iOS application crashes when opening the Camera plugin (com.apple.camera.avcapturesession) more than a couple of times
[ https://issues.apache.org/jira/browse/CB-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-2101. --- Resolution: Duplicate Marking as duplicate of long-standing CB-975. If you're willing to attach a .zip of a project that reproduces this, that would be super helpful. I've so far been unable to get it to crash on any of my test devices. iOS application crashes when opening the Camera plugin (com.apple.camera.avcapturesession) more than a couple of times -- Key: CB-2101 URL: https://issues.apache.org/jira/browse/CB-2101 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.1.0, 2.2.0 Environment: iOS 6.1, Xcode 4.5, Mac OS X 10.8 Reporter: Kelvin Dart Assignee: Shazron Abdullah Priority: Critical When I call navigator.camera.getPicture, I am able to capture an image fine the first time and assign it to the src attribute of an img tag. When I open the Camera plugin a second or third time to get another image still within the same page, it crashes at the com.apple.camera.avcapturesession thread. I have recently changed from DATA_URL to FILE_URI as I originally believed the issue was down to this. However, this seems to have changed very little unfortunately. I also have a drop-down image which enables me to select the camera quality settings. These are, by default: 320x240 50% image quality 640x480 60% image quality Both times were on an iPhone 4S (8MP camera) which has quite high specs as it is. On an iPad 2, it worked with more as I was able to get up to eight images (I didn't test further than this). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2086) Invoke default android file picker for html file input
[ https://issues.apache.org/jira/browse/CB-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13535313#comment-13535313 ] Andrew Grieve commented on CB-2086: --- I think your links got truncated. Could you post them again? Invoke default android file picker for html file input -- Key: CB-2086 URL: https://issues.apache.org/jira/browse/CB-2086 Project: Apache Cordova Issue Type: Wish Components: Android Affects Versions: 2.2.0 Reporter: Mark Dineen Assignee: Simon MacDonald Priority: Minor PhoneGap build currently doesn't invoke the Android file picker when a input[type=file] is clicked. This behaviour can (apparently) be overridden with some code changes in Cordova itself. http://tmkmobile.wordpress.com/2012/0... http://stackoverflow.com/questions/59... Can this be introduced? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-2086) Invoke default android file picker for html file input
[ https://issues.apache.org/jira/browse/CB-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve updated CB-2086: -- Fix Version/s: 2.4.0 Invoke default android file picker for html file input -- Key: CB-2086 URL: https://issues.apache.org/jira/browse/CB-2086 Project: Apache Cordova Issue Type: Wish Components: Android Affects Versions: 2.2.0 Reporter: Mark Dineen Assignee: Simon MacDonald Priority: Minor Fix For: 2.4.0 PhoneGap build currently doesn't invoke the Android file picker when a input[type=file] is clicked. This behaviour can (apparently) be overridden with some code changes in Cordova itself. http://tmkmobile.wordpress.com/2012/0... http://stackoverflow.com/questions/59... Can this be introduced? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2086) Invoke default android file picker for html file input
[ https://issues.apache.org/jira/browse/CB-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13535387#comment-13535387 ] Andrew Grieve commented on CB-2086: --- (so in summary I think we should still add this in for 2.4) Invoke default android file picker for html file input -- Key: CB-2086 URL: https://issues.apache.org/jira/browse/CB-2086 Project: Apache Cordova Issue Type: Wish Components: Android Affects Versions: 2.2.0 Reporter: Mark Dineen Assignee: Simon MacDonald Priority: Minor Fix For: 2.4.0 PhoneGap build currently doesn't invoke the Android file picker when a input[type=file] is clicked. This behaviour can (apparently) be overridden with some code changes in Cordova itself. http://tmkmobile.wordpress.com/2012/0... http://stackoverflow.com/questions/59... Can this be introduced? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2058) 2 File API test failures on mobile-spec 2.3.0rc2
[ https://issues.apache.org/jira/browse/CB-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve resolved CB-2058. --- Resolution: Fixed Pulled in Shaz's fix: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=2226b097a5249be30da3f98789860296b2326c65 (don't forget to close the pull request :)) 2 File API test failures on mobile-spec 2.3.0rc2 Key: CB-2058 URL: https://issues.apache.org/jira/browse/CB-2058 Project: Apache Cordova Issue Type: Bug Components: CordovaJS, iOS, mobile-spec Affects Versions: 2.3.0 Reporter: Shazron Abdullah Assignee: Shazron Abdullah Priority: Critical Fix For: 2.3.0 1. File API read method should read file properly, File object. Expected 'There%20is%20an%20exception%20to%20every%20rule.%20%20Except%20this%20one.' to be 'There is an exception to every rule. Except this one.'. 2. File API FileWriter should write and read special characters. Expected 'H%C3%ABll%C3%B5%20Euro%20%E2%82%AC%C2%A1' to be 'Hëllõ Euro €¡'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2054) Iframe not working in Android4.0
[ https://issues.apache.org/jira/browse/CB-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13531163#comment-13531163 ] Andrew Grieve commented on CB-2054: --- Could you attach or link us to a test page that repro's this? Preferably the test page would not depend on any external libraries so that we can rule out them as a possible cause. Iframe not working in Android4.0 Key: CB-2054 URL: https://issues.apache.org/jira/browse/CB-2054 Project: Apache Cordova Issue Type: Bug Components: Android Environment: Android4.0 corodova2.1.0 Jquerymobile 1.2.0 Reporter: nathiya Assignee: Joe Bowser Labels: android, javascript, jquery, phonegap Fix For: 2.2.0 Original Estimate: 51h Remaining Estimate: 51h I am using IFrame for loading webpage .its working fine in android 2.2 but its not working in android 4.0.Input elements inside the webpage are disabled I can't able to type and click the button and then I have searched and added scrolling=no in Iframe tag.Now i can able to type in the textbox(access input elements inside the webpage in Iframe) but i can't able to scroll to the left and right of the webpage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CB-861) Header support for PhoneGap's FileTransfer (download)
[ https://issues.apache.org/jira/browse/CB-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Grieve reopened CB-861: -- How did you test this? There's no code in FileTransfer's download path for adding headers: https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=framework/src/org/apache/cordova/FileTransfer.java;h=fdc9c75dc8169ce9c9996f8c7c97d1b416a8ff06;hb=HEAD I think the status of it is that it's still not implemented. If I'm confused and it does actually work, we should add a spec test for it (there's already one that tests upload headers) Header support for PhoneGap's FileTransfer (download) - Key: CB-861 URL: https://issues.apache.org/jira/browse/CB-861 Project: Apache Cordova Issue Type: Improvement Components: Android, CordovaJS Affects Versions: 1.7.0 Reporter: Aurelien MERCIER Assignee: Andrew Grieve -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1893) Convert cordova.plist - config.xml
[ https://issues.apache.org/jira/browse/CB-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507111#comment-13507111 ] Andrew Grieve commented on CB-1893: --- Added a conversion script: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=67e93c90a708d2021075e130fc1f5c6bae888cf7 Convert cordova.plist - config.xml --- Key: CB-1893 URL: https://issues.apache.org/jira/browse/CB-1893 Project: Apache Cordova Issue Type: Improvement Components: iOS Reporter: Andrew Grieve Assignee: Braden Shepherdson Priority: Minor Fix For: 2.3.0 Relevant ML discussion: http://callback.markmail.org/thread/dulyzr4rcmudtibq Just like Android switched, iOS should also use a config.xml file that follows the same format. Bonus points for writing a script to convert a .plist - config.xml, but this is not strictly necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1893) Convert cordova.plist - config.xml
[ https://issues.apache.org/jira/browse/CB-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505521#comment-13505521 ] Andrew Grieve commented on CB-1893: --- I think supporting both was one of the things that upset users when Android made the switch (at least, it upset me). What happened was that I ended up having both files present, and the code was silently using one and not the other, and I couldn't figure out why my whitelist changes were not being picked up. I think a conversion script was also suggested. I think it would be best to just fail loudly if config.xml is missing with a message saying run this script: cordova/bin/plist2xml.py path/to/cordova.plist WDYT? Convert cordova.plist - config.xml --- Key: CB-1893 URL: https://issues.apache.org/jira/browse/CB-1893 Project: Apache Cordova Issue Type: Improvement Components: iOS Reporter: Andrew Grieve Assignee: Braden Shepherdson Priority: Minor Fix For: 2.3.0 Relevant ML discussion: http://callback.markmail.org/thread/dulyzr4rcmudtibq Just like Android switched, iOS should also use a config.xml file that follows the same format. Bonus points for writing a script to convert a .plist - config.xml, but this is not strictly necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-1931) Contact.find() docs don't match implementation for zero-length array
Andrew Grieve created CB-1931:
-
Summary: Contact.find() docs don't match implementation for
zero-length array
Key: CB-1931
URL: https://issues.apache.org/jira/browse/CB-1931
Project: Apache Cordova
Issue Type: Bug
Components: CordovaJS, Docs
Reporter: Andrew Grieve
Assignee: Filip Maj
Priority: Minor
The docs say:
http://docs.phonegap.com/en/2.2.0/cordova_contacts_contacts.md.html#contacts.find
A zero-length contactFields parameter will result in an array of Contact
objects with only the id property populated.
The code says (in contacts.js):
if (!fields || (utils.isArray(fields) fields.length === 0)) {
errorCB errorCB(new ContactError(ContactError.INVALID_ARGUMENT_ERROR));
}
I peeked at the iOS Contacts impl, and I don't think it looks for the case of
an empty array.
Maybe simplest thing is to just make the docs say that an empty array is
invalid?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1892) Refactor type-checking code in plugins into a helper method
[
https://issues.apache.org/jira/browse/CB-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13502929#comment-13502929
]
Andrew Grieve commented on CB-1892:
---
argscheck module:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=1dfa2ac54a41287279e6726d2b748060e1cc44bf
Lower-case .js plugin files:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=9ba65d4f42cddf0cdc1c1f1b624df201bde0ca18
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=f400233bef00da6d3678d95e4abf745a1f62e07f
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=58990dad50f337fd8c71250398d6586ae2b055ac
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=f81be6623d3429f442a0e214adfe3f66fff32b1f
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=4864283bcc17d37d7d28d85ffed9dc41dd3931f9
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=1fe276bcb9b36ced8be236c40886a6c0dc0a1076
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=ee4a70cce10fadd7a7563eb2941f231c9841d009
So far, 4kb off of cordova.ios.js (from 192 to 188kb)
245 insertions(+), 323 deletions(-)
This is now mostly done, but need to check if it would make sense for any of
the CamelCase.js files to use it.
Refactor type-checking code in plugins into a helper method
---
Key: CB-1892
URL: https://issues.apache.org/jira/browse/CB-1892
Project: Apache Cordova
Issue Type: Improvement
Components: CordovaJS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.3.0
ML Discussion: http://callback.markmail.org/thread/4vgze66wlaaxthsd
The idea is to add a typecheck module along the lines of:
argscheck.checkArgs('noasdf', 'testFunc', arguments);
where n=number, o=object, a=array, s=string, d=date, f=function, *=anything
Side-effects of this change will include:
1. All core plugins will have their callbacks be optional
2. Incorrect types will result in an exception thrown
3. Should reduce the size of cordova.js through removing repetitive code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
