[jira] [Commented] (CB-571) Check that audio file recording to using Media.startRecord is of type .wav

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-571:
--

I don't love android's behaviour here, because there's no way to discover the 
full path to the file you've just created. That said, if you want to keep the 
file (not have it in the cache dir), then arguably you should just use an 
absolute URL as an argument anyways.

Since this is already the behaviour on Android, I think it's too late to change 
(outside of our grand API audit). I think the equivalent on iOS would be to put 
the file in the /tmp directory. If they want to keep the 
file, or save it in the Documents directory, then they should use a full URL.



> Check that audio file recording to using Media.startRecord is of type .wav
> --
>
> Key: CB-571
> URL: https://issues.apache.org/jira/browse/CB-571
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Affects Versions: 1.6.1
> Environment: iOS
>Reporter: Ram Kulkarni
>Assignee: Becky Gibson
>Priority: Minor
>  Labels: ios, media
> Fix For: 2.5.0
>
>
> As we document in {{startRecord}} on our [docs 
> page|http://docs.phonegap.com/en/1.6.1/cordova_media_media.md.html#media.startRecord],
>  when recording audio in iOS, you need to make sure the file exists and that 
> it is of type .wav.
> It would be nice if the {{startRecordingAudio}} method in CDVSound.m checked 
> that the requested file to record to is of the right type, and throw an error 
> if it is not.

--
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

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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' ==> /Library
- 'data' && iOS && persistence == 'device_persistent' ==> 
/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' ==> 
/Documents
- 'documents' && iOS && persistence == 'device_persistent' ==> 
/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/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .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-2227) Move mapping of module->symbol into individual plugins

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2293) File Transfer of picture fails on every other picture

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=2&api_key=x&source=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(Po

[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-285:
--

Thanks for the feedback Becky!

Moving from Documents -> Library: My thought here was that it's more common to 
use it for app data than for user-generated content. Users should be able to 
understand what each file in their Documents directory is for. That's not a 
distinction that the LocalFileSystem API makes. 

Agree that a USER_DATA might make sense, but that doesn't map as well 
x-platform, and so wanted to punt on it for the first go-around. If you (or 
someone else) wants to propose something for it though, now's not a bad time to 
discuss! :)

I suggest exposing  only to avoid exposing every 
sub-directory of it as different constants. Maybe this would be better though? 
I can also imagine third-party plugins wanting to be able to chose a 
sub-directory to use for plugin-specific files that does not show up to the app 
within their PERSISTENT / TEMPORARY spaces. e.g. /tmp/my-plugin or 
/Library/my-plugin/. Exposing the root ( makes this possible.

For assets - it's not currently possible to create a FileEntry() to a file in 
the www/ directory (unless you call the constructor directly with the full 
path, which is not really a supported API). There can also be siblings of www/ 
on both iOS and Android. I figured it would be useful to expose these (through 
our non-standard additions), but I can't actually think of a reason right now 
why you'd want to. It would only make your life harder, no? Maybe instead of 
APP_ASSETS, we should just have a CORDOVA_WWW constant? wdyt? The reason we 
want to expose it via the FileSystem API even though it's read-only, is that it 
makes it enumerable.

I *think* I agree with what you said about relative paths. They should be 
treated as relative URLs, so should be relative to the html file you're 
currently on.

For CB-571, I don't know that it's safe to assume Documents directory. It could 
be the app is a shazam-like app and the sound-clip is really just temporary app 
data. The best thing would be if the apps passed in absolute URLs for where 
they want the file. According to what you (and I agree) suggest for handling 
relative URLs, passing in just a filename should resolve to a file in the www/ 
directory, and be read-only. This would be my expected behaviour if I created 
the Media object with the intention of calling .play() on it.


> 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/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .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-2226) FileTransfer.abort -- successfully aborting actually calls the error callback. Nothing ever gets called for the success callback.

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (CB-285) Add property returning root path of PhoneGap files

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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. 


The other locations are all subdirectories of , 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 /Documents --> 
/Library/CdvPersistentStorage
 2. TEMPORARY changes from /tmp --> 
/tmp/CdvTemporaryStorage
 3. APP_ASSETS --> Application bundle
 4. APP_DATA --> 

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. 


The other locations are all subdirectories of , 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 /Documents --> 
/Library/CdvPersistentStorage
 2. TEMPORARY changes from /tmp --> 
/tmp/CdvTemporaryStorage
 3. APP_ASSETS --> Application bundle
 4. APP_DATA --> 

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_

[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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. 


The other locations are all subdirectories of , 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 /Documents --> 
/Library/CdvPersistentStorage
 2. TEMPORARY changes from /tmp --> 
/tmp/CdvTemporaryStorage
 3. APP_ASSETS --> Application bundle
 4. APP_DATA --> 

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/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .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 wa

[jira] [Resolved] (CB-1701) FileTransfer response UTF-8 Bug

[Andrew Grieve (JIRA)]

 [ 
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-2293) File Transfer of picture fails on every other picture

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=2&api_key=x&source=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 Me

[jira] [Commented] (CB-2226) FileTransfer.abort -- successfully aborting actually calls the error callback. Nothing ever gets called for the success callback.

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-2226:
---

What's is the suggested fix? Is there a use-case for having abort callbacks? 
maybe we should just delete the callbacks.

> 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

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=2&api_key=x&source=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 
> libcor

[jira] [Commented] (CB-2293) File Transfer of picture fails on every other picture

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=2&api_key=x&source=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 1

[jira] [Commented] (CB-2214) Refactor JS files to be more ready to move into their own repositories

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (CB-2239) Support returning multiple plugin-result values from native->js

[Andrew Grieve (JIRA)]

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

Andrew Grieve updated CB-2239:
--

Fix Version/s: 2.5.0

> Support returning multiple plugin-result values from native->js
> ---
>
> Key: CB-2239
> URL: https://issues.apache.org/jira/browse/CB-2239
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Android, iOS
>Affects Versions: 2.3.0
>Reporter: Michal Mocny
>Assignee: Michal Mocny
>Priority: Minor
> Fix For: 2.5.0
>
>
> Currently, on both Android and iOS, we support calling a plugin with multiple 
> arguments, but only support a single return value.
> If all your return values are json serializable, you can construct a json 
> array or dictionary and return that, and that has gotten us this far.
> However, we have recently added support for sending ArrayBuffers, which are 
> not json serializable.  Some plugins require returning data along with an 
> ArrayBuffer result (such as a success indicator).
> We propose adding a new return type to CDVPluginResult (ios) and to 
> PluginResult (android) which is some multi-value container, semantically a 
> list of PluginResult.  The types this container supports are the same as we 
> have supported until now, and the current PluginResults implementations can 
> be written in terms-of a list of size 1 so as to support the common case 
> while not diverging implementations.

--
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/

[Andrew Grieve (JIRA)]

 [ 
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] [Updated] (CB-1518) FileTransfer.download progress events has this.lengthComputable = false when response is gzipped on iOS

[Andrew Grieve (JIRA)]

 [ 
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

[Andrew Grieve (JIRA)]

 [ 
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-2180) Convert iOS project template to use ARC

[Andrew Grieve (JIRA)]

 [ 
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-2180) Convert iOS project template to use ARC

[Andrew Grieve (JIRA)]

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

Andrew Grieve updated CB-2180:
--

Fix Version/s: (was: 2.4.0)
   3.0.0

> 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: 3.0.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.

[Andrew Grieve (JIRA)]

 [ 
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] [Resolved] (CB-1793) Fix Objective-C unit tests

[Andrew Grieve (JIRA)]

 [ 
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

[jira] [Updated] (CB-2275) Explicitly initialize NSURLCache in the project template

[Andrew Grieve (JIRA)]

 [ 
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-2276) Refactor to eliminate casts of viewControlled -> CDVViewController

[Andrew Grieve (JIRA)]

 [ 
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-2285) No more activities from Cordova

[Andrew Grieve (JIRA)]

 [ 
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] [Commented] (CB-2293) File Tranfer of picture fails on every other picture

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=2&api_key=x&source=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.BlockGuard

[jira] [Commented] (CB-2293) File Tranfer of picture fails on every other picture

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=2&api_key=x&source=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/res

[jira] [Commented] (CB-2227) Move mapping of module->symbol into individual plugins

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-2293:
---

Okay, did submit the one bugfix anyways:

https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=2e20bb063933a5cc27ae95b0ec70c59c5b9ae3b9

Also added a log statement so that we'll know how much of the file was uploaded 
when the exception happens. From your stack trace, it looks like it happens 
after the file has finished uploading and it's reading the response headers.

I don't suppose you have any server logs that indicate what the error might be? 
I *think* what's happening is that server is closing the connection on us.

> 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=2&api_key=x&source=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/Fi

[jira] [Created] (CB-2306) FileTransfer.download does not support file:/// URLs on Android

[Andrew Grieve (JIRA)]

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] [Created] (CB-2305) Add InAppBrowser.executeScript() / InAppBrowser.insertCSS API

[Andrew Grieve (JIRA)]

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] [Commented] (CB-2301) EXC_BAD_ACCESS on resume/wake on iOS device

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2293) File Tranfer of picture fails on every other picture

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=2&api_key=x&source=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/

[jira] [Updated] (CB-2293) File Tranfer of picture fails on every other picture

[Andrew Grieve (JIRA)]

 [ 
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=2&api_key=x&source=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=2&api_key=x

[jira] [Commented] (CB-2184) JNI Error on HTC Evo device running android 4.0.3

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-2184:
---

One stab-in-the-dark would be to see if commenting out the 
addJavaScriptInterface call helps at all:

https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=framework/src/org/apache/cordova/CordovaWebView.java;h=44c9299a5899ca61c773d7fd77d0ae4e9e8b7b03;hb=HEAD#l314

> JNI Error on HTC Evo device running android 4.0.3
> -
>
> Key: CB-2184
> URL: https://issues.apache.org/jira/browse/CB-2184
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Android 4.0.3 on HTC Evo device
>Reporter: besta
>Assignee: Joe Bowser
>
> My app uses Cordova to implement the business logic in JS. So there is a 
> single activity that loads a webview and afterwards some fragments to provide 
> native UI elements.
> Running the app on an Android 2.2 emulator works fine. But trying the app on 
> my HTC Evo device leads to the following error:
> 01-04 17:58:11.537: E/dalvikvm(5451): JNI ERROR (app bug): attempt to use 
> stale local reference 0x1
> 01-04 17:58:11.537: E/dalvikvm(5451): VM aborting
> 01-04 17:58:11.537: A/libc(5451): Fatal signal 11 (SIGSEGV) at 0xdeadd00d 
> (code=1)
> 01-04 17:58:11.967: I/DEBUG(5047): debuggerd: 2013-01-04 17:58:11
> 01-04 17:58:11.967: I/DEBUG(5047): *** *** *** *** *** *** *** *** *** *** 
> *** *** *** *** *** ***
> 01-04 17:58:11.967: I/DEBUG(5047): Build fingerprint: 
> 'htc_europe/htc_shooteru/shooteru:4.0.3/IML74K/385730.1:user/release-keys'
> 01-04 17:58:11.967: I/DEBUG(5047): pid: 5451, tid: 5531  >>> 
> eu.mobilion.wasserfinder <<<
> 01-04 17:58:11.967: I/DEBUG(5047): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), 
> fault addr deadd00d
> 01-04 17:58:11.967: I/DEBUG(5047):  r0   r1 00c34d48  r2   r3 
> 
> 01-04 17:58:11.967: I/DEBUG(5047):  r4 deadd00d  r5 40950ce8  r6 020c  r7 
> 52131900
> 01-04 17:58:11.967: I/DEBUG(5047):  r8 01320c50  r9 2765  10 000c  fp 
> 0127c3d0
> 01-04 17:58:11.967: I/DEBUG(5047):  ip   sp 52131650  lr 408e82db  pc 
> 408e82da  cpsr 6030
> 01-04 17:58:11.967: I/DEBUG(5047):  d0    d1  
> ...
> 01-04 17:58:11.977: I/DEBUG(5047):  d30   d31 3ff0
> 01-04 17:58:11.977: I/DEBUG(5047):  scr 6013
> 01-04 17:58:12.247: I/DEBUG(5047):  #00  pc 000512da  
> /system/lib/libdvm.so (dvmAbort)
> 01-04 17:58:12.247: I/DEBUG(5047):  #01  pc 000326b8  
> /system/lib/libdvm.so (_ZNK16IndirectRefTable3getEPv)
> 01-04 17:58:12.247: I/DEBUG(5047):  #02  pc 00055ea4  
> /system/lib/libdvm.so (_Z20dvmDecodeIndirectRefP6ThreadP8_jobject)
> 01-04 17:58:12.247: I/DEBUG(5047):  #03  pc 0005724c  
> /system/lib/libdvm.so
> 01-04 17:58:12.247: I/DEBUG(5047):  #04  pc 0022707e  
> /system/lib/libwebcore.so
> 01-04 17:58:12.247: I/DEBUG(5047):  #05  pc 003ee990  
> /system/lib/libwebcore.so
> 01-04 17:58:12.247: I/DEBUG(5047):  #06  pc 003a2cd2  
> /system/lib/libwebcore.so
> 01-04 17:58:12.247: I/DEBUG(5047):  #07  pc 003a30ca  
> /system/lib/libwebcore.so
> ...
> When commenting out the JS inclusion in the loaded index.html, the native UI 
> elements show up on my HTC Evo device but of course without any callback 
> functionality on button clicks due to the missing JS.

--
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

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=2&api_key=x&source=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(P

[jira] [Commented] (CB-2293) File Tranfer of picture fails on every other picture

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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=2&api_key=x&source=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): erro

[jira] [Commented] (CB-2285) No more activities from Cordova

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-1807) Android navigator.connection.type is not equal to navigator.network.connection.type

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Assigned] (CB-2285) No more activities from Cordova

[Andrew Grieve (JIRA)]

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

Andrew Grieve reassigned CB-2285:
-

Assignee: Andrew Grieve  (was: Shazron Abdullah)

> 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-1807) Android navigator.connection.type is not equal to navigator.network.connection.type

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-1807:
---

Which version of Android?

> 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

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2207) Xcode sometimes does not pick up changes to www/

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-2207:
---

I've implemented this and put it on a branch:
https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=log;h=refs/heads/better_resource_copy_step

Would like to merge after 2.4 is out.

> 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] [Resolved] (CB-2271) Creating multiple CDVViewControllers at once only fires deviceready once

[Andrew Grieve (JIRA)]

 [ 
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

[Andrew Grieve (JIRA)]

 [ 
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-2225) User-Agent changes in the CordovaWebView after using InAppBrowser

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Closed] (CB-2235) FileTransfer spec test failing on iOS5

[Andrew Grieve (JIRA)]

 [ 
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-2235) FileTransfer spec test failing on iOS5

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (CB-2285) No more activities from Cordova

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-285) Add property returning root path of PhoneGap files

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

*/Documents*
  - For user-data.
  - Backed up by iCloud, where each file is shown as an entry.

*/Documents/Inbox*
  - Can't create or write files, but *can* delete & read files.
  - Used for receiving files from Mail.app

*/Library*
  - Backed up by iCloud unless com.apple.MobileBackup attribute is set.
  - All files shown as a single entry in iCloud

*/Library/Application Support*
  - Same as /Library it looks like...

*/Library/Caches*
  - Not backed up by iCloud

*/tmp*
  - Not backed up by iCloud
  - Get this via NSTemporaryDirectory() (it's /var/folders/ when on simulator)

 == /var/mobile/Applications//. Retrieve it with 
NSHomeDirectory()


PERSISTENT ==> /Documents
TEMPORARY ==> /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/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .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

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .app.
> This has two side effects:
> 1. Paths to audio for Media must be hard-coded separately depending on the 
> platform, which is inconvenient.

[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .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] [Assigned] (CB-285) Add property returning root path of PhoneGap files

[Andrew Grieve (JIRA)]

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

Andrew Grieve reassigned CB-285:


Assignee: Andrew Grieve

> 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/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .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-2235) FileTransfer spec test failing on iOS5

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:





> 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] [Resolved] (CB-2279) Mobile-Spec does not run on Android 2.x

[Andrew Grieve (JIRA)]

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

Andrew Grieve resolved CB-2279.
---

Resolution: Fixed

Fix commit:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=71223711fb1591b1255d871140d959fd9095f0c3

> 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
>Assignee: Andrew Grieve
>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-2279) Mobile-Spec does not run on Android 2.x

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (CB-1957) InAppBrowser - video/audio does not stop playing when browser is closed

[Andrew Grieve (JIRA)]

 [ 
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-2227) Move mapping of module->symbol into individual plugins

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (CB-2276) Refactor to eliminate casts of viewControlled -> CDVViewController

[Andrew Grieve (JIRA)]

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] [Created] (CB-2275) Explicitly initialize NSURLCache in the project template

[Andrew Grieve (JIRA)]

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] [Commented] (CB-2180) Convert iOS project template to use ARC

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (CB-2207) Xcode sometimes does not pick up changes to www/

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-622) FileTransfer interface should provide progress monitoring

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2165) The "saveToPhotoAlbum" option for Camera.getPicture does not work with Cordova 2.2/Android

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-975) camera.getPicture crashes app on iPad3 when capturing multiple images

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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   libsy

[jira] [Commented] (CB-2190) FileTransfer does not request more time than the 5 second limit when placed in background.

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Andrew Grieve (JIRA)]

 [ 
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] [Reopened] (CB-1957) InAppBrowser - video/audio does not stop playing when browser is closed

[Andrew Grieve (JIRA)]

 [ 
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] [Commented] (CB-2227) Move mapping of module->symbol into individual plugins

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-2227:
---

The working branch is here:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/symbolmapping

Currently steps 1-3 are done. And the File plugin has been moved over to using 
it.

Next up is to do likewise for other core plugins.

This changes does not affect existing third-party plugins. It would be nice to 
fold builder & modulemapper into the same module when this is over, but we 
should check that no third-party plugins currently depend on cordova/builder. I 
think Ripple currently depends on it.

> 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-2225) User-Agent changes in the CordovaWebView after using InAppBrowser

[Andrew Grieve (JIRA)]

 [ 
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] [Resolved] (CB-2165) The "saveToPhotoAlbum" option for Camera.getPicture does not work with Cordova 2.2/Android

[Andrew Grieve (JIRA)]

 [ 
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] [Commented] (CB-2165) The "saveToPhotoAlbum" option for Camera.getPicture does not work with Cordova 2.2/Android

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (CB-2225) User-Agent changes in the CordovaWebView after using InAppBrowser

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2086) Invoke default android file picker for html file input

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-2235) FileTransfer spec test failing on iOS5

[Andrew Grieve (JIRA)]

Andrew Grieve created CB-2235:
-

 Summary: 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: Andrew Grieve
 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] [Resolved] (CB-2208) MobileSpec File tests Crash on Android 4.0.3 intel Emulator

[Andrew Grieve (JIRA)]

 [ 
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] [Created] (CB-2228) Add a command that prepares platform directories, but then doesn't call their build scripts

[Andrew Grieve (JIRA)]

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] [Created] (CB-2227) Move mapping of module->symbol into individual plugins

[Andrew Grieve (JIRA)]

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] [Commented] (CB-2102) InAppBrowser will not open PDFs on different pages

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-2102:
---

If the User-Agent is still changing, then I think that this is still a problem 
since we use it to determine which white-list to use. It's on my list for this 
week to try out your repro test case and see if I can get the UA to not change.

> 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.4.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] [Resolved] (CB-1978) Cordova 2.2 iOS does not work with RequireJS

[Andrew Grieve (JIRA)]

 [ 
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] [Resolved] (CB-2094) Cordova 2.3.0 not reliably firing deviceready after reload of local files

[Andrew Grieve (JIRA)]

 [ 
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-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse

[Andrew Grieve (JIRA)]

 [ 
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] [Commented] (CB-2213) Add support for native URIs

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (CB-2214) Refactor JS files to be more ready to move into their own repositories

[Andrew Grieve (JIRA)]

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] [Reopened] (CB-1978) Cordova 2.2 iOS does not work with RequireJS

[Andrew Grieve (JIRA)]

 [ 
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] [Commented] (CB-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-2183:
---

That's great! Supporting Blobs & ArrayBuffers is actually being worked on right 
now (likely to be included in the 2.4).

It would be great if we could get you as a tester for it. Would you be willing?

What I'm wondering is:
-What platforms your developing for,
-Exactly which APIs you'd like to use and how (e.g. give code snippets of how 
you use FileReader/FileWriter/Blob/ArrayBuffer/XHR2)
-Would you be willing to test these features as they get added into the 
development version

We'll still fix this bug in FileTransfer.

> [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: 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] [Resolved] (CB-2211) App template does not compile using xcodebuild

[Andrew Grieve (JIRA)]

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

Andrew Grieve resolved CB-2211.
---

Resolution: Not A Problem

Thanks Shaz. Works like a charm of course.

> App template does not compile using xcodebuild
> --
>
> Key: CB-2211
> URL: https://issues.apache.org/jira/browse/CB-2211
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Andrew Grieve
>Assignee: Andrew Grieve
>Priority: Minor
> Fix For: 2.4.0
>
>
> bin/create a com.google.a a
> xcodebuild -project a.xcodeproj -target a -configuration Debug -sdk 
> iphoneos6.0
> ...blah blah blah output...
> In file included from 
> /Users/agrieve/git/cordova-ios/a/a/Classes/AppDelegate.m:28:
> /Users/agrieve/git/cordova-ios/a/a/Classes/AppDelegate.h:30:9: fatal error: 
> 'Cordova/CDVViewController.h' file not found
> #import 
> ^
> 1 error generated.

--
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

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (CB-2211) App template does not compile using xcodebuild

[Andrew Grieve (JIRA)]

Andrew Grieve created CB-2211:
-

 Summary: App template does not compile using xcodebuild
 Key: CB-2211
 URL: https://issues.apache.org/jira/browse/CB-2211
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
 Fix For: 2.4.0


bin/create a com.google.a a

xcodebuild -project a.xcodeproj -target a -configuration Debug -sdk iphoneos6.0

...blah blah blah output...

In file included from 
/Users/agrieve/git/cordova-ios/a/a/Classes/AppDelegate.m:28:
/Users/agrieve/git/cordova-ios/a/a/Classes/AppDelegate.h:30:9: fatal error: 
'Cordova/CDVViewController.h' file not found
#import 
^
1 error generated.

--
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-2206) Cordova's FileReader breaks when used with a Blob

[Andrew Grieve (JIRA)]

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

Andrew Grieve resolved CB-2206.
---

Resolution: Fixed

Tested that this works on iOS & Android.
The test fails on pre-iOS6 and pre Android 3.0 though, since these browsers 
don't have a way to construct a Blob from JS.

js:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=d41650becbeee9d61860db06f7537898c0768987

mobile-spec:
https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=commit;h=fa02bfdb9627a01a14853f100d8006ff3c68ecdc

> 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] [Commented] (CB-2208) MobileSpec File tests Crash on Android 4.0.3 intel Emulator

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (CB-2208) MobileSpec File tests Crash on Android 4.0.3 intel Emulator

[Andrew Grieve (JIRA)]

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] [Resolved] (CB-2168) HTML Escaping on iOS FileReader may be unnecessary

[Andrew Grieve (JIRA)]

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

Andrew Grieve resolved CB-2168.
---

Resolution: Fixed

Removed the specialization and all tests still pass.

iOS Change:
https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=20b20b8d48bcd39ebe509cd302a43b1781d5431c

JS Change:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=f9bcabb68f3139458192f34a71ed3c6ae8a25123

> 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] [Assigned] (CB-2168) HTML Escaping on iOS FileReader may be unnecessary

[Andrew Grieve (JIRA)]

 [ 
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] [Commented] (CB-2206) Cordova's FileReader breaks when used with a Blob

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (CB-2207) Xcode sometimes does not pick up changes to www/

[Andrew Grieve (JIRA)]

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] [Updated] (CB-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse

[Andrew Grieve (JIRA)]

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

Andrew Grieve updated CB-2183:
--

Priority: Minor  (was: Critical)

> [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: 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] [Commented] (CB-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse

[Andrew Grieve (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (CB-1892) Refactor type-checking code in plugins into a helper method

[Andrew Grieve (JIRA)]

 [ 
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