date:20130111

Andrew Grieve created CB-2206:
-

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


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

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


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

[jira] [Resolved] (CB-1892) Refactor type-checking code in plugins into a helper method

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

Andrew Grieve resolved CB-1892.
---

Resolution: Fixed

Some commits ending with:
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=790e28572ec70d2956f24c48591ed681ddec5eaf

This applies argscheck to all files that already have type-checking in them
(and so reduces code size).

I'd like to not go overboard with this, so am marking as fixed and do not
intend to introduce it anywhere else.

Refactor type-checking code in plugins into a helper method
---

Key: CB-1892
URL: https://issues.apache.org/jira/browse/CB-1892
Project: Apache Cordova
Issue Type: Improvement
Components: CordovaJS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
Fix For: 2.4.0

ML Discussion: http://callback.markmail.org/thread/4vgze66wlaaxthsd
The idea is to add a typecheck module along the lines of:
argscheck.checkArgs('noasdf', 'testFunc', arguments);
where n=number, o=object, a=array, s=string, d=date, f=function, *=anything
Side-effects of this change will include:
1. All core plugins will have their callbacks be optional
2. Incorrect types will result in an exception thrown
3. Should reduce the size of cordova.js through removing repetitive code.

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

[jira] [Commented] (CB-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse


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

Andrew Grieve commented on CB-2183:
---

To be clear, I do think we should fix this. I'm also wondering though if you 
can accomplish what you're trying to do using the FileSystem API? 

 [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse
 --

 Key: CB-2183
 URL: https://issues.apache.org/jira/browse/CB-2183
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.2.0
 Environment: Tested on iOS 5.1 and 6.0
Reporter: William Wong
Assignee: Shazron Abdullah
Priority: Critical
  Labels: File, FileTransfer
 Fix For: 2.4.0


 When FileTransfer.download() is downloading a file from file:///, 
 NSURLConnection did not return with NSHTTPURLResponse. This will fail for 
 apps that copy files from www/, e.g. apps that initialize its database from a 
 pre-built cache packaged in IPA.
 In CB-1600 (fixed in 2.2.0), the fix assumes all response must be 
 NSHTTPURLResponse. So when FileTransfer.download() is downloading from a 
 file:/// URL (e.g. copying file from www/ folder to Documents/), FileTransfer 
 assumed the download operation failed and returned 403.
 Tested if we comment out CB-1600, downloading from file:/// works again.
 We need to find out a better fix instead of commenting out CB-1600.
 According to 
 http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html#//apple_ref/doc/uid/1165i,
  URL of file:/// is supported.
 You can test FileTransfer.download() by calling it with 
 encodeURI(document.location.href) as the source parameter.

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

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

Andrew Grieve created CB-2207:
-

 Summary: Xcode sometimes does not pick up changes to www/
 Key: CB-2207
 URL: https://issues.apache.org/jira/browse/CB-2207
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
 Fix For: 2.4.0


Pretty annoying when you make changes and click Play and your changes aren't 
there. I think we can fix this by changing the project template's custom build 
step from:

touch -cm ${PROJECT_DIR}/www

to:

rm -rf $BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME/www
exec cp -R www $BUILT_PRODUCTS_DIR/$FULL_PRODUCT_NAME/www


Any objections?

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

Re: too long to package a release?

2013-01-11 Thread 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 bra...@chromium.orgwrote:

 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 agri...@chromium.org
 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 f...@adobe.com wrote:
 
   On 1/10/13 5:07 PM, Brian LeRoux b...@brian.io 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] [Commented] (CB-2206) Cordova's FileReader breaks when used with a Blob


[ 
https://issues.apache.org/jira/browse/CB-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551221#comment-13551221
 ] 

Andrew Grieve commented on CB-2206:
---

The iOS crash happens because of the presence of an \x01 character in the file 
path. I don't think this is worth fixing.

 Cordova's FileReader breaks when used with a Blob
 -

 Key: CB-2206
 URL: https://issues.apache.org/jira/browse/CB-2206
 Project: Apache Cordova
  Issue Type: Bug
  Components: CordovaJS
Affects Versions: 2.3.0
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
 Fix For: 2.4.0


 The follow code doesn't work as expected, and on iOS causes the app to crash.
 var blob = new Blob([new DataView(buf)]);
 var f = new FileReader();
 f.onload = function(e) {
   callback(e.target.result);
 };  
 f.readAsText(blob);

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

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


[ 
https://issues.apache.org/jira/browse/CB-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Comment Edited] (CB-2102) InAppBrowser will not open PDFs on different pages


[ 
https://issues.apache.org/jira/browse/CB-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Comment Edited] (CB-2102) InAppBrowser will not open PDFs on different pages


[ 
https://issues.apache.org/jira/browse/CB-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Assigned] (CB-2168) HTML Escaping on iOS FileReader may be unnecessary


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

Andrew Grieve reassigned CB-2168:
-

Assignee: Andrew Grieve  (was: Braden Shepherdson)

 HTML Escaping on iOS FileReader may be unnecessary
 --

 Key: CB-2168
 URL: https://issues.apache.org/jira/browse/CB-2168
 Project: Apache Cordova
  Issue Type: Sub-task
  Components: iOS
Affects Versions: 2.3.0
Reporter: Braden Shepherdson
Assignee: Andrew Grieve
Priority: Minor
 Fix For: 2.4.0


 The iOS FileReader's readAsText handler encodes the result with HTML percent 
 escapes, and the iOS-specific Javascript code decodes it. This 
 platform-specific Javascript code doesn't support slicing.
 Either the encoding is there for a reason and I'll implement slicing for the 
 iOS JS code, or we can remove the encoding and the unnecessary separate 
 implementation. We need to know why that encoding was added in the first 
 place.

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

Re: Should Automatic Reference Counting be on?

2013-01-11 Thread 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 
 ja...@jacobweber.comjavascript:;
 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?

2013-01-11 Thread 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 agri...@chromium.org 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 ja...@jacobweber.com 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: Cordova Activity Code Changes

2013-01-11 Thread 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 bows...@gmail.com wrote:
 On Thu, Jan 10, 2013 at 6:31 PM, Andrew Grieve agri...@chromium.org 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

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


[ 
https://issues.apache.org/jira/browse/CB-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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: Should Automatic Reference Counting be on?

2013-01-11 Thread 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
agri...@chromium.orgjavascript:;
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
ja...@jacobweber.comjavascript:;
wrote:

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

2013-01-11 Thread Filip Maj

No idea..

On 1/11/13 6:26 AM, Marcel Kinard cmarc...@gmail.com 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 shaz...@gmail.com wrote:

 Procedure: http://projects.apache.org/create.html


 On Mon, Jan 7, 2013 at 5:45 AM, Marcel Kinard cmarc...@gmail.com
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 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: too long to package a release?

2013-01-11 Thread 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 agri...@chromium.org 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
bra...@chromium.orgwrote:

 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 agri...@chromium.org
 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 f...@adobe.com wrote:
 
   On 1/10/13 5:07 PM, Brian LeRoux b...@brian.io 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

2013-01-11 Thread 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 cmarc...@gmail.com 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?

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


 [ 
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

[jira] [Updated] (CB-2054) Iframe not working in Android4.0


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


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


[ 
https://issues.apache.org/jira/browse/CB-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Resolved] (CB-1560) Cordova reports Network Error when trying to launch a corporate intranet site


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

Andrew Grieve created CB-2208:
-

 Summary: MobileSpec File tests Crash on Android 4.0.3 intel 
Emulator
 Key: CB-2208
 URL: https://issues.apache.org/jira/browse/CB-2208
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
 Fix For: 2.4.0


01-11 14:34:23.028: I/dalvikvm(1465): java.lang.UnsupportedOperationException: 
Unknown URI: content://media/external/images/media match: 1
01-11 14:34:23.028: I/dalvikvm(1465):   at 
android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:168)
01-11 14:34:23.028: I/dalvikvm(1465):   at 
android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:136)
01-11 14:34:23.028: I/dalvikvm(1465):   at 
android.content.ContentProviderProxy.delete(ContentProviderNative.java:479)
01-11 14:34:23.028: I/dalvikvm(1465):   at 
android.content.ContentResolver.delete(ContentResolver.java:822)
01-11 14:34:23.028: I/dalvikvm(1465):   at 
org.apache.cordova.FileUtils.notifyDelete(FileUtils.java:242)
01-11 14:34:23.028: I/dalvikvm(1465):   at 
org.apache.cordova.FileUtils.execute(FileUtils.java:186)


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

[jira] [Commented] (CB-2208) MobileSpec File tests Crash on Android 4.0.3 intel Emulator


[ 
https://issues.apache.org/jira/browse/CB-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13551463#comment-13551463
 ] 

Andrew Grieve commented on CB-2208:
---

I could just add a try/catch around it in FileUtils.notifyDelete(). I'm not too 
sure of what this is trying to do though, so not sure if that's the best fix.

 MobileSpec File tests Crash on Android 4.0.3 intel Emulator
 ---

 Key: CB-2208
 URL: https://issues.apache.org/jira/browse/CB-2208
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
 Fix For: 2.4.0


 01-11 14:34:23.028: I/dalvikvm(1465): 
 java.lang.UnsupportedOperationException: Unknown URI: 
 content://media/external/images/media match: 1
 01-11 14:34:23.028: I/dalvikvm(1465): at 
 android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:168)
 01-11 14:34:23.028: I/dalvikvm(1465): at 
 android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:136)
 01-11 14:34:23.028: I/dalvikvm(1465): at 
 android.content.ContentProviderProxy.delete(ContentProviderNative.java:479)
 01-11 14:34:23.028: I/dalvikvm(1465): at 
 android.content.ContentResolver.delete(ContentResolver.java:822)
 01-11 14:34:23.028: I/dalvikvm(1465): at 
 org.apache.cordova.FileUtils.notifyDelete(FileUtils.java:242)
 01-11 14:34:23.028: I/dalvikvm(1465): at 
 org.apache.cordova.FileUtils.execute(FileUtils.java:186)

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

[jira] [Commented] (CB-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse


[ 
https://issues.apache.org/jira/browse/CB-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (CB-2102) InAppBrowser will not open PDFs on different pages

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

Re: Native URL functionality for files

2013-01-11 Thread 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=13ext=JPG


On Fri, Jan 11, 2013 at 10:21 AM, Max Woghiren m...@chromium.org 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] [Commented] (CB-2159) handleOpenURL not called on iOS


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

[jira] [Commented] (CB-2159) handleOpenURL not called on iOS


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


[ 
https://issues.apache.org/jira/browse/CB-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Comment Edited] (CB-2159) handleOpenURL not called on iOS


[ 
https://issues.apache.org/jira/browse/CB-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Created] (CB-2209) ARC issues in Contact

2013-01-11 Thread 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] [Created] (CB-2210) Update incubator download link in Getting Started Guide

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] [Assigned] (CB-2210) Update incubator download link in Getting Started Guide


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

2013-01-11 Thread Simon MacDonald (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:
 !DOCTYPE html
 html
   head
 titleSplashscreen Example/title
 script type=text/javascript charset=utf-8 
 src=cordova-2.3.0rc2.js/script
 script type=text/javascript charset=utf-8
 // 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);
 }
 /script
   /head
   body
 h1Example/h1
 button onclick=showSplash()Show/button
 button onclick=hideSplash()Hide/button
   /body
 /html
 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] [Commented] (CB-2102) InAppBrowser will not open PDFs on different pages


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

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

2013-01-11 Thread Brian LeRoux

http://goo.gl/fYW3J

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


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

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


 [ 
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


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

[jira] [Commented] (CB-1973) console.log should only log once

2013-01-11 Thread JIRA


[ 
https://issues.apache.org/jira/browse/CB-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (CB-2102) InAppBrowser will not open PDFs on different pages

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

Andrew Grieve commented on CB-2102:
---

Does your main page reload at any point? The bridge caches the number in the
brackets on the first call to exec(), so even if the UA changed afterwards I
wouldn't expect the bridge to stop working.

InAppBrowser will not open PDFs on different pages
--

Attachments: cdv230 copy.zip, www-cb-2102.zip

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

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

Attachments: cdv230 copy.zip, www-cb-2102.zip

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