[jira] [Comment Edited] (CB-2102) InAppBrowser will not open PDFs on different pages

[Jonathan Brumley (JIRA)]

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

Jonathan Brumley edited comment on CB-2102 at 1/12/13 4:27 AM:
---

It only do a reload after signing in, after that(on index.html) between 
requests and opening the PDF there is no page reload.

  was (Author: cayasso):
It only do a reload after signing in, after that, everything is on 
index.html, between requests and opening the PDF there is no page reload.
  
> InAppBrowser will not open PDFs on different pages
> --
>
> Key: CB-2102
> URL: https://issues.apache.org/jira/browse/CB-2102
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS, iOS
>Affects Versions: 2.3.0
> Environment: OSX Mountain Lion, xCode 4.5.2, happens on iPad 
> simulator 5.0, 5.1, 6.0.
>Reporter: Chad Crowell
>Assignee: Shazron Abdullah
>  Labels: InAppBrowser, iOS6
> Fix For: 2.3.0
>
> Attachments: cdv230 copy.zip, www-cb-2102.zip
>
>
> WWW folder is here: https://dl.dropbox.com/u/119908/www.zip
> The folder structure here is setup exactly like the much more elaborate 
> website we are wrapping in Cordova as an "offline website browser" app for my 
> client. This stripped down version exhibits the same problematic behavior.
> Whichever page you view first, the PDFs on that page open in IAB just fine. 
> Click over to the other page and the PDFs there don't open in IAB. Doesn't 
> matter which page you go to first, the other page always doesn't work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-2102) InAppBrowser will not open PDFs on different pages

[Jonathan Brumley (JIRA)]

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

Jonathan Brumley commented on CB-2102:
--

It only do a reload after signing in, after that, everything is on index.html, 
between requests and opening the PDF there is no page reload.

> 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] [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] [Commented] (CB-1973) console.log should only log once

[JIRA]

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

Frederico Costa Galvão commented on CB-1973:


I agree with the removal of excessive logging, but an important version of the 
3 logs was removed.
Neither of both current (2.3.0) logs show sourceID + lineCount anymore, and 
that makes debugging log errors quite difficult.
Is that expected? If so, is there a way, maybe a log filter (although I've 
looked for it and haven't found), to get that information (the source of the 
error/console.log and line number) now?

> console.log should only log once
> 
>
> Key: CB-1973
> URL: https://issues.apache.org/jira/browse/CB-1973
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Reporter: Joe Bowser
>Assignee: Joe Bowser
>Priority: Trivial
>
> This is something that we've ignored because it's trivial, but someone got 
> confused by it so we should fix this:
> https://groups.google.com/forum/?fromgroups=#!topic/phonegap/rQV04LCiZSw

--
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-2159) handleOpenURL not called on iOS

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah resolved CB-2159.
--

Resolution: Fixed

> handleOpenURL not called on iOS
> ---
>
> Key: CB-2159
> URL: https://issues.apache.org/jira/browse/CB-2159
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Fix For: 2.4.0
>
>
> Idan Gozlan from the ML:
> Ive noticed that handleOpenURL function not called when app is closed and 
> launched by the custom url.
> the function works alright when the app is in background.

--
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-2159) handleOpenURL not called on iOS

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah commented on CB-2159:
--

Fix commit - http://git-wip-us.apache.org/repos/asf/cordova-ios/commit/51831837

Note that for backgrounded apps, it still needs the explicit JavaScript write 
in AppDelegate.m (to fix later)

> handleOpenURL not called on iOS
> ---
>
> Key: CB-2159
> URL: https://issues.apache.org/jira/browse/CB-2159
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Fix For: 2.4.0
>
>
> Idan Gozlan from the ML:
> Ive noticed that handleOpenURL function not called when app is closed and 
> launched by the custom url.
> the function works alright when the app is in background.

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

[Jonathan Brumley (JIRA)]

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

Jonathan Brumley commented on CB-2102:
--

Correct. Its a single page app.

> 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

A little late butŠ welcome Marcel!

[Filip Maj]

Marcel got voted in as a committer and PMC member for Apache Cordova last
week. Marcel did a ton of work on this project across a few platforms
leading up to his voting in.

Marcel: congratulations and thank you for all your efforts to date!

[jira] [Resolved] (CB-2210) Update incubator download link in Getting Started Guide

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah resolved CB-2210.
--

Resolution: Fixed

Fix commit - http://git-wip-us.apache.org/repos/asf/cordova-docs/commit/be782c1c

> Update incubator download link in Getting Started Guide
> ---
>
> Key: CB-2210
> URL: https://issues.apache.org/jira/browse/CB-2210
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs, iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Fix For: 2.4.0
>
>
> http://docs.phonegap.com/en/2.3.0/guide_getting-started_ios_index.md.html#Getting%20Started%20with%20iOS
> Update in 2.3.0 and edge to TLP folder

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

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah commented on CB-2102:
--

Well, yes you are just echoing my findings above. Are you using a multi-page 
app, or a single index.html app?

> 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

[FYI] call for cordova devs to participate in phonegap day event in july

[Brian LeRoux]

http://goo.gl/fYW3J

[jira] [Commented] (CB-2211) App template does not compile using xcodebuild

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah commented on CB-2211:
--

It's missing a setting. If not cordova/build script 
(https://github.com/apache/cordova-ios/blob/master/bin/templates/project/cordova/build)
 won't work - and I tested that a few days ago. 

The key is the CONFIGURATION_BUILD_DIR setting in that script which is the 
equivalent to the Xcode IDE's Unique location for Derived Data preference.

> 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

[Jonathan Brumley (JIRA)]

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

Jonathan Brumley commented on CB-2102:
--

[~shazron]I dont have test code handy at the moment, but by looking at the 
server logs the issue seems to be with the User-Agent, for some reason the one 
set after I close a PDF is different than my initial one, check bellow:

My requests before window.open are using this User-Agent
Mozilla/5.0 (iPad; CPU OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like 
Gecko) Mobile/9B176 (161603296)

But after opening a PDF and closing, the user Agent is this:
Mozilla/5.0 (iPad; CPU OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like 
Gecko) Mobile/9B176

The difference is that (161603296) is missing, so since our requests are 
checked against the user agent out session get invalidated.

We might be able to change that to get over the issue, but this is a very 
interesting finding.
Best,
JB

> 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] [Commented] (CB-2154) navigator.splashscreen.show() broken in Phonegap 2.2 and 2.3.0rc2

[Simon MacDonald (JIRA)]

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

Simon MacDonald commented on CB-2154:
-

Yes, that will work in 2.4.0. I'm going to add a feature request to specify a 
timeout for SplashScreen.show().

> navigator.splashscreen.show() broken in Phonegap 2.2 and 2.3.0rc2
> -
>
> Key: CB-2154
> URL: https://issues.apache.org/jira/browse/CB-2154
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Android, Phonegap 2.2 and 2.3rc2
>Reporter: Ismael Olusola Jimoh
>Assignee: Simon MacDonald
> Fix For: 2.4.0
>
>
> I tested the navigator.splashscreen.show() function as documented and 
> realised that it is broken.
> The Splash-screen works as expected when app launched but a button call to 
> show splashscreen doesn't work.
> I had tested this same thing on Phonegap 2.1 and it worked alright so was 
> surprised it didn't work on 2.2. I then tested on Phonegap 2.3 and realised 
> it was also broken.
> Below is the code I used:
> 
> 
>   
> Splashscreen Example
>  src="cordova-2.3.0rc2.js">
> 
> // Wait for Cordova to load
> //
> document.addEventListener("deviceready", onDeviceReady, false);
> // Cordova is ready
> //
> function onDeviceReady() {
> //navigator.splashscreen.show();
> }
> function showSplash() {
> setTimeout(function() {
>   navigator.splashscreen.show();
> }, 2000);
> }
> function hideSplash() {
> setTimeout(function() {
>   navigator.splashscreen.hide();
>   }, 2000);
> }
> 
>   
>   
> Example
> Show
> Hide
>   
> 
> It doesn't work as mentioned on neither 2.2 nor 2.3.
> Thanks.
> Ismael

--
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-2210) Update incubator download link in Getting Started Guide

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah reassigned CB-2210:


Assignee: Shazron Abdullah  (was: Michael Brooks)

> Update incubator download link in Getting Started Guide
> ---
>
> Key: CB-2210
> URL: https://issues.apache.org/jira/browse/CB-2210
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs, iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Fix For: 2.4.0
>
>
> http://docs.phonegap.com/en/2.3.0/guide_getting-started_ios_index.md.html#Getting%20Started%20with%20iOS
> Update in 2.3.0 and edge to TLP folder

--
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-2210) Update incubator download link in Getting Started Guide

[Shazron Abdullah (JIRA)]

Shazron Abdullah created CB-2210:


 Summary: Update incubator download link in Getting Started Guide
 Key: CB-2210
 URL: https://issues.apache.org/jira/browse/CB-2210
 Project: Apache Cordova
  Issue Type: Bug
  Components: Docs, iOS
Reporter: Shazron Abdullah
Assignee: Michael Brooks
 Fix For: 2.4.0


http://docs.phonegap.com/en/2.3.0/guide_getting-started_ios_index.md.html#Getting%20Started%20with%20iOS

Update in 2.3.0 and edge to TLP folder

--
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-2209) ARC issues in Contact

[Becky Gibson (JIRA)]

Becky Gibson created CB-2209:


 Summary: ARC issues in Contact 
 Key: CB-2209
 URL: https://issues.apache.org/jira/browse/CB-2209
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.3.0
Reporter: Becky Gibson
Assignee: Becky Gibson
 Fix For: 2.4.0


Changing the __unsafe_unretained stack variables in contact.m to __weak exposes 
issues with the ARC conversion.  

See:  https://groups.google.com/forum/?fromgroups=#!topic/phonegap/D9-7rmVojI4

--
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-2159) handleOpenURL not called on iOS

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah edited comment on CB-2159 at 1/11/13 8:56 PM:
---

One way is for CDVViewController to handle the notification 
CDVPluginHandleOpenURLNotification itself and queue the writing of the JS up 
for after webViewDidFinishLoad. 

This avoids messy upgrade issues for users, and we can leave existing 
(BOOL)application:(UIApplication*)application handleOpenURL:(NSURL*)url code in 
AppDelegate.m as is.

  was (Author: shazron):
One way is for CDVViewController to handle the notification 
CDVPluginHandleOpenURLNotification itself and queue the writing of the JS up 
for after webViewDidFinishLoad. 

This avoids messy upgrade issues for users, and we can leave existing 
BOOL)application:(UIApplication*)application handleOpenURL:(NSURL*)url code in 
AppDelegate.m as is.
  
> handleOpenURL not called on iOS
> ---
>
> Key: CB-2159
> URL: https://issues.apache.org/jira/browse/CB-2159
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Fix For: 2.4.0
>
>
> Idan Gozlan from the ML:
> Ive noticed that handleOpenURL function not called when app is closed and 
> launched by the custom url.
> the function works alright when the app is in background.

--
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-2159) handleOpenURL not called on iOS

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah commented on CB-2159:
--

One way is for CDVViewController to handle the notification 
CDVPluginHandleOpenURLNotification itself and queue the writing of the JS up 
for after webViewDidFinishLoad. 

This avoids messy upgrade issues for users, and we can leave existing 
BOOL)application:(UIApplication*)application handleOpenURL:(NSURL*)url code in 
AppDelegate.m as is.

> handleOpenURL not called on iOS
> ---
>
> Key: CB-2159
> URL: https://issues.apache.org/jira/browse/CB-2159
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Fix For: 2.4.0
>
>
> Idan Gozlan from the ML:
> Ive noticed that handleOpenURL function not called when app is closed and 
> launched by the custom url.
> the function works alright when the app is in background.

--
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-2159) handleOpenURL not called on iOS

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah commented on CB-2159:
--

Easy patch would be this in AppDelegate.m, but not ideal since it hard-codes 
500ms delay. Best to queue it up after webViewDidFinishLoad:

{code}
- (BOOL)application:(UIApplication*)application handleOpenURL:(NSURL*)url
{
if (!url) {
return NO;
}

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 500 * NSEC_PER_MSEC), 
dispatch_get_current_queue(), ^{

// calls into javascript global function 'handleOpenURL'
NSString* jsString = [NSString 
stringWithFormat:@"handleOpenURL(\"%@\");", url];
[self.viewController.webView 
stringByEvaluatingJavaScriptFromString:jsString];

// all plugins will get the notification, and their handlers will be 
called
[[NSNotificationCenter defaultCenter] postNotification:[NSNotification 
notificationWithName:CDVPluginHandleOpenURLNotification object:url]];
});

return YES;
}
{code}

> handleOpenURL not called on iOS
> ---
>
> Key: CB-2159
> URL: https://issues.apache.org/jira/browse/CB-2159
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Fix For: 2.4.0
>
>
> Idan Gozlan from the ML:
> Ive noticed that handleOpenURL function not called when app is closed and 
> launched by the custom url.
> the function works alright when the app is in background.

--
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-2159) handleOpenURL not called on iOS

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah commented on CB-2159:
--

The problem here is of timing. 

The sequence of events is:
1. Called: (BOOL)application:(UIApplication*)application 
handleOpenURL:(NSURL*)url
2. Called: (void)webViewDidFinishLoad:(UIWebView*)theWebView

We need to "queue up" the JavaScript write until later. The easy way is to just 
use a block that is run after a delay for (1), but ideally we want to only run 
the JavaScript after (2)



> handleOpenURL not called on iOS
> ---
>
> Key: CB-2159
> URL: https://issues.apache.org/jira/browse/CB-2159
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Fix For: 2.4.0
>
>
> Idan Gozlan from the ML:
> Ive noticed that handleOpenURL function not called when app is closed and 
> launched by the custom url.
> the function works alright when the app is in background.

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

Re: Native URL functionality for files

[Shazron]

I like it. I seem to remember we discussed something related, like
document:// shortcut to files in the app's Documents folder as well (iOS
specific) but nothing came out of it.

For those curious, AssetLibrary urls look like
this: assets-library://asset/asset.JPG?id=13&ext=JPG


On Fri, Jan 11, 2013 at 10:21 AM, Max Woghiren  wrote:

> Hi everyone,
>
> I'm working on implementing chrome apps file system functionality using
> Cordova.  I'm focusing on iOS first.
>
> I'm planning on using AssetsLibrary to prevent having to (1) send actual
> file data to and from JS unnecessarily and (2) save temporary copies of
> files.
>
> In order to use asset library URLs (and the equivalents on other
> platforms), I'd like to add a third Camera DestinationType: NATIVE_URL.  In
> iOS, Camera would send back the assets-library URL, which can then be
> stored in a FileEntry.
>
> This type of URL would then be handled wherever necessary.  For instance,
> uploading an image to a server using FileTransfer would be able do it
> directly from the photo library, since it'd be given the assets-library
> URL.  File would have a bunch of changes to handle this as well.
>
> Please let me know if you have any comments, concerns, or things to
> consider about add this functionality.
>
> Thanks!
> -Max
>

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

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah commented on CB-2102:
--

@Jonathan - post test code. There is no "overwriting of xhr" going on with 
InAppBrowser, just 1) instantiation of a new UIWebView and 2) setting a new 
User-Agent. It's possible (as my findings show) doing either brings to light 
some bugs in iOS.

> InAppBrowser will not open PDFs on different pages
> --
>
> Key: CB-2102
> URL: https://issues.apache.org/jira/browse/CB-2102
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS, iOS
>Affects Versions: 2.3.0
> Environment: OSX Mountain Lion, xCode 4.5.2, happens on iPad 
> simulator 5.0, 5.1, 6.0.
>Reporter: Chad Crowell
>Assignee: Shazron Abdullah
>  Labels: InAppBrowser, iOS6
> Fix For: 2.3.0
>
> Attachments: cdv230 copy.zip, www-cb-2102.zip
>
>
> WWW folder is here: https://dl.dropbox.com/u/119908/www.zip
> The folder structure here is setup exactly like the much more elaborate 
> website we are wrapping in Cordova as an "offline website browser" app for my 
> client. This stripped down version exhibits the same problematic behavior.
> Whichever page you view first, the PDFs on that page open in IAB just fine. 
> Click over to the other page and the PDFs there don't open in IAB. Doesn't 
> matter which page you go to first, the other page always doesn't work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah commented on CB-2183:
--

I thought Patrick's patch was iOS 4.3 specific that's why I suggested removing 
it since removing it fixes this problem (and would be easiest I suppose) -- but 
let's do this correctly as you suggested

> [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] [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-1560) Cordova reports "Network Error" when trying to launch a corporate intranet site

[Joe Bowser (JIRA)]

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

Joe Bowser resolved CB-1560.


Resolution: Invalid

This issue appears to be an issue with the company network, not with the 
whitelist in general.  Due to inactivity, I'm going to close this issue.

> Cordova reports "Network Error" when trying to launch a corporate intranet 
> site
> ---
>
> Key: CB-1560
> URL: https://issues.apache.org/jira/browse/CB-1560
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.0.0
> Environment: Android 4.0.x, Droid 4, SGS3 both reproduced it
>Reporter: John Ament
>Assignee: Andrew Grieve
>Priority: Minor
>
> When you setup a simple app, with this:
> super.onCreate(savedInstanceState);
> super.loadUrl("http://devsystem.mycompany.com:8080/SomeMobileWeb";);
> You receive back a "Network Error."  This site is not externally facing, it's 
> internal only.
> This does not occur when your site is externally facing (public accessibility)

--
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-1560) Cordova reports "Network Error" when trying to launch a corporate intranet site

[Joe Bowser (JIRA)]

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

Joe Bowser commented on CB-1560:


Is this issue still present? 

> Cordova reports "Network Error" when trying to launch a corporate intranet 
> site
> ---
>
> Key: CB-1560
> URL: https://issues.apache.org/jira/browse/CB-1560
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.0.0
> Environment: Android 4.0.x, Droid 4, SGS3 both reproduced it
>Reporter: John Ament
>Assignee: Andrew Grieve
>Priority: Minor
>
> When you setup a simple app, with this:
> super.onCreate(savedInstanceState);
> super.loadUrl("http://devsystem.mycompany.com:8080/SomeMobileWeb";);
> You receive back a "Network Error."  This site is not externally facing, it's 
> internal only.
> This does not occur when your site is externally facing (public accessibility)

--
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-1009) Mass edit of contacts result in failure: error "failed binder transaction"

[Joe Bowser (JIRA)]

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

Joe Bowser commented on CB-1009:


So, what happened with this issue?

> Mass edit of contacts result in failure: error "failed binder transaction"
> --
>
> Key: CB-1009
> URL: https://issues.apache.org/jira/browse/CB-1009
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 1.9.0, 2.0.0
> Environment: Eclipse
>Reporter: Ciro La Ferrara
>Assignee: Braden Shepherdson
>
> Mass edit contact. If contacts are few, the application works. If contacts 
> are many (180), it closes unexpectedly.
> This is the source: http://nopaste.info/d1908f2aa9.html
> In the log i have many many "!!! FAILED BINDER TRANSACTION !!!"

--
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-2171) FileTransfer.download leaves 0 byte file in filesystem on 404 from server

[Joe Bowser (JIRA)]

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

Joe Bowser resolved CB-2171.


Resolution: Fixed

Pull requests are welcome! 

> FileTransfer.download leaves 0 byte file in filesystem on 404 from server
> -
>
> Key: CB-2171
> URL: https://issues.apache.org/jira/browse/CB-2171
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.3.0
> Environment: Android 2.3.
>Reporter: Clayton Grassick
>Assignee: Joe Bowser
> Fix For: 2.4.0
>
>
> To reproduce: 
> Call fileTransfer.download, passing a URL which returns 404.
> Error callback will be correctly fired. But 0-byte file will be left on 
> filesystem. This is because:
> FileOutputStream outputStream = new FileOutputStream(file);
> is called before the getInputStream is called.

--
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-2054) Iframe not working in Android4.0

[Joe Bowser (JIRA)]

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

Joe Bowser updated CB-2054:
---

Fix Version/s: (was: 2.4.0)

I don't think there will be a fix for this in the near future, since this is an 
ICS only issue.

> Iframe not working in Android4.0
> 
>
> Key: CB-2054
> URL: https://issues.apache.org/jira/browse/CB-2054
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
> Environment: Android4.0 corodova2.1.0 Jquerymobile 1.2.0
>Reporter: nathiya
>Assignee: Joe Bowser
>  Labels: android, javascript, jquery, phonegap
>
> I am using IFrame for loading webpage .its working fine in android 2.2 but 
> its not working in android 4.0.Input elements inside the webpage are disabled 
> I can't able to type and click the button and then
> I have searched and added scrolling="no" in Iframe tag.Now i can able to type 
> in the textbox(access input elements inside the webpage in Iframe) but i 
> can't able to scroll to the left and right of the webpage.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CB-1062) Way to get instance of a plugin via PluginManager

[Joe Bowser (JIRA)]

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

Joe Bowser resolved CB-1062.


Resolution: Fixed

This has been added as part of the state restore methods.

> Way to get instance of a plugin via PluginManager
> -
>
> Key: CB-1062
> URL: https://issues.apache.org/jira/browse/CB-1062
> Project: Apache Cordova
>  Issue Type: Wish
>  Components: Android
>Reporter: Andreas Sommer
>Assignee: Joe Bowser
> Fix For: 2.4.0
>
>
> PluginManager.getPlugin should be made public so that a plugin's instance can 
> be retrieved in Java 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

Re: not listed as a TLP

[Marcel Kinard]

Jukka or Brian, might you know the answer here?

On 1/11/2013 1:54 PM, Filip Maj wrote:

No idea..

On 1/11/13 6:26 AM, "Marcel Kinard"  wrote:


I'm working on creating the DOAP file.

Question: which PMC is Cordova in? I assumed it had its own dedicated PMC,
but I don't see a Cordova PMC listed anywhere at
http://projects.apache.org/indexes/pmc.html , does another rdf file need
to
be created?

Re: too long to package a release?

[Filip Maj]

I think we all agree on the general flow of feature branch -> "staging" ->
merge into "master" + tag.

Ripple uses "next" as the label for the branch with all stuff going into
the next release. I like this approach.

On 1/11/13 7:48 AM, "Andrew Grieve"  wrote:

>I don't think there's any advantage to creating them ahead of time, so we
>might as well not bother.
>
>
>On Fri, Jan 11, 2013 at 10:32 AM, Braden Shepherdson
>wrote:
>
>> Maybe I'm being coloured by the Chrome channels, but it seems to me
>>that we
>> would be doing our "development" of the next release in "dev", rather
>>than
>> unstable, and that bleeding edge Cordova users wanting the latest
>>features
>> with no outright breakages but with higher possibility of bugs should
>>use
>> "unstable". But I'm not sure how and when changes would move from one to
>> the other, whichever way around the names go. I'm imagining the flow
>>would
>> be:
>> Feature branches   ---ready to push-->   my "dev" (your "unstable")
>> ---release candidate-->   my "unstable" (your "dev")   ---release-->
>>  stable, tagged.
>>
>> Are we going to have branches for each minor release (ie. 2.3, 2.4) so
>>that
>> we can do point releases on them? Or would those be created only as
>> necessary when we needed a point release?
>>
>>
>> On Thu, Jan 10, 2013 at 9:05 PM, Andrew Grieve 
>> wrote:
>>
>> > I'm not clear on the difference between dev and unstable. If
>>something is
>> > so shaky that we're considering not putting it in the next release,
>>then
>> > I'd think that would go on a named feature branch (e.g.
>>array_buffers).
>> >
>> > Unless... is the purpose of dev to be where we put together a release
>> > candidate? If so, maybe a better name would be "staging"
>> >
>> >
>> > On Thu, Jan 10, 2013 at 8:13 PM, Filip Maj  wrote:
>> >
>> > > On 1/10/13 5:07 PM, "Brian LeRoux"  wrote:
>> > >
>> > > >Thank you. I lean to agreement w/ Andrew that more meaningful pull
>> > > >reqs are better and having named branches for what they do makes
>> > > >sense. Also agree that tags are for points in time---but I take no
>> > > >exception to a branch for those as well for dev purposes.
>> > > >
>> > > >Let me try to capture the conversation to this point:
>> > > >
>> > > >Branches:
>> > > >- Master gets deleted. We want meaningful pull requests and this
>>will
>> > > >force folks to pick a branch to dev against.
>> > > >- Stable: This is stable and frozen on the last tagged release.
>> > > >- Dev: The next release to be tagged. Feature branches merged from
>> > > >master when confident. This should build cleanly.
>> > >
>> > > ^^ merged from master?
>> > >
>> > > >- Unstable: the current working branch. Feature branches merged as
>> > > >needed for collaboration. No guarantee it builds.
>> > > >
>> > > >Tags:
>> > > >- Happen on the Stable branch.
>> > > >
>> > > >Workflow
>> > > >- Everyone works from local feature branch rebasing and committing
>>to
>> > > >Unstable as neccessary.
>> > > >- When that feature branch is considered good enough, it is merged
>> into
>> > > >Dev.
>> > > >- On release date whatever is Dev is rebased to Stable. Tagged.
>> > Released.
>> > > >
>> > > >Thoughts?
>> > >
>> > >
>> >
>>

Re: not listed as a TLP

[Filip Maj]

No idea..

On 1/11/13 6:26 AM, "Marcel Kinard"  wrote:

>I'm working on creating the DOAP file.
>
>Question: which PMC is Cordova in? I assumed it had its own dedicated PMC,
>but I don't see a Cordova PMC listed anywhere at
>http://projects.apache.org/indexes/pmc.html , does another rdf file need
>to
>be created?
>
>
>On Mon, Jan 7, 2013 at 8:58 AM, Shazron  wrote:
>
>> Procedure: http://projects.apache.org/create.html
>>
>>
>> On Mon, Jan 7, 2013 at 5:45 AM, Marcel Kinard 
>>wrote:
>>
>> > Cordova is not listed in any of the indexes at
>> http://projects.apache.org/
>> >
>> > It is still listed as an incubator at http://incubator.apache.org/**
>> > projects/index.html 
>> >
>> > Assuming this is an oversight, is there someone that could move it to
>>the
>> > TLP list? Thanks!
>> >
>> > -- Marcel Kinard
>> >
>>

Re: Moving plugin JS files around

[Jesse MacFadyen]

Hi Andrew,

Having spent some time with this, I don't think it's awful, but I am
worried about complexity.

To me, a better approach is:

- all plugins are simply ripped out of cordova-js
- each plugin is distributed 'built' meaning for an API like file or
contacts, there is only 1 js file, and while it depends on cordova.js,
it is not part of it. ( or possibly just a concat )
- plugman does the work of adding/removing but it is really just
changing script tags for the js portion

This means all our core plugs will need to be modified as the
currently depend on the builder to wrap them.

I spent some time working with your approach Andrew, and I think it
sounds better than it is. Blackberry has 4 inter-related branches to
consider, webos shares hardly any code with the other platforms, ... I
am more keen on adding consistency than  I am to making the tool work
around it.

If we were only concerned with iOS, Android, and windows phone, then
your  approach might be best, but there are some messes in there.

I will continue to push for the simpler solution, but I won't block
you anymore.
I do think you should dive a little deeper into your approach, and
possibly prove me wrong. I am completely open to further discussion on
the point.


Cheers,
 Jesse

Sent from my iPhone5

On 2013-01-10, at 8:09 PM, Andrew Grieve  wrote:

On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner  wrote:

> Ideally the require paths should stay true to the following rules (not that
> we follow them exactly now but we are close):
>
> 1. should always start with cordova (in case we ever share a require
> framework)
> 2. should follow as close as possible to the folder structure.
>
> We don't really do this now (but we are close).  It is mainly to help with
> navigation of the project from a require statement:
>
>var foo = require('cordova/plugin/foo/submodule')
>
> Ideally I should be able to navigate to a file that lives in:
>
>~/cordova.js/plugin/foo/submodule.js
>
> But realistically we are probably going to see:
>
>   ~/cordova.js/plugin/foo/js/submodule.js
>
> Assuming we are dumping everything into a js folder here is the "mapping"
> off the top of my head:
>
>   var foo = require('cordova/plugin/foo')
>   ~/cordova.js/plugin/foo/js/index.js
>
>   var foo = require('cordova/plugin/foo/ios')
>   ~/cordova.js/plugin/foo/js/ios.js
>
>   var foo = require('cordova/plugin/foo/blackberry/qnx')
>   ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>
> What does a plugin (native and js code) folder structure look like?


Have a look at this plugin: https://github.com/shazron/KeychainPlugin

With the JS changes I'm proposing, it would look like:
/src/ios/*.h, *.m
/www  <- empty!
/src/js/common/keychain.js
  or
/src/js/ios/keychain.js

So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
within cordova-js, is that when they move out, there will be the mapping:
cordova-js/plugin/$PLUGIN_NAME --->  $PLUGIN_REPO/src/js


When a plugin is installed into a project via cordova-cli, I suggest that
we get a structure like this:

MyApp/platforms/ios/... same as before ...
MyApp/cordova-js/... copy of cordova-js
MyApp/cordova-js/plugin/keychain/common/keychain.js
MyApp/plugins/keychain/plugin.xml
MyApp/www

So, the idea here is that the cordova-js will have no top-level plugin/
directory, but one will be added when plugins are added.

Also, like other sources, .js file should be listed in the plugin.xml so
that they can be reliably removed.



About the require paths. I think for files in cordova-js, the prefix should
be "cordova/", but for plugin files, it should be "plugin/" (or maybe
"cordovaplugin/"?), so that plugin JS doesn't accidentally clobber core
cordova modules.

For the keychain example: require('cordovaplugin/keychain/keychain')


In terms of changes to the builder, we'd need to add the idea of multiple
roots. Instead of just 'lib', there will also be 'plugin' as a root.




>
> On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve  wrote:
>
>> I'd like to take a first step towards moving plugin JS into separate
> repos
>> by first moving them around within cordova-js.
>>
>> Here is my proposal:
>>
>> Current structure:
>>   lib/common/plugin/*.js
>>   lib/$PLATFORM/plugin/*.js
>>
>> New structure:
>>   plugin/$PLUGIN_NAME/js/common/*.js
>>   plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>>
>> The require path will need to change. Going from:
>>   cordova.require('cordova/plugin/FileTransferError')
>> To:
>>   cordova.require('plugin/file/FileTransferError')
>>
>>
>> I'll obviously need to update the builder scripts accordingly. The idea
>> here is that we:
>>   1. "cordova plugin add" will copy files into a project's plugins
>> directory
>>   2. "cordova build ios" will use the cordova-js packager and pass
> it
>> the plugin/ directory to use
>>
>> This will not involve changing how we export modules onto namespaces in
>> common.js / platform.js. That will come next though.
>>
>>
>> The resulting structur

Re: Should Automatic Reference Counting be on?

[Shazron]

Actually Cordova core has been ARC for a couple of releases now. Good idea
for the plugin tool default to non-ARC, this should be covered in the
spec...

On Friday, January 11, 2013, Kerri Shotts wrote:

> My two cents:
>
> If it's feasible to support ARC, I'd go for it. Having worked with ARC and
> non-ARC code, ARC is definitely easier on my brain cells -- I'm far too
> likely to leak memory like a sieve with manual memory management…
>
> That said, converting Cordova's base code from non-ARC to ARC may not be
> trivial. In theory, you can just get rid of autoreleases, retains,
> deallocs, and handle properties (assign/retain/copy --> weak,strong), but
> sometimes you end up getting into toll-free bridging between Cocoa and Core
> Foundation, and occasionally you run into more obscure problems (such as
> ARC releasing the object before the code expected it. Easy to fix, but not
> always /obvious/ prior to experiencing the issue.)
>
> Once we have ARC support, though,  the -fno-objc-arc compiler flag is a
> per-file setting, so I would think that the plugin tools could set that
> flag based on whether or not the plugin supported ARC or not. (I would
> think this should be determined in the metadata somewhere? Perhaps
> defaulting to no-ARC if there's no metadata saying one way or the other?)
>
>
> On Jan 11, 2013, at 9:14 AM, Andrew Grieve 
> >
> wrote:
>
> > This caught me off-guard as well, and I filed an issue to fix it up:
> > https://issues.apache.org/jira/browse/CB-2180
> >
> > I don't think it'll be entirely straight-forward though, because some
> > plugins still do not support ARC.
> >
> > What are everyone's thoughts on how to address this? One option is to
> have
> > the default project template already set-up with two lib targets. One for
> > ARC and one without ARC. Another option is to instruct users how to set
> the
> > compile flag to disable arc on a per-file basis.
> >
> > Do we want to support ARC and non-ARC plugins in plugman?
> >
> >
> > On Thu, Jan 10, 2013 at 6:52 PM, Jacob Weber 
> > >
> wrote:
> >
> >> When I create a new iOS project with Cordova 2.3, Automatic Reference
> >> Counting (CLANG_ENABLE_OBJC_ARC) is turned off. And the code (e.g.
> >> AppDelegate.m) uses autorelease, which I'm pretty sure is incompatible
> with
> >> ARC.
> >>
> >> Is this correct? Based on this blog post, I thought it should be on:
> >>
> >>
> http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counting-arc-and-cordova-plugins/
> >>
> >> Jacob
>
>

[jira] [Commented] (CB-2207) Xcode sometimes does not pick up changes to www/

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah commented on CB-2207:
--

Knowing some of the users, a full copy everytime might take a while if they 
have a lot of assets. I'm wondering if rsync could be better, not sure.

-- Posted from Bugbox for iPhone

> 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

Re: commit messages for newbies

[Michael Brooks]

Looks really good, nice work!

On Fri, Jan 11, 2013 at 9:59 AM, Marcel Kinard  wrote:

> Good points, Michael.
>
> Done. Please tweak further where desired. http://wiki.apache.org/**
> cordova/ContributorWorkflow
>
> -- Marcel
>
>
> On 1/10/2013 2:23 PM, Michael Brooks wrote:
>
>> @Marcel nice work, I agree we should add this to the wiki article.
>>
>> One note is that I believe you should have an empty line between the
>> summary and detailed body.
>>
>> The Pro Git Books [1] summaries the git messages templates as:
>>
>> Short (50 chars or less) summary of changes
>>
>> More detailed explanatory text, if necessary.  Wrap it to about 72
>> characters or so.  In some contexts, the first line is treated as the
>> subject of an email and the rest of the text as the body.  The blank
>> line separating the summary from the body is critical (unless you omit
>> the body entirely); tools like rebase can get confused if you run the
>> two together.
>>
>> Further paragraphs come after blank lines.
>>
>>   - Bullet points are okay, too
>>
>>   - Typically a hyphen or asterisk is used for the bullet, preceded by a
>> single space, with blank lines in between, but conventions vary here
>>
>>
>> @Josh
>>
>> I think short commit messages and multiple tiny commits are fine (and
>> good). For me, the most important part of the commit message is a
>> reference
>> to the issue that it is related to. For example, "[CB-1287] Rename such
>> and
>> such." The issue reference groups all of the tiny commits into a common
>> task.
>>
>> [1] 
>> http://git-scm.com/book/ch5-2.**html#Commit-Guidelines
>>
>>

Re: Cordova Activity Code Changes

[Joe Bowser]

I've added this master. Even with the uncertainty, it's better to have
this code than not.

On Thu, Jan 10, 2013 at 6:50 PM, Joe Bowser  wrote:
> On Thu, Jan 10, 2013 at 6:31 PM, Andrew Grieve  wrote:
>> I'd like to verify if this is the scenario:
>> 1. We invoke an intent that causes another app to take the foreground.
>> 2. Our app is forced to close by the OS due to memory pressures
>> 3. The other app finishes and sends an intent back to us
>> 4. Our app re-initializes, finds the plugin that started the request, and
>> gives it the result
>>
>
> That's the exact scenario!  In theory this should work.  In practice,
> it sort-of works, except that the Camera doesn't pass data back if you
> don't allow background processes (I tested it by restricting the
> background processes).
>
>> Assuming I've got this straight, I think there is value in adding in this
>> code. *if* apps design themselves such that their state is always stored,
>> then they should have a chance at restoring their state when they
>> re-launch.
>>
>> Uncertainties I have:
>> 1. Do we have a chance to give JS some time to run
>> within onSaveInstanceState? Perhaps we can send a message to the webkit
>> thread and then just sleep for a second? Perhaps even let it store things
>> in the Bundle?
>
> I don't know.  I'm hoping that this stops when we save the WebKit
> state, but I'd have to go spelunking in the Android WebKit code to
> figure this out.
>
>> 2. Upon re-launch, can we signal to the JS that it is "restarting" instead
>> of starting from scratch?
>
> We could easily do this, since we have to watch for the bundle in the
> activity in the first place.  From my tests, restoring the state is
> the same as hitting the refresh button on the page.  I have no idea
> what happens to session variables or anything else that is present at
> that time.
>
> Joe

Native URL functionality for files

[Max Woghiren]

Hi everyone,

I'm working on implementing chrome apps file system functionality using
Cordova.  I'm focusing on iOS first.

I'm planning on using AssetsLibrary to prevent having to (1) send actual
file data to and from JS unnecessarily and (2) save temporary copies of
files.

In order to use asset library URLs (and the equivalents on other
platforms), I'd like to add a third Camera DestinationType: NATIVE_URL.  In
iOS, Camera would send back the assets-library URL, which can then be
stored in a FileEntry.

This type of URL would then be handled wherever necessary.  For instance,
uploading an image to a server using FileTransfer would be able do it
directly from the photo library, since it'd be given the assets-library
URL.  File would have a bunch of changes to handle this as well.

Please let me know if you have any comments, concerns, or things to
consider about add this functionality.

Thanks!
-Max

Re: Should Automatic Reference Counting be on?

[Kerri Shotts]

My two cents:

If it's feasible to support ARC, I'd go for it. Having worked with ARC and 
non-ARC code, ARC is definitely easier on my brain cells -- I'm far too likely 
to leak memory like a sieve with manual memory management… 

That said, converting Cordova's base code from non-ARC to ARC may not be 
trivial. In theory, you can just get rid of autoreleases, retains, deallocs, 
and handle properties (assign/retain/copy --> weak,strong), but sometimes you 
end up getting into toll-free bridging between Cocoa and Core Foundation, and 
occasionally you run into more obscure problems (such as ARC releasing the 
object before the code expected it. Easy to fix, but not always /obvious/ prior 
to experiencing the issue.) 

Once we have ARC support, though,  the -fno-objc-arc compiler flag is a 
per-file setting, so I would think that the plugin tools could set that flag 
based on whether or not the plugin supported ARC or not. (I would think this 
should be determined in the metadata somewhere? Perhaps defaulting to no-ARC if 
there's no metadata saying one way or the other?)


On Jan 11, 2013, at 9:14 AM, Andrew Grieve  wrote:

> This caught me off-guard as well, and I filed an issue to fix it up:
> https://issues.apache.org/jira/browse/CB-2180
> 
> I don't think it'll be entirely straight-forward though, because some
> plugins still do not support ARC.
> 
> What are everyone's thoughts on how to address this? One option is to have
> the default project template already set-up with two lib targets. One for
> ARC and one without ARC. Another option is to instruct users how to set the
> compile flag to disable arc on a per-file basis.
> 
> Do we want to support ARC and non-ARC plugins in plugman?
> 
> 
> On Thu, Jan 10, 2013 at 6:52 PM, Jacob Weber  wrote:
> 
>> When I create a new iOS project with Cordova 2.3, Automatic Reference
>> Counting (CLANG_ENABLE_OBJC_ARC) is turned off. And the code (e.g.
>> AppDelegate.m) uses autorelease, which I'm pretty sure is incompatible with
>> ARC.
>> 
>> Is this correct? Based on this blog post, I thought it should be on:
>> 
>> http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counting-arc-and-cordova-plugins/
>> 
>> Jacob

Re: Should Automatic Reference Counting be on?

[Shazron]

I'm not for the two targets thing - i think we should educate devs to
upgrade to ARC, and plugin devs to have preprocessor macros to mix ARC and
non-ARC so as to be compatible everywhere if they want.

On Friday, January 11, 2013, Andrew Grieve wrote:

> This caught me off-guard as well, and I filed an issue to fix it up:
> https://issues.apache.org/jira/browse/CB-2180
>
> I don't think it'll be entirely straight-forward though, because some
> plugins still do not support ARC.
>
> What are everyone's thoughts on how to address this? One option is to have
> the default project template already set-up with two lib targets. One for
> ARC and one without ARC. Another option is to instruct users how to set the
> compile flag to disable arc on a per-file basis.
>
> Do we want to support ARC and non-ARC plugins in plugman?
>
>
> On Thu, Jan 10, 2013 at 6:52 PM, Jacob Weber 
> >
> wrote:
>
> > When I create a new iOS project with Cordova 2.3, Automatic Reference
> > Counting (CLANG_ENABLE_OBJC_ARC) is turned off. And the code (e.g.
> > AppDelegate.m) uses autorelease, which I'm pretty sure is incompatible
> with
> > ARC.
> >
> > Is this correct? Based on this blog post, I thought it should be on:
> >
> >
> http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counting-arc-and-cordova-plugins/
> >
> > Jacob
>

Re: Should Automatic Reference Counting be on?

[Shazron]

ARC is off in the template, thus autorelease is valid. My reasons why ARC
is off are in the blog post - namely no one has upgraded plugins to ARC yet
and we will break everything. We can change this if course (Andrew filed an
issue) - I'll file an issue with plugman and the spec.

On Thursday, January 10, 2013, Jacob Weber wrote:

> When I create a new iOS project with Cordova 2.3, Automatic Reference
> Counting (CLANG_ENABLE_OBJC_ARC) is turned off. And the code (e.g.
> AppDelegate.m) uses autorelease, which I'm pretty sure is incompatible with
> ARC.
>
> Is this correct? Based on this blog post, I thought it should be on:
>
> http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counting-arc-and-cordova-plugins/
>
> Jacob

Re: commit messages for newbies

[Marcel Kinard]

Good points, Michael.

Done. Please tweak further where desired. 
http://wiki.apache.org/cordova/ContributorWorkflow


-- Marcel

On 1/10/2013 2:23 PM, Michael Brooks wrote:

@Marcel nice work, I agree we should add this to the wiki article.

One note is that I believe you should have an empty line between the
summary and detailed body.

The Pro Git Books [1] summaries the git messages templates as:

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Further paragraphs come after blank lines.

  - Bullet points are okay, too

  - Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here


@Josh

I think short commit messages and multiple tiny commits are fine (and
good). For me, the most important part of the commit message is a reference
to the issue that it is related to. For example, "[CB-1287] Rename such and
such." The issue reference groups all of the tiny commits into a common
task.

[1] http://git-scm.com/book/ch5-2.html#Commit-Guidelines

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

[Jonathan Brumley (JIRA)]

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

Jonathan Brumley edited comment on CB-2102 at 1/11/13 4:55 PM:
---

I am having a weird issue with InAppBrowser that might be related to this 
issue, the first time I open a PDF with window.open everything is fine and I 
can close and open the same PDF over and over, but when I open a different PDF 
and then close it, it looks like something is changing or affecting my ajax 
requests, and the reason I know is that my token(or my request) in my ajax gets 
invalidated, this only happen after the second time I open a different PDF with 
window.open, I think InAppBrowser is overwriting the xhr in some kind of way 
that when you close the PDF xhr doesn't work properly. This only happen with 
PDFs when I open regular pages it works fine. This is all I have for now I will 
try to do some more testing to see what of my xhr is really changing.

Any idea what is going on, could this be related to the issue posted here?

  was (Author: cayasso):
I am having a weird issue with InAppBrowser that might be related to this 
issue, the first time I open a PDF with window.open everything is fine and I 
can close and open the same PDF over and over, but when I open a different PDF 
and then close it, it looks like something is changing or affecting my ajax 
requests, and the reason I know is that my token(or my request) in my ajax gets 
invalidated, this only happen after the second time I open a different PDF with 
window.open, I think InAppBrowser is overwriting the xhr in some kind of way 
that when you close the PDF xhr doesn't work properly. This only happen with 
PDFs when I open regular pages it works fine. This is all I have for now I will 
try to do some more testing to see what of my xhr is really changing.
  
> 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] [Comment Edited] (CB-2102) InAppBrowser will not open PDFs on different pages

[Jonathan Brumley (JIRA)]

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

Jonathan Brumley edited comment on CB-2102 at 1/11/13 4:40 PM:
---

I am having a weird issue with InAppBrowser that might be related to this 
issue, the first time I open a PDF with window.open everything is fine and I 
can close and open the same PDF over and over, but when I open a different PDF 
and then close it, it looks like something is changing or affecting my ajax 
requests, and the reason I know is that my token(or my request) in my ajax gets 
invalidated, this only happen after the second time I open a different PDF with 
window.open, I think InAppBrowser is overwriting the xhr in some kind of way 
that when you close the PDF xhr doesn't work properly. This only happen with 
PDFs when I open regular pages it works fine. This is all I have for now I will 
try to do some more testing to see what of my xhr is really changing.

  was (Author: cayasso):
I am having a weird issue with InAppBrowser that might be related to this 
issue, the first time I open a PDF with window.open everything is fine and I 
can close and open the same PDF over and over, but when I open a different PDF 
and then close it, it looks like something is changing or affecting my ajax 
requests, and the reason I know is that my token(or my request) in my ajax gets 
invalidated, this only happen after the second time I open a different PDF with 
window.open, I think InAppBrowser is overwriting the xhr in some kind of way 
that when you close the PDF xhr doesn't work properly. This only happen with 
PDFs when I open regular pages it works fine. This is all I have for now I will 
try to do some more testing to see what is really changing of my xhr.
  
> InAppBrowser will not open PDFs on different pages
> --
>
> Key: CB-2102
> URL: https://issues.apache.org/jira/browse/CB-2102
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS, iOS
>Affects Versions: 2.3.0
> Environment: OSX Mountain Lion, xCode 4.5.2, happens on iPad 
> simulator 5.0, 5.1, 6.0.
>Reporter: Chad Crowell
>Assignee: Shazron Abdullah
>  Labels: InAppBrowser, iOS6
> Fix For: 2.3.0
>
> Attachments: cdv230 copy.zip, www-cb-2102.zip
>
>
> WWW folder is here: https://dl.dropbox.com/u/119908/www.zip
> The folder structure here is setup exactly like the much more elaborate 
> website we are wrapping in Cordova as an "offline website browser" app for my 
> client. This stripped down version exhibits the same problematic behavior.
> Whichever page you view first, the PDFs on that page open in IAB just fine. 
> Click over to the other page and the PDFs there don't open in IAB. Doesn't 
> matter which page you go to first, the other page always doesn't work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-2102) InAppBrowser will not open PDFs on different pages

[Jonathan Brumley (JIRA)]

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

Jonathan Brumley commented on CB-2102:
--

I am having a weird issue with InAppBrowser that might be related to this 
issue, the first time I open a PDF with window.open everything is fine and I 
can close and open the same PDF over and over, but when I open a different PDF 
and then close it, it looks like something is changing or affecting my ajax 
requests, and the reason I know is that my token(or my request) in my ajax gets 
invalidated, this only happen after the second time I open a different PDF with 
window.open, I think InAppBrowser is overwriting the xhr in some kind of way 
that when you close the PDF xhr doesn't work properly. This only happen with 
PDFs when I open regular pages it works fine. This is all I have for now I will 
try to do some more testing to see what is really changing of my xhr.

> InAppBrowser will not open PDFs on different pages
> --
>
> Key: CB-2102
> URL: https://issues.apache.org/jira/browse/CB-2102
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS, iOS
>Affects Versions: 2.3.0
> Environment: OSX Mountain Lion, xCode 4.5.2, happens on iPad 
> simulator 5.0, 5.1, 6.0.
>Reporter: Chad Crowell
>Assignee: Shazron Abdullah
>  Labels: InAppBrowser, iOS6
> Fix For: 2.3.0
>
> Attachments: cdv230 copy.zip, www-cb-2102.zip
>
>
> WWW folder is here: https://dl.dropbox.com/u/119908/www.zip
> The folder structure here is setup exactly like the much more elaborate 
> website we are wrapping in Cordova as an "offline website browser" app for my 
> client. This stripped down version exhibits the same problematic behavior.
> Whichever page you view first, the PDFs on that page open in IAB just fine. 
> Click over to the other page and the PDFs there don't open in IAB. Doesn't 
> matter which page you go to first, the other page always doesn't work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-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

Re: too long to package a release?

[Andrew Grieve]

I don't think there's any advantage to creating them ahead of time, so we
might as well not bother.


On Fri, Jan 11, 2013 at 10:32 AM, Braden Shepherdson wrote:

> Maybe I'm being coloured by the Chrome channels, but it seems to me that we
> would be doing our "development" of the next release in "dev", rather than
> unstable, and that bleeding edge Cordova users wanting the latest features
> with no outright breakages but with higher possibility of bugs should use
> "unstable". But I'm not sure how and when changes would move from one to
> the other, whichever way around the names go. I'm imagining the flow would
> be:
> Feature branches   ---ready to push-->   my "dev" (your "unstable")
> ---release candidate-->   my "unstable" (your "dev")   ---release-->
>  stable, tagged.
>
> Are we going to have branches for each minor release (ie. 2.3, 2.4) so that
> we can do point releases on them? Or would those be created only as
> necessary when we needed a point release?
>
>
> On Thu, Jan 10, 2013 at 9:05 PM, Andrew Grieve 
> wrote:
>
> > I'm not clear on the difference between dev and unstable. If something is
> > so shaky that we're considering not putting it in the next release, then
> > I'd think that would go on a named feature branch (e.g. array_buffers).
> >
> > Unless... is the purpose of dev to be where we put together a release
> > candidate? If so, maybe a better name would be "staging"
> >
> >
> > On Thu, Jan 10, 2013 at 8:13 PM, Filip Maj  wrote:
> >
> > > On 1/10/13 5:07 PM, "Brian LeRoux"  wrote:
> > >
> > > >Thank you. I lean to agreement w/ Andrew that more meaningful pull
> > > >reqs are better and having named branches for what they do makes
> > > >sense. Also agree that tags are for points in time---but I take no
> > > >exception to a branch for those as well for dev purposes.
> > > >
> > > >Let me try to capture the conversation to this point:
> > > >
> > > >Branches:
> > > >- Master gets deleted. We want meaningful pull requests and this will
> > > >force folks to pick a branch to dev against.
> > > >- Stable: This is stable and frozen on the last tagged release.
> > > >- Dev: The next release to be tagged. Feature branches merged from
> > > >master when confident. This should build cleanly.
> > >
> > > ^^ merged from master?
> > >
> > > >- Unstable: the current working branch. Feature branches merged as
> > > >needed for collaboration. No guarantee it builds.
> > > >
> > > >Tags:
> > > >- Happen on the Stable branch.
> > > >
> > > >Workflow
> > > >- Everyone works from local feature branch rebasing and committing to
> > > >Unstable as neccessary.
> > > >- When that feature branch is considered good enough, it is merged
> into
> > > >Dev.
> > > >- On release date whatever is Dev is rebased to Stable. Tagged.
> > Released.
> > > >
> > > >Thoughts?
> > >
> > >
> >
>

[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

Re: too long to package a release?

[Braden Shepherdson]

Maybe I'm being coloured by the Chrome channels, but it seems to me that we
would be doing our "development" of the next release in "dev", rather than
unstable, and that bleeding edge Cordova users wanting the latest features
with no outright breakages but with higher possibility of bugs should use
"unstable". But I'm not sure how and when changes would move from one to
the other, whichever way around the names go. I'm imagining the flow would
be:
Feature branches   ---ready to push-->   my "dev" (your "unstable")
---release candidate-->   my "unstable" (your "dev")   ---release-->
 stable, tagged.

Are we going to have branches for each minor release (ie. 2.3, 2.4) so that
we can do point releases on them? Or would those be created only as
necessary when we needed a point release?


On Thu, Jan 10, 2013 at 9:05 PM, Andrew Grieve  wrote:

> I'm not clear on the difference between dev and unstable. If something is
> so shaky that we're considering not putting it in the next release, then
> I'd think that would go on a named feature branch (e.g. array_buffers).
>
> Unless... is the purpose of dev to be where we put together a release
> candidate? If so, maybe a better name would be "staging"
>
>
> On Thu, Jan 10, 2013 at 8:13 PM, Filip Maj  wrote:
>
> > On 1/10/13 5:07 PM, "Brian LeRoux"  wrote:
> >
> > >Thank you. I lean to agreement w/ Andrew that more meaningful pull
> > >reqs are better and having named branches for what they do makes
> > >sense. Also agree that tags are for points in time---but I take no
> > >exception to a branch for those as well for dev purposes.
> > >
> > >Let me try to capture the conversation to this point:
> > >
> > >Branches:
> > >- Master gets deleted. We want meaningful pull requests and this will
> > >force folks to pick a branch to dev against.
> > >- Stable: This is stable and frozen on the last tagged release.
> > >- Dev: The next release to be tagged. Feature branches merged from
> > >master when confident. This should build cleanly.
> >
> > ^^ merged from master?
> >
> > >- Unstable: the current working branch. Feature branches merged as
> > >needed for collaboration. No guarantee it builds.
> > >
> > >Tags:
> > >- Happen on the Stable branch.
> > >
> > >Workflow
> > >- Everyone works from local feature branch rebasing and committing to
> > >Unstable as neccessary.
> > >- When that feature branch is considered good enough, it is merged into
> > >Dev.
> > >- On release date whatever is Dev is rebased to Stable. Tagged.
> Released.
> > >
> > >Thoughts?
> >
> >
>

[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

[jira] [Created] (CB-2206) Cordova's FileReader breaks when used with a Blob

[Andrew Grieve (JIRA)]

Andrew Grieve created CB-2206:
-

 Summary: Cordova's FileReader breaks when used with a Blob
 Key: CB-2206
 URL: https://issues.apache.org/jira/browse/CB-2206
 Project: Apache Cordova
  Issue Type: Bug
  Components: CordovaJS
Affects Versions: 2.3.0
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
 Fix For: 2.4.0


The follow code doesn't work as expected, and on iOS causes the app to crash.

var blob = new Blob([new DataView(buf)]);
var f = new FileReader();
f.onload = function(e) {
  callback(e.target.result);
};  
f.readAsText(blob);


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Should Automatic Reference Counting be on?

[Andrew Grieve]

This caught me off-guard as well, and I filed an issue to fix it up:
https://issues.apache.org/jira/browse/CB-2180

I don't think it'll be entirely straight-forward though, because some
plugins still do not support ARC.

What are everyone's thoughts on how to address this? One option is to have
the default project template already set-up with two lib targets. One for
ARC and one without ARC. Another option is to instruct users how to set the
compile flag to disable arc on a per-file basis.

Do we want to support ARC and non-ARC plugins in plugman?


On Thu, Jan 10, 2013 at 6:52 PM, Jacob Weber  wrote:

> When I create a new iOS project with Cordova 2.3, Automatic Reference
> Counting (CLANG_ENABLE_OBJC_ARC) is turned off. And the code (e.g.
> AppDelegate.m) uses autorelease, which I'm pretty sure is incompatible with
> ARC.
>
> Is this correct? Based on this blog post, I thought it should be on:
>
> http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counting-arc-and-cordova-plugins/
>
> Jacob

Re: not listed as a TLP

[Marcel Kinard]

I'm working on creating the DOAP file.

Question: which PMC is Cordova in? I assumed it had its own dedicated PMC,
but I don't see a Cordova PMC listed anywhere at
http://projects.apache.org/indexes/pmc.html , does another rdf file need to
be created?


On Mon, Jan 7, 2013 at 8:58 AM, Shazron  wrote:

> Procedure: http://projects.apache.org/create.html
>
>
> On Mon, Jan 7, 2013 at 5:45 AM, Marcel Kinard  wrote:
>
> > Cordova is not listed in any of the indexes at
> http://projects.apache.org/
> >
> > It is still listed as an incubator at http://incubator.apache.org/**
> > projects/index.html 
> >
> > Assuming this is an oversight, is there someone that could move it to the
> > TLP list? Thanks!
> >
> > -- Marcel Kinard
> >
>

[jira] [Created] (CB-2205) adding Blackberry platform throws an error -- running cordova-client in windows "The provided path is not a Cordova BlackBerry WebWorks project"

[manu devarunda (JIRA)]

manu devarunda created CB-2205:
--

 Summary: adding Blackberry platform throws an error -- running 
cordova-client in windows "The provided path is not a Cordova BlackBerry 
WebWorks project"
 Key: CB-2205
 URL: https://issues.apache.org/jira/browse/CB-2205
 Project: Apache Cordova
  Issue Type: Bug
  Components: BlackBerry, CLI
Affects Versions: 2.2.0
 Environment: blackberry, cordova-client
Reporter: manu devarunda
Assignee: Tim Kim


running cordova-client in windows

succesfully created cordova project.

try to add blackberry platform

cordova platform add blackberry

getting below error : 
The provided path is not a Cordova BlackBerry WebWorks project.

please let me know what setting I need to change?

BR,
Manu

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