[jira] [Commented] (CB-5454) Plugin Mapping Issue

2015-07-31 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-5454:
---

{quote}the work around is to manually add plugin's *.m source files to Compiled 
Sources.{quote}

OMG you are my hero. I was totally stuck on this annoying ERROR: Plugin 
'StatusBar' not found, or is not a CDVPlugin. Check your plugin mapping in 
config.xml. issue (except my issue was with GAPlugin) and THIS is what got it 
finally working. Dear God why does it always have to be so painful to get 
plugins, Xcode, cordova working every few months!!!  In any case - THANK YOU 
for sharing this. 

 Plugin Mapping Issue
 

 Key: CB-5454
 URL: https://issues.apache.org/jira/browse/CB-5454
 Project: Apache Cordova
  Issue Type: Bug
  Components: CLI, iOS, Plugins
Affects Versions: 3.1.0
 Environment: iOS
Reporter: Mike Hartington
Assignee: Braden Shepherdson
  Labels: cli, config.xml,, cordova, cordova-cli
 Fix For: 3.2.0


 Once I've removed a plugin, I'm unable to add any plugins back again. So from 
 the command line,
 cordova plugin rm org.apache.cordova.device
 cordova plugin add org.apache.cordova.device
 Everything installs properly but once I go into Xcode and run the project, my 
 console puts out 
 2013-11-20 14:59:28.301 ProductDemo[65497:a0b] CDVPlugin class CDVStatusBar 
 (pluginName: StatusBar) does not exist.
 2013-11-20 14:59:28.302 ProductDemo[65497:a0b] ERROR: Plugin 'StatusBar' not 
 found, or is not a CDVPlugin. Check your plugin mapping in config.xml.
 2013-11-20 14:59:28.303 ProductDemo[65497:a0b] -[CDVCommandQueue 
 executePending] [Line 117] FAILED pluginJSON = [
   INVALID,
   StatusBar,
   overlaysWebView,
   [
 true
   ]
 ]
 I've run thought the debugging option and no errors come up so I'm not sure 
 what the issue is,  but my config.xml is correct and everything is copied 
 over as far as files go. Anyone have this issue too?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Created] (CB-8527) Please add pgbomit functionality to the PhoneGap/Cordova CLI

2015-02-23 Thread Chris Emerson (JIRA)
Chris Emerson created CB-8527:
-

 Summary: Please add pgbomit functionality to the PhoneGap/Cordova 
CLI
 Key: CB-8527
 URL: https://issues.apache.org/jira/browse/CB-8527
 Project: Apache Cordova
  Issue Type: Improvement
  Components: CLI
Reporter: Chris Emerson


Per the docs from PhoneGap Build here: 
http://phonegap.com/blog/2014/04/11/phonegap-build-adds-some-new-features/#pgbomit

Please add something similar for CLI, non-PhoneGap Build users, to be able to 
exclude folders from a build w/out having to figure out/implement strange hooks 
in each project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-5890) Media won't play local file on iOS

2015-02-23 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-5890:
---

FWIW I also got this once (error very similar) when the file (URL) path was 
pointing to a non-existent mp3.

 Media won't play local file on iOS
 --

 Key: CB-5890
 URL: https://issues.apache.org/jira/browse/CB-5890
 Project: Apache Cordova
  Issue Type: Bug
  Components: Plugin Media
Affects Versions: 3.3.0
 Environment: iOS
Reporter: John M. Wargo

 I have an application that will play a media file on Android, but not on iOS. 
 When I try to play the file, the console indicates that it can find the file, 
 but fails on opening it:
 Failed to initialize AVAudioPlayer
 Here's some console entries:
 2014-01-24 08:49:51.374 Ex141[386:60b] Entering doPlay
 2014-01-24 08:49:51.376 Ex141[386:60b] Found resource 
 '/var/mobile/Applications/C557863E-BB8C-4384-8188-9C36B5B603C4/Ex141.app/www/sample.mp3'
  in the web folder.
 2014-01-24 08:49:51.391 Ex141[386:60b] Failed to initialize AVAudioPlayer: 
 The operation couldn’t be completed. (OSStatus error 1685348671.)
 2014-01-24 08:49:51.394 Ex141[386:60b] THREAD WARNING: ['Media'] took 
 '18.647949' ms. Plugin should use a background thread.
 2014-01-24 08:49:51.396 Ex141[386:60b] Leaving doPlay
 2014-01-24 08:49:51.397 Ex141[386:60b] ERROR: Entering mediaError
 2014-01-24 08:49:51.398 Ex141[386:60b] ERROR: {message:,code:4}
 Notice that the message string is blank. 
 This is my code:
 theFile = 'sample.mp3';
 theMedia = new Media(theFile, mediaSuccess, mediaError, mediaStatus);
 theMedia.play();



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-7606) handleOpenURL handler firing more than necessary

2015-02-20 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-7606:
---

Anyone else seeing the cold start issue return after/as-of Cordova 4.2? 
Hopefully I'm just screwing up the fix but it sure seems like it might be back.

 handleOpenURL handler firing more than necessary
 

 Key: CB-7606
 URL: https://issues.apache.org/jira/browse/CB-7606
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 3.5.0
Reporter: Paul Kane
Assignee: Shazron Abdullah
 Fix For: 3.8.0


 I'm not an Obj-C or Cordova programmer so bear with me.
 Let's say my app is running. Then I hop over to my mail app and click on a 
 link (myapp://blahBlahBlah) that should open up my app. This works fine, the 
 app opens, my own URL handler (in javascript) takes over, etc.
 However in Obj-C the view controller is -- incorrectly, I believe -- storing 
 that scheme data (blahBlahBlah) in self.openURL (so that it can be picked up 
 later in processOpenURL function, called during webView initialization).
 This isn't normally a problem, except when you move to a new page 
 (window.href = /new_page), the webView initialization runs again and picks 
 up the old (already-acted-upon) openURL variable. (it's then set to nil, so 
 that it doesn't get acted upon a third time, fourth time, etc...).
 I might have some details wrong, but it should be fairly easy to walk through 
 with a project-wide search for openurl. Just seems like a slightly wrong 
 logic-flow, which unfortunately is interfering with my app.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Comment Edited] (CB-7606) handleOpenURL handler firing more than necessary

2015-02-20 Thread Chris Emerson (JIRA)

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

Chris Emerson edited comment on CB-7606 at 2/20/15 7:02 PM:


Anyone else seeing the cold start issue return after/as-of Cordova 4.2? 
Hopefully I'm just screwing up the fix but it sure seems like it might be back. 
 Because for me that timeout that Shazron posted in his fix is not firing on 
cold starts ... only after the app is opened. 


was (Author: chrisemersonnc):
Anyone else seeing the cold start issue return after/as-of Cordova 4.2? 
Hopefully I'm just screwing up the fix but it sure seems like it might be back.

 handleOpenURL handler firing more than necessary
 

 Key: CB-7606
 URL: https://issues.apache.org/jira/browse/CB-7606
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 3.5.0
Reporter: Paul Kane
Assignee: Shazron Abdullah
 Fix For: 3.8.0


 I'm not an Obj-C or Cordova programmer so bear with me.
 Let's say my app is running. Then I hop over to my mail app and click on a 
 link (myapp://blahBlahBlah) that should open up my app. This works fine, the 
 app opens, my own URL handler (in javascript) takes over, etc.
 However in Obj-C the view controller is -- incorrectly, I believe -- storing 
 that scheme data (blahBlahBlah) in self.openURL (so that it can be picked up 
 later in processOpenURL function, called during webView initialization).
 This isn't normally a problem, except when you move to a new page 
 (window.href = /new_page), the webView initialization runs again and picks 
 up the old (already-acted-upon) openURL variable. (it's then set to nil, so 
 that it doesn't get acted upon a third time, fourth time, etc...).
 I might have some details wrong, but it should be fairly easy to walk through 
 with a project-wide search for openurl. Just seems like a slightly wrong 
 logic-flow, which unfortunately is interfering with my app.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Comment Edited] (CB-7606) handleOpenURL handler firing more than necessary

2015-02-20 Thread Chris Emerson (JIRA)

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

Chris Emerson edited comment on CB-7606 at 2/20/15 7:09 PM:


Anyone else seeing the cold start issue return after/as-of the most recent 
version of Cordova? Hopefully I'm just screwing up the fix but it sure seems 
like it might be back.  Because for me that timeout that Shazron posted in his 
fix is not firing on cold starts ... only after the app is opened. 


was (Author: chrisemersonnc):
Anyone else seeing the cold start issue return after/as-of Cordova 4.2? 
Hopefully I'm just screwing up the fix but it sure seems like it might be back. 
 Because for me that timeout that Shazron posted in his fix is not firing on 
cold starts ... only after the app is opened. 

 handleOpenURL handler firing more than necessary
 

 Key: CB-7606
 URL: https://issues.apache.org/jira/browse/CB-7606
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 3.5.0
Reporter: Paul Kane
Assignee: Shazron Abdullah
 Fix For: 3.8.0


 I'm not an Obj-C or Cordova programmer so bear with me.
 Let's say my app is running. Then I hop over to my mail app and click on a 
 link (myapp://blahBlahBlah) that should open up my app. This works fine, the 
 app opens, my own URL handler (in javascript) takes over, etc.
 However in Obj-C the view controller is -- incorrectly, I believe -- storing 
 that scheme data (blahBlahBlah) in self.openURL (so that it can be picked up 
 later in processOpenURL function, called during webView initialization).
 This isn't normally a problem, except when you move to a new page 
 (window.href = /new_page), the webView initialization runs again and picks 
 up the old (already-acted-upon) openURL variable. (it's then set to nil, so 
 that it doesn't get acted upon a third time, fourth time, etc...).
 I might have some details wrong, but it should be fairly easy to walk through 
 with a project-wide search for openurl. Just seems like a slightly wrong 
 logic-flow, which unfortunately is interfering with my app.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-7606) handleOpenURL handler firing more than necessary

2015-02-20 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-7606:
---


Just an update ... I manually updated my Cordova files w/the updates here and 
that appears to fix the cold-start problem. When are these files going to be 
rolled into the current/latest Cordova version? 

Side/related question - When I run cordova --version I get 4.2 not 3.8 (?)... 
what am I missing/confusing here?

 handleOpenURL handler firing more than necessary
 

 Key: CB-7606
 URL: https://issues.apache.org/jira/browse/CB-7606
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 3.5.0
Reporter: Paul Kane
Assignee: Shazron Abdullah
 Fix For: 3.8.0


 I'm not an Obj-C or Cordova programmer so bear with me.
 Let's say my app is running. Then I hop over to my mail app and click on a 
 link (myapp://blahBlahBlah) that should open up my app. This works fine, the 
 app opens, my own URL handler (in javascript) takes over, etc.
 However in Obj-C the view controller is -- incorrectly, I believe -- storing 
 that scheme data (blahBlahBlah) in self.openURL (so that it can be picked up 
 later in processOpenURL function, called during webView initialization).
 This isn't normally a problem, except when you move to a new page 
 (window.href = /new_page), the webView initialization runs again and picks 
 up the old (already-acted-upon) openURL variable. (it's then set to nil, so 
 that it doesn't get acted upon a third time, fourth time, etc...).
 I might have some details wrong, but it should be fairly easy to walk through 
 with a project-wide search for openurl. Just seems like a slightly wrong 
 logic-flow, which unfortunately is interfering with my app.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-8036) Cannot update to 3.7.0

2015-02-13 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-8036:
---

Ditto. I was about to go postal if I had to rm/add my platform again - this 
saved me from doing that. THANK YOU! 

 Cannot update to 3.7.0
 --

 Key: CB-8036
 URL: https://issues.apache.org/jira/browse/CB-8036
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 3.7.0
 Environment: OS X Maverics (10.9.5) with XCode 6
Reporter: Hirbod
Assignee: Andrew Grieve
 Fix For: 3.8.0


 Hi,
 before 3.7.0 I could update without any problems from 3.5.0 to 3.6.3
 I tried to update from 3.6.3 to 3.7.0 but now I receive this error:
 cordova platform update ios
 module.js:340
 throw err;
   ^
 Error: Cannot find module 'shelljs'
 at Function.Module._resolveFilename (module.js:338:15)
 at Function.Module._load (module.js:280:25)
 at Module.require (module.js:364:17)
 at require (module.js:380:17)
 at Object.anonymous 
 (/Users/Hirbod/.cordova/lib/npm_cache/cordova-ios/3.7.0/package/bin/update:21:13)
 at Module._compile (module.js:456:26)
 at Object.Module._extensions..js (module.js:474:10)
 at Module.load (module.js:356:32)
 at Function.Module._load (module.js:312:12)
 at Function.Module.runMain (module.js:497:10)
 Error: 
 /Users/Hirbod/.cordova/lib/npm_cache/cordova-ios/3.7.0/package/bin/update: 
 Command failed with exit code 8
 at ChildProcess.whenDone 
 (/usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/cordova/superspawn.js:135:23)
 at ChildProcess.emit (events.js:98:17)
 at maybeClose (child_process.js:756:16)
 at Process.ChildProcess._handle.onexit (child_process.js:823:5)
 I tried to reinstall shelljs locally and globally but I can't figure out this 
 bug.
 Update for Android to version 3.6.4 worked without any problems.
 Of course I've updated phonegap and cordova before (like described in the CLI 
 Docs on phonegap.com)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Comment Edited] (CB-7716) Alert Dialog not working in Android API =11

2014-10-29 Thread Chris Emerson (JIRA)

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

Chris Emerson edited comment on CB-7716 at 10/29/14 11:10 AM:
--

For the record - my issue *may* have been unrelated. It appears my prompt 
method started working again on Android 2.3 once I went from this:

bq. myPrompt(msg,title,function(){ /* do stuff */},labels); 

to this:

bq. myPrompt(msg,title,functionName,labels); 


was (Author: chrisemersonnc):
For the record - my issue *may* have been unrelated. It appears my prompt 
method started working again on Android 2.3 once I went from this:

myPrompt(msg,title,function(){ /* do stuff */},labels); 

to this:

myPrompt(msg,title,functionName,labels); 

 Alert Dialog not working in Android API =11
 

 Key: CB-7716
 URL: https://issues.apache.org/jira/browse/CB-7716
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android, Plugin Dialogs
Affects Versions: 3.6.0
Reporter: Keshav OS
Assignee: Joe Bowser

 Works on android API14 (4.0+). However, the following issue is when 
 targeting only API 10 (2.3.3 and 2.3.4). 
 1. Updated platforms/android/AndroidManifest.xml to 
 uses-sdk android:minSdkVersion=10 android:targetSdkVersion=10 /
 2. Added dialogs plugin to make use of custom alert, confirm boxes through 
 the cli
 cordova plugin add org.apache.cordova.dialogs
 Installs successfully on the device. However the dialogs don't show up as 
 expected. Logcat reveals the following error:
 bq. 10-06 11:00:18.469: D/CordovaLog(7719): : Line 1772609 : No device 
 specific handleNewLine procedure
 10-06 11:00:18.469: I/Web Console(7719): No device specific handleNewLine 
 procedure at :1772609
 10-06 11:00:18.479: W/dalvikvm(7719): VFY: unable to resolve direct method 
 29: Landroid/app/AlertDialog$Builder;.init (Landroid/content/Context;I)V
 10-06 11:00:18.479: W/System.err(7719): java.lang.NoSuchMethodError: 
 android.app.AlertDialog$Builder.init
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.dialogs.Notification$2.run(Notification.java:160)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.app.Activity.runOnUiThread(Activity.java:3717)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.dialogs.Notification.alert(Notification.java:185)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.dialogs.Notification.execute(Notification.java:79)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaPlugin.execute(CordovaPlugin.java:84)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.PluginManager.exec(PluginManager.java:147)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaBridge.jsExec(CordovaBridge.java:59)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaBridge.promptOnJsPrompt(CordovaBridge.java:129)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaChromeClient.onJsPrompt(CordovaChromeClient.java:192)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.webkit.CallbackProxy.handleMessage(CallbackProxy.java:580)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.os.Handler.dispatchMessage(Handler.java:99)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.os.Looper.loop(Looper.java:130)
 10-06 11:00:18.489: W/System.err(7719):   at 
 android.app.ActivityThread.main(ActivityThread.java:3687)
 10-06 11:00:18.489: W/System.err(7719):   at 
 java.lang.reflect.Method.invokeNative(Native Method)
 10-06 11:00:18.489: W/System.err(7719):   at 
 java.lang.reflect.Method.invoke(Method.java:507)
 10-06 11:00:18.489: W/System.err(7719):   at 
 com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
 10-06 11:00:18.489: W/System.err(7719):   at 
 com.android.internal.os.ZygoteInit.main(ZygoteInit.java:625)
 10-06 11:00:18.489: W/System.err(7719):   at 
 dalvik.system.NativeStart.main(Native Method)
 10-06 11:00:18.499: D/CONTEXT(7719): m_mainFrame-editor()-hasComposition 
 not 
 10-06 11:00:18.539: D/CONTEXT(7719): m_mainFrame-editor()-hasComposition 
 not 
 10-06 11:00:18.549: D/CONTEXT(7719): m_mainFrame-editor()-hasComposition 
 not 
 Have tried using v0.2.8, 0.2.9, 0.2.10 and the same issue exists. 
 Running the cordova clean utility, remove and adding the plugin, setting 
 android target to 10 in project.properties, none of these seem to fix the 
 issue. 
 Have also tried all proposed and pending PR's related to this issue, but none 
 of the solutions work. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: 

[jira] [Commented] (CB-7716) Alert Dialog not working in Android API =11

2014-10-28 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-7716:
---

Has the notifications (?https://github.com/apache/cordova-plugin-dialogs) 
plugin been updated with this fix? 

 Alert Dialog not working in Android API =11
 

 Key: CB-7716
 URL: https://issues.apache.org/jira/browse/CB-7716
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android, Plugin Dialogs
Affects Versions: 3.6.0
Reporter: Keshav OS
Assignee: Joe Bowser

 Works on android API14 (4.0+). However, the following issue is when 
 targeting only API 10 (2.3.3 and 2.3.4). 
 1. Updated platforms/android/AndroidManifest.xml to 
 uses-sdk android:minSdkVersion=10 android:targetSdkVersion=10 /
 2. Added dialogs plugin to make use of custom alert, confirm boxes through 
 the cli
 cordova plugin add org.apache.cordova.dialogs
 Installs successfully on the device. However the dialogs don't show up as 
 expected. Logcat reveals the following error:
 bq. 10-06 11:00:18.469: D/CordovaLog(7719): : Line 1772609 : No device 
 specific handleNewLine procedure
 10-06 11:00:18.469: I/Web Console(7719): No device specific handleNewLine 
 procedure at :1772609
 10-06 11:00:18.479: W/dalvikvm(7719): VFY: unable to resolve direct method 
 29: Landroid/app/AlertDialog$Builder;.init (Landroid/content/Context;I)V
 10-06 11:00:18.479: W/System.err(7719): java.lang.NoSuchMethodError: 
 android.app.AlertDialog$Builder.init
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.dialogs.Notification$2.run(Notification.java:160)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.app.Activity.runOnUiThread(Activity.java:3717)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.dialogs.Notification.alert(Notification.java:185)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.dialogs.Notification.execute(Notification.java:79)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaPlugin.execute(CordovaPlugin.java:84)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.PluginManager.exec(PluginManager.java:147)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaBridge.jsExec(CordovaBridge.java:59)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaBridge.promptOnJsPrompt(CordovaBridge.java:129)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaChromeClient.onJsPrompt(CordovaChromeClient.java:192)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.webkit.CallbackProxy.handleMessage(CallbackProxy.java:580)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.os.Handler.dispatchMessage(Handler.java:99)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.os.Looper.loop(Looper.java:130)
 10-06 11:00:18.489: W/System.err(7719):   at 
 android.app.ActivityThread.main(ActivityThread.java:3687)
 10-06 11:00:18.489: W/System.err(7719):   at 
 java.lang.reflect.Method.invokeNative(Native Method)
 10-06 11:00:18.489: W/System.err(7719):   at 
 java.lang.reflect.Method.invoke(Method.java:507)
 10-06 11:00:18.489: W/System.err(7719):   at 
 com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
 10-06 11:00:18.489: W/System.err(7719):   at 
 com.android.internal.os.ZygoteInit.main(ZygoteInit.java:625)
 10-06 11:00:18.489: W/System.err(7719):   at 
 dalvik.system.NativeStart.main(Native Method)
 10-06 11:00:18.499: D/CONTEXT(7719): m_mainFrame-editor()-hasComposition 
 not 
 10-06 11:00:18.539: D/CONTEXT(7719): m_mainFrame-editor()-hasComposition 
 not 
 10-06 11:00:18.549: D/CONTEXT(7719): m_mainFrame-editor()-hasComposition 
 not 
 Have tried using v0.2.8, 0.2.9, 0.2.10 and the same issue exists. 
 Running the cordova clean utility, remove and adding the plugin, setting 
 android target to 10 in project.properties, none of these seem to fix the 
 issue. 
 Have also tried all proposed and pending PR's related to this issue, but none 
 of the solutions work. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-7716) Alert Dialog not working in Android API =11

2014-10-28 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-7716:
---

My initiaattempt after grabbing latest doesn't seem to have fixed the issue-but 
I'll confirm tomorrow morning. I'm not 100% sure my issue is exactly what this 
bug is describing-insured my issue is that android phones running 2.3 seem to 
be ignoring my prompt method calls - calls that appear to be working in android 
4.x and iOS 7 and 8.    

- Chri

 Alert Dialog not working in Android API =11
 

 Key: CB-7716
 URL: https://issues.apache.org/jira/browse/CB-7716
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android, Plugin Dialogs
Affects Versions: 3.6.0
Reporter: Keshav OS
Assignee: Joe Bowser

 Works on android API14 (4.0+). However, the following issue is when 
 targeting only API 10 (2.3.3 and 2.3.4). 
 1. Updated platforms/android/AndroidManifest.xml to 
 uses-sdk android:minSdkVersion=10 android:targetSdkVersion=10 /
 2. Added dialogs plugin to make use of custom alert, confirm boxes through 
 the cli
 cordova plugin add org.apache.cordova.dialogs
 Installs successfully on the device. However the dialogs don't show up as 
 expected. Logcat reveals the following error:
 bq. 10-06 11:00:18.469: D/CordovaLog(7719): : Line 1772609 : No device 
 specific handleNewLine procedure
 10-06 11:00:18.469: I/Web Console(7719): No device specific handleNewLine 
 procedure at :1772609
 10-06 11:00:18.479: W/dalvikvm(7719): VFY: unable to resolve direct method 
 29: Landroid/app/AlertDialog$Builder;.init (Landroid/content/Context;I)V
 10-06 11:00:18.479: W/System.err(7719): java.lang.NoSuchMethodError: 
 android.app.AlertDialog$Builder.init
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.dialogs.Notification$2.run(Notification.java:160)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.app.Activity.runOnUiThread(Activity.java:3717)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.dialogs.Notification.alert(Notification.java:185)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.dialogs.Notification.execute(Notification.java:79)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaPlugin.execute(CordovaPlugin.java:84)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.PluginManager.exec(PluginManager.java:147)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaBridge.jsExec(CordovaBridge.java:59)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaBridge.promptOnJsPrompt(CordovaBridge.java:129)
 10-06 11:00:18.479: W/System.err(7719):   at 
 org.apache.cordova.CordovaChromeClient.onJsPrompt(CordovaChromeClient.java:192)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.webkit.CallbackProxy.handleMessage(CallbackProxy.java:580)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.os.Handler.dispatchMessage(Handler.java:99)
 10-06 11:00:18.479: W/System.err(7719):   at 
 android.os.Looper.loop(Looper.java:130)
 10-06 11:00:18.489: W/System.err(7719):   at 
 android.app.ActivityThread.main(ActivityThread.java:3687)
 10-06 11:00:18.489: W/System.err(7719):   at 
 java.lang.reflect.Method.invokeNative(Native Method)
 10-06 11:00:18.489: W/System.err(7719):   at 
 java.lang.reflect.Method.invoke(Method.java:507)
 10-06 11:00:18.489: W/System.err(7719):   at 
 com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
 10-06 11:00:18.489: W/System.err(7719):   at 
 com.android.internal.os.ZygoteInit.main(ZygoteInit.java:625)
 10-06 11:00:18.489: W/System.err(7719):   at 
 dalvik.system.NativeStart.main(Native Method)
 10-06 11:00:18.499: D/CONTEXT(7719): m_mainFrame-editor()-hasComposition 
 not 
 10-06 11:00:18.539: D/CONTEXT(7719): m_mainFrame-editor()-hasComposition 
 not 
 10-06 11:00:18.549: D/CONTEXT(7719): m_mainFrame-editor()-hasComposition 
 not 
 Have tried using v0.2.8, 0.2.9, 0.2.10 and the same issue exists. 
 Running the cordova clean utility, remove and adding the plugin, setting 
 android target to 10 in project.properties, none of these seem to fix the 
 issue. 
 Have also tried all proposed and pending PR's related to this issue, but none 
 of the solutions work. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Comment Edited] (CB-7291) Externally-launchable applications should be configurable

2014-10-21 Thread Chris Emerson (JIRA)

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

Chris Emerson edited comment on CB-7291 at 10/21/14 1:05 PM:
-

Thanks for the reply Marcel. So glad to hear 3.6.0 is out even though I can't 
see it on the PhoneGap website - I will npm info soon and try that out. Thank 
you!

PS: I'm in the RDU area too - small world!




was (Author: chrisemersonnc):
Thanks for the reply Marcel. I'm using PhoneGap, not Cordova, in this case so I 
can't just update (AFAIK?) since PhoneGap doesn't yet have a fix for this in a 
public build - https://twitter.com/emerson_chris/status/521726447858507776 

I'd really prefer to not have to move from PhoneGap to Cordova - but at the 
moment sounds like the only way I'll get my app past this security issue Google 
is complaining about?

PS: I'm in the RDU area too - small world!



 Externally-launchable applications should be configurable
 -

 Key: CB-7291
 URL: https://issues.apache.org/jira/browse/CB-7291
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 3.5.0
Reporter: Ian Clelland
Assignee: Ian Clelland
Priority: Blocker
 Fix For: 3.6.0


 Cordova Android versions up to 3.5.0 would launch any and all external 
 applications by URL. Any URL not explicitly whitelisted was sent to the 
 Android intent system for handling. This was the cause of the security 
 vulnerabilities reported by IBM and disclosed in CVE-2014-3502.
 Cordova Android 3.5.1 was released to fix this, which it did by disabling 
 explicit intents, and explaining how to use a plugin to block other URL 
 schemes if desired.
 We want to have a better official solution than this, so that developers can 
 easily configure which applications (sms, email, maps, etc) should be 
 launchable from their Cordova app.
 *Proposal*
 The proposed solution is to maintain a second whitelist within the app, for 
 URL patterns which may be used to launch external applications. Then, on URL 
 loading, these tests will occur (in order):
 # URLs which are whitelisted internally (existing list) will cause internal 
 navigation
 # URLs which are whitelisted externally (new list) will attempt to launch an 
 intent to handle it
 # URLs which are not whitelisted at all (in neither list) will be blocked.
 *Configuration*
 URLs can be added to the new (external) whitelist through an extension to the 
 {{config.xml}} whitelist syntax:
 {code}
 access origin=sms:* launch-external=yes /
 {code}
 (Any non-empty value for the {{launch-external}} attribute will be considered 
 true when parsing the {{config.xml}} file)
 *Open questions* (one about forward-thinking security, the other about 
 backwards-compatibility):
 # What should the default external whitelist be in the application template 
 that we ship? This will be the case for new apps build with 3.6.0.
 # What should the default external whitelist be when there are no {{access 
 launch-external=yes}} tags in {{config.xml}}? This will be the case for 
 apps which are upgrading to 3.6.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-7291) Externally-launchable applications should be configurable

2014-10-21 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-7291:
---

Thanks for the reply Marcel. I'm using PhoneGap, not Cordova, in this case so I 
can't just update (AFAIK?) since PhoneGap doesn't yet have a fix for this in a 
public build - https://twitter.com/emerson_chris/status/521726447858507776 

I'd really prefer to not have to move from PhoneGap to Cordova - but at the 
moment sounds like the only way I'll get my app past this security issue Google 
is complaining about?

PS: I'm in the RDU area too - small world!



 Externally-launchable applications should be configurable
 -

 Key: CB-7291
 URL: https://issues.apache.org/jira/browse/CB-7291
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 3.5.0
Reporter: Ian Clelland
Assignee: Ian Clelland
Priority: Blocker
 Fix For: 3.6.0


 Cordova Android versions up to 3.5.0 would launch any and all external 
 applications by URL. Any URL not explicitly whitelisted was sent to the 
 Android intent system for handling. This was the cause of the security 
 vulnerabilities reported by IBM and disclosed in CVE-2014-3502.
 Cordova Android 3.5.1 was released to fix this, which it did by disabling 
 explicit intents, and explaining how to use a plugin to block other URL 
 schemes if desired.
 We want to have a better official solution than this, so that developers can 
 easily configure which applications (sms, email, maps, etc) should be 
 launchable from their Cordova app.
 *Proposal*
 The proposed solution is to maintain a second whitelist within the app, for 
 URL patterns which may be used to launch external applications. Then, on URL 
 loading, these tests will occur (in order):
 # URLs which are whitelisted internally (existing list) will cause internal 
 navigation
 # URLs which are whitelisted externally (new list) will attempt to launch an 
 intent to handle it
 # URLs which are not whitelisted at all (in neither list) will be blocked.
 *Configuration*
 URLs can be added to the new (external) whitelist through an extension to the 
 {{config.xml}} whitelist syntax:
 {code}
 access origin=sms:* launch-external=yes /
 {code}
 (Any non-empty value for the {{launch-external}} attribute will be considered 
 true when parsing the {{config.xml}} file)
 *Open questions* (one about forward-thinking security, the other about 
 backwards-compatibility):
 # What should the default external whitelist be in the application template 
 that we ship? This will be the case for new apps build with 3.6.0.
 # What should the default external whitelist be when there are no {{access 
 launch-external=yes}} tags in {{config.xml}}? This will be the case for 
 apps which are upgrading to 3.6.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-7291) Externally-launchable applications should be configurable

2014-10-21 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-7291:
---

Thanks again, [~cmarcelk]. I've updated via CLI and my projects are now at 
3.6.0.x (PhoneGap) - so I should be good to go now. Thanks!

 Externally-launchable applications should be configurable
 -

 Key: CB-7291
 URL: https://issues.apache.org/jira/browse/CB-7291
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 3.5.0
Reporter: Ian Clelland
Assignee: Ian Clelland
Priority: Blocker
 Fix For: 3.6.0


 Cordova Android versions up to 3.5.0 would launch any and all external 
 applications by URL. Any URL not explicitly whitelisted was sent to the 
 Android intent system for handling. This was the cause of the security 
 vulnerabilities reported by IBM and disclosed in CVE-2014-3502.
 Cordova Android 3.5.1 was released to fix this, which it did by disabling 
 explicit intents, and explaining how to use a plugin to block other URL 
 schemes if desired.
 We want to have a better official solution than this, so that developers can 
 easily configure which applications (sms, email, maps, etc) should be 
 launchable from their Cordova app.
 *Proposal*
 The proposed solution is to maintain a second whitelist within the app, for 
 URL patterns which may be used to launch external applications. Then, on URL 
 loading, these tests will occur (in order):
 # URLs which are whitelisted internally (existing list) will cause internal 
 navigation
 # URLs which are whitelisted externally (new list) will attempt to launch an 
 intent to handle it
 # URLs which are not whitelisted at all (in neither list) will be blocked.
 *Configuration*
 URLs can be added to the new (external) whitelist through an extension to the 
 {{config.xml}} whitelist syntax:
 {code}
 access origin=sms:* launch-external=yes /
 {code}
 (Any non-empty value for the {{launch-external}} attribute will be considered 
 true when parsing the {{config.xml}} file)
 *Open questions* (one about forward-thinking security, the other about 
 backwards-compatibility):
 # What should the default external whitelist be in the application template 
 that we ship? This will be the case for new apps build with 3.6.0.
 # What should the default external whitelist be when there are no {{access 
 launch-external=yes}} tags in {{config.xml}}? This will be the case for 
 apps which are upgrading to 3.6.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-6407) [Android] InAppBrowser 0.3.3 Crashes App on Android 4.4.2

2014-10-21 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-6407:
---

+1 to Marcel's manual workaround working.

 [Android] InAppBrowser 0.3.3 Crashes App on Android 4.4.2
 -

 Key: CB-6407
 URL: https://issues.apache.org/jira/browse/CB-6407
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 3.4.0
 Environment: Nexus 5 running Android 4.4.2 with Cordova 3.4.0-0.1.3 
 and inAppBrowser plugin version 0.3.3
Reporter: Sean Abrahams

 window.open('http://cordova.apache.org/', '_blank', 'location=yes')
 Results in the following exception:
 04-04 20:10:34.824: D/CordovaNetworkManager(10617): Connection Type: wifi
 04-04 20:10:37.644: D/InAppBrowser(10617): target = _blank
 04-04 20:10:37.644: D/InAppBrowser(10617): in blank
 04-04 20:10:37.654: W/ResourceType(10617): No package identifier when getting 
 value for resource number 0x
 04-04 20:10:37.654: D/AndroidRuntime(10617): Shutting down VM
 04-04 20:10:37.654: W/dalvikvm(10617): threadid=1: thread exiting with 
 uncaught exception (group=0x4161aba8)
 04-04 20:10:37.654: E/AndroidRuntime(10617): FATAL EXCEPTION: main
 04-04 20:10:37.654: E/AndroidRuntime(10617): Process: 
 com.bugreport.bugreport, PID: 10617
 04-04 20:10:37.654: E/AndroidRuntime(10617): 
 android.content.res.Resources$NotFoundException: Resource ID #0x0
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 android.content.res.Resources.getValue(Resources.java:1123)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 android.content.res.Resources.getDrawable(Resources.java:698)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 org.apache.cordova.inappbrowser.InAppBrowser$5.run(InAppBrowser.java:493)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 android.app.Activity.runOnUiThread(Activity.java:4713)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 org.apache.cordova.inappbrowser.InAppBrowser.showWebPage(InAppBrowser.java:647)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 org.apache.cordova.inappbrowser.InAppBrowser$1.run(InAppBrowser.java:150)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 android.os.Handler.handleCallback(Handler.java:733)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 android.os.Handler.dispatchMessage(Handler.java:95)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 android.os.Looper.loop(Looper.java:136)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 android.app.ActivityThread.main(ActivityThread.java:5017)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 java.lang.reflect.Method.invokeNative(Native Method)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 java.lang.reflect.Method.invoke(Method.java:515)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
 04-04 20:10:37.654: E/AndroidRuntime(10617):  at 
 dalvik.system.NativeStart.main(Native Method)
 04-04 20:10:52.894: I/Process(10617): Sending signal. PID: 10617 SIG: 9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-3325) Add PDF support to the InAppBrowser within Android

2014-10-17 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-3325:
---

Sadly not that I'm aware of. Somehow it is still impossible to freaking show a 
PDF in any kind of Android webview. Insane!

 Add PDF support to the InAppBrowser within Android
 --

 Key: CB-3325
 URL: https://issues.apache.org/jira/browse/CB-3325
 Project: Apache Cordova
  Issue Type: Improvement
  Components: Android
Affects Versions: 2.6.0
 Environment: Windows 7, Eclipse v3.8.0
Reporter: Kelvin Dart
Priority: Minor
 Fix For: Master


 When I was making use of the ChildBrowser for both iOS and Android, I wrote 
 an extra bit of code to enable PDF support for the Android version (which 
 started up the installed PDF application if there was one).
 I also understand that the Android WebView doesn't natively support viewing a 
 PDF document which is why it doesn't fully behave like the iOS version - but 
 is it possible to either: 1) write similar code which, if the opened URL is 
 directed to a PDF file, then it opens the native PDF reader or; 2) integrate 
 a PDF view into the InAppBrowser which opens a PDF document much like 
 InAppBrowser does on iOS.
 (1) is what I currently have working at the moment and would probably be 
 easiest. (2) is what would be very good but I expect more difficult to 
 achieve.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Comment Edited] (CB-3325) Add PDF support to the InAppBrowser within Android

2014-10-17 Thread Chris Emerson (JIRA)

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

Chris Emerson edited comment on CB-3325 at 10/17/14 7:02 PM:
-

Sadly not that I'm aware of. Somehow it is still impossible to freaking show a 
PDF in any kind of Android webview. Insane!

My current workaround is converting PDFs to PNGs... so lame but the only 
reasonable option/fallback for now. =/


was (Author: chrisemersonnc):
Sadly not that I'm aware of. Somehow it is still impossible to freaking show a 
PDF in any kind of Android webview. Insane!

 Add PDF support to the InAppBrowser within Android
 --

 Key: CB-3325
 URL: https://issues.apache.org/jira/browse/CB-3325
 Project: Apache Cordova
  Issue Type: Improvement
  Components: Android
Affects Versions: 2.6.0
 Environment: Windows 7, Eclipse v3.8.0
Reporter: Kelvin Dart
Priority: Minor
 Fix For: Master


 When I was making use of the ChildBrowser for both iOS and Android, I wrote 
 an extra bit of code to enable PDF support for the Android version (which 
 started up the installed PDF application if there was one).
 I also understand that the Android WebView doesn't natively support viewing a 
 PDF document which is why it doesn't fully behave like the iOS version - but 
 is it possible to either: 1) write similar code which, if the opened URL is 
 directed to a PDF file, then it opens the native PDF reader or; 2) integrate 
 a PDF view into the InAppBrowser which opens a PDF document much like 
 InAppBrowser does on iOS.
 (1) is what I currently have working at the moment and would probably be 
 easiest. (2) is what would be very good but I expect more difficult to 
 achieve.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-7291) Externally-launchable applications should be configurable

2014-10-15 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-7291:
---

Anyone able to respond to my previous comment? This is somewhat urgent as I 
don't want my app to get flagged/labeled as dangerous as gently threatened in 
the email I got from Google a few weeks ago (below). I would just update 
Cordova to 3.5.1 but my app is now using PhoneGap and I'd rather not risk going 
back to Cordova at this point as that normally creates a whole bunch of 
plugin/platform issues. 

=

Subject: Security Alert: Apache Cordova vulnerabilities in your Google 
Play app

This is a notification that your com.situational.isitlead, is built on 
a version of Apache Cordova that contains security vulnerabilities. This 
includes a high severity cross-application scripting (XAS) vulnerability. Under 
certain circumstances, vulnerable apps could be remotely exploited to steal 
sensitive information, such as user login credentials.

You should upgrade to Apache Cordova 3.5.1 or higher as soon as 
possible. For more information about the vulnerabilities, and for guidance on 
upgrading Apache Cordova, please see 
http://cordova.apache.org/announcements/2014/08/04/android-351.htmlhttp://www.google.com/appserve/mkt/p/4VJWfraOToNVpaGBpBZXXLlLQvvjnCSfTyQgLqZNujeukMviSDbiy1egsxQbTP7QGXlLrEn7Skw1zVTl7vTyiT7_NYpA38y6ZkdNL2FXkdEg6H4=.

Please note, applications with vulnerabilities that expose users to 
risk of compromise may be considered dangerous products and subject to 
removal from Google Play.

Regards,

Google Play Team

(c)2014 Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043

Email preferences: You have received this mandatory email service 
announcement to update you about important issues relating to your Google Play 
account.

 Externally-launchable applications should be configurable
 -

 Key: CB-7291
 URL: https://issues.apache.org/jira/browse/CB-7291
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 3.5.0
Reporter: Ian Clelland
Assignee: Ian Clelland
Priority: Blocker
 Fix For: 3.6.0


 Cordova Android versions up to 3.5.0 would launch any and all external 
 applications by URL. Any URL not explicitly whitelisted was sent to the 
 Android intent system for handling. This was the cause of the security 
 vulnerabilities reported by IBM and disclosed in CVE-2014-3502.
 Cordova Android 3.5.1 was released to fix this, which it did by disabling 
 explicit intents, and explaining how to use a plugin to block other URL 
 schemes if desired.
 We want to have a better official solution than this, so that developers can 
 easily configure which applications (sms, email, maps, etc) should be 
 launchable from their Cordova app.
 *Proposal*
 The proposed solution is to maintain a second whitelist within the app, for 
 URL patterns which may be used to launch external applications. Then, on URL 
 loading, these tests will occur (in order):
 # URLs which are whitelisted internally (existing list) will cause internal 
 navigation
 # URLs which are whitelisted externally (new list) will attempt to launch an 
 intent to handle it
 # URLs which are not whitelisted at all (in neither list) will be blocked.
 *Configuration*
 URLs can be added to the new (external) whitelist through an extension to the 
 {{config.xml}} whitelist syntax:
 {code}
 access origin=sms:* launch-external=yes /
 {code}
 (Any non-empty value for the {{launch-external}} attribute will be considered 
 true when parsing the {{config.xml}} file)
 *Open questions* (one about forward-thinking security, the other about 
 backwards-compatibility):
 # What should the default external whitelist be in the application template 
 that we ship? This will be the case for new apps build with 3.6.0.
 # What should the default external whitelist be when there are no {{access 
 launch-external=yes}} tags in {{config.xml}}? This will be the case for 
 apps which are upgrading to 3.6.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-7291) Externally-launchable applications should be configurable

2014-10-13 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-7291:
---

Any tips/advice on manually applying the fix for this [CVE-2014-3502] to the 
current version of PhoneGap / CLI (3.5.0-0.21.18)? 
Pardon my naivety here but if I piece together the commits above myself and 
apply to my local cordova.js would that suffice? Or not that simple/easy? 

Thanks. (Reference: From conversation with Raymond and Shazron: 
http://goo.gl/ovPeml )

PS: If this isn't the correct bug to ask this question please let me know

 Externally-launchable applications should be configurable
 -

 Key: CB-7291
 URL: https://issues.apache.org/jira/browse/CB-7291
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 3.5.0
Reporter: Ian Clelland
Assignee: Ian Clelland
Priority: Blocker
 Fix For: 3.6.0


 Cordova Android versions up to 3.5.0 would launch any and all external 
 applications by URL. Any URL not explicitly whitelisted was sent to the 
 Android intent system for handling. This was the cause of the security 
 vulnerabilities reported by IBM and disclosed in CVE-2014-3502.
 Cordova Android 3.5.1 was released to fix this, which it did by disabling 
 explicit intents, and explaining how to use a plugin to block other URL 
 schemes if desired.
 We want to have a better official solution than this, so that developers can 
 easily configure which applications (sms, email, maps, etc) should be 
 launchable from their Cordova app.
 *Proposal*
 The proposed solution is to maintain a second whitelist within the app, for 
 URL patterns which may be used to launch external applications. Then, on URL 
 loading, these tests will occur (in order):
 # URLs which are whitelisted internally (existing list) will cause internal 
 navigation
 # URLs which are whitelisted externally (new list) will attempt to launch an 
 intent to handle it
 # URLs which are not whitelisted at all (in neither list) will be blocked.
 *Configuration*
 URLs can be added to the new (external) whitelist through an extension to the 
 {{config.xml}} whitelist syntax:
 {code}
 access origin=sms:* launch-external=yes /
 {code}
 (Any non-empty value for the {{launch-external}} attribute will be considered 
 true when parsing the {{config.xml}} file)
 *Open questions* (one about forward-thinking security, the other about 
 backwards-compatibility):
 # What should the default external whitelist be in the application template 
 that we ship? This will be the case for new apps build with 3.6.0.
 # What should the default external whitelist be when there are no {{access 
 launch-external=yes}} tags in {{config.xml}}? This will be the case for 
 apps which are upgrading to 3.6.0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-4930) InAppBrowser should take into account the status bar

2014-10-03 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4930:
---

+1

 InAppBrowser should take into account the status bar
 

 Key: CB-4930
 URL: https://issues.apache.org/jira/browse/CB-4930
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS, Plugin InAppBrowser
Affects Versions: 3.0.0
Reporter: Shazron Abdullah
  Labels: ios7
 Fix For: 3.2.0


 Right now, the status bar overlaps the IAB at the top.
 Hide the status bar when on iOS 7, unhide (if it was hidden by the user in 
 the first place for the app only) when it is closed.
 Workaround for now - I suppose you could inject some css to have a body 
 margin-top of 20px (or a different value if it is landscape - yeah it could 
 get messy)
 Hiding/unhiding the status bar is preferable to moving the view down to be 
 consistent with the UIWebView taking up the whole window.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org



[jira] [Commented] (CB-4862) ios 7 keyboard resizes the page even with KeyboardShrinksView set to false

2014-03-28 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4862:
---

For whatever it's worth - viewports are still a sensitive/tedious topic. I have 
to maintain separate viewport tags for ANDROID and iOS otherwise crazy things 
happen. I realize this comment lacks tactical/actionable detail - mainly I'm 
just posting to find out if anyone is looking at removing this issue so we 
(Cordova/PhoneGap devs) can soon just pick ONE viewport tag and it magically 
works on all devices.

 ios 7 keyboard resizes the page even with KeyboardShrinksView set to false
 --

 Key: CB-4862
 URL: https://issues.apache.org/jira/browse/CB-4862
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.8.0
 Environment: ipod 5th gen ios 7 and simulator for ios 7
Reporter: Jake Williams
Assignee: Shazron Abdullah
  Labels: ios7, keyboard-plugin

 We have a page with a fixed footer and some inputs.  In previous ios versions 
 the page would be pushed up when an input was focused and the keyboard came 
 up.  In ios 7, the page height is reduced to the available space after the 
 keyboard appears and the footer covers the input (depends on the position of 
 the footer, but it does happen sometimes).  There is also a problem where the 
 input could be beneath the keyboard if you have multiple inputs and you use 
 next/previous to move between them.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (CB-6117) cdvfile file url is not working with html5 image src

2014-03-26 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-6117:
---

Will leaning on this .toNativeURL() break on newer Android/iOS File plugin 
usage? I was really liking the simple cdfvile:// pathing approach but if 
Android 2.x only works with this toNativeURL() method I guess we have no choie.

 cdvfile file url is not working with html5 image src
 

 Key: CB-6117
 URL: https://issues.apache.org/jira/browse/CB-6117
 Project: Apache Cordova
  Issue Type: Bug
  Components: Plugin File, Plugin File Transfer
Affects Versions: 3.4.0
 Environment: Appears to be Android  4.0.0
Reporter: rita
Assignee: Ian Clelland
Priority: Critical

 Hi 
 I had used the fileTranser APi to download the image from a given path.
 The image was downloaded at the path 
 cdvfile://localhost/persistent/SPB/ics-android.png.
 But I am unable to access this image as url for img tag in html.Same code 
 was working till 2.9.0



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (CB-3020) HideKeyboardFormAccessoryBar and KeyboardShrinksView show white bar instead of removing it

2014-01-31 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-3020:
---

Does that snippet from the dev branch mean this will soon no longer be an issue 
- i.e. It will behave as it did pre ios7?


- Chris


 HideKeyboardFormAccessoryBar and KeyboardShrinksView show white bar instead 
 of removing it
 --

 Key: CB-3020
 URL: https://issues.apache.org/jira/browse/CB-3020
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS, Plugins
Affects Versions: 2.6.0, 3.0.0
 Environment: ios 6.1.3
Reporter: Horst Perfect
Assignee: Shazron Abdullah
Priority: Minor
  Labels: keyboard-plugin
 Fix For: 3.1.0

 Attachments: Classes.zip, iOS Simulator Screen shot 2013-10-05 
 2.27.26 PM.png, iOS Simulator Screen shot 2013-10-05 2.27.36 PM.png, ios.zip


 I use phonegap 2.6 with the two new preferences HideKeyboardFormAccessoryBar 
 KeyboardShrinksView set to true. Instead of the AccessoryBar a white bar 
 appears ([screenshot|http://i.stack.imgur.com/3fgV8.png]).
 This is just happening when i set *both* of the preferences to true. When i 
 just set the AccessoryBar preference to true the bar disappears as planned.
 Horst



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (CB-4862) ios 7 keyboard resizes the page even with KeyboardShrinksView set to false

2014-01-28 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4862:
---

Thanks Shazron. Unfortunately hooks are just above my grasp at the moment - 
I've read some articles on them but I just don't get them yet (i.e. not sure 
how to really create/use them in even a general way let alone the specific way 
I'd need them for this issue). 

Any chance you can predict how this issue is going to pan out with Cordova? 
Will we have to have two different viewports for Android/iOS forever or will 
the ShrinkKeyboard behavior in iOS get fixed/reverted back to how it behaved 
prior to iOS7? Any insight you could share would help me plan things on my end. 
My main concern is that this loose end is going to remain a painful step in our 
deployment and testing process.

 ios 7 keyboard resizes the page even with KeyboardShrinksView set to false
 --

 Key: CB-4862
 URL: https://issues.apache.org/jira/browse/CB-4862
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.8.0
 Environment: ipod 5th gen ios 7 and simulator for ios 7
Reporter: Jake Williams
Assignee: Shazron Abdullah
  Labels: ios7, keyboard-plugin

 We have a page with a fixed footer and some inputs.  In previous ios versions 
 the page would be pushed up when an input was focused and the keyboard came 
 up.  In ios 7, the page height is reduced to the available space after the 
 keyboard appears and the footer covers the input (depends on the position of 
 the footer, but it does happen sometimes).  There is also a problem where the 
 input could be beneath the keyboard if you have multiple inputs and you use 
 next/previous to move between them.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (CB-4862) ios 7 keyboard resizes the page even with KeyboardShrinksView set to false

2014-01-17 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4862:
---

FYI - I've encountered my first real-world problem with this unresolved issue. 

If I use the fixed viewport tag (mentioned above) my Android phone apps zoom 
themselves out like they're tablets. But if I remove the fixed viewport tag 
the iPhone keyboard problem comes back (where the viewport resizes when the 
keyboard shows up). SO ... for now I have to give my Android HTML pages one 
viewport tag and my IOS HTML pages a different viewport tag - very painful as 
it makes my CLI-drive workflow pretty pointless since I have to make manual 
changes after every [$ cordova build] statement.

Any updates or advice here?

 ios 7 keyboard resizes the page even with KeyboardShrinksView set to false
 --

 Key: CB-4862
 URL: https://issues.apache.org/jira/browse/CB-4862
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.8.0
 Environment: ipod 5th gen ios 7 and simulator for ios 7
Reporter: Jake Williams
Assignee: Shazron Abdullah
  Labels: ios7, keyboard-plugin

 We have a page with a fixed footer and some inputs.  In previous ios versions 
 the page would be pushed up when an input was focused and the keyboard came 
 up.  In ios 7, the page height is reduced to the available space after the 
 keyboard appears and the footer covers the input (depends on the position of 
 the footer, but it does happen sometimes).  There is also a problem where the 
 input could be beneath the keyboard if you have multiple inputs and you use 
 next/previous to move between them.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (CB-4862) ios 7 keyboard resizes the page even with KeyboardShrinksView set to false

2014-01-08 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4862:
---

Has anyone truly answered Adrian Vasiliu's great point above 
([link](https://issues.apache.org/jira/browse/CB-4862?focusedCommentId=13797718page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13797718)
 )? While the meta tag shown above does seem to resolve the issue the CDV docs 
tell us to not use that meta-tag in it's entirety to avoid other problems. 

- [Adrian's 
Comment](https://issues.apache.org/jira/browse/CB-4862?focusedCommentId=13797718page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13797718)
- [Related Meta Tag Bug](https://issues.apache.org/jira/browse/CB-4323)
- [CDV Docs saying avoid 
tag](http://cordova.apache.org/docs/en/3.3.0/guide_platforms_ios_upgrading.md.html#Upgrading%20iOS)

 ios 7 keyboard resizes the page even with KeyboardShrinksView set to false
 --

 Key: CB-4862
 URL: https://issues.apache.org/jira/browse/CB-4862
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.8.0
 Environment: ipod 5th gen ios 7 and simulator for ios 7
Reporter: Jake Williams
Assignee: Shazron Abdullah
  Labels: ios7

 We have a page with a fixed footer and some inputs.  In previous ios versions 
 the page would be pushed up when an input was focused and the keyboard came 
 up.  In ios 7, the page height is reduced to the available space after the 
 keyboard appears and the footer covers the input (depends on the position of 
 the footer, but it does happen sometimes).  There is also a problem where the 
 input could be beneath the keyboard if you have multiple inputs and you use 
 next/previous to move between them.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (CB-4994) Cordova prepare SyntaxError

2013-11-08 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4994:
---

+1 for needing this update. My ios builds are failing for a similar, if not the 
same, problem. (SyntaxError message: 'Expected /*, ...)

 Cordova prepare SyntaxError
 ---

 Key: CB-4994
 URL: https://issues.apache.org/jira/browse/CB-4994
 Project: Apache Cordova
  Issue Type: Bug
  Components: CLI
Affects Versions: 3.1.0
 Environment: Xcode 5, mac 10.8.5, cordova 3.1.0-0.1.0
Reporter: pushandplay
Assignee: Braden Shepherdson
Priority: Blocker
  Labels: build
 Attachments: Screen Shot 2013-10-09 at 8.31.20 PM.png


 After modify project in Xcode (change icons, capabilities and localisation 
 language) can not prepare project with command cordova prepare and catch 
 error in console
 $ cordova prepare
 { name: 'SyntaxError',
   message: 'Expected /*, = or [A-Za-z0-9_] but . found.',
   line: 382,
   column: 11 }



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Comment Edited] (CB-4994) Cordova prepare SyntaxError

2013-11-08 Thread Chris Emerson (JIRA)

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

Chris Emerson edited comment on CB-4994 at 11/8/13 3:28 PM:


+1 for needing this update. My ios builds are failing for a similar, if not the 
same, problem. (SyntaxError message: 'Expected /*, ...)

FYI I'm on:
- cordova 3.1.0-0.2.0 
- plugman 0.14.0


was (Author: chrisemersonnc):
+1 for needing this update. My ios builds are failing for a similar, if not the 
same, problem. (SyntaxError message: 'Expected /*, ...)

 Cordova prepare SyntaxError
 ---

 Key: CB-4994
 URL: https://issues.apache.org/jira/browse/CB-4994
 Project: Apache Cordova
  Issue Type: Bug
  Components: CLI
Affects Versions: 3.1.0
 Environment: Xcode 5, mac 10.8.5, cordova 3.1.0-0.1.0
Reporter: pushandplay
Assignee: Braden Shepherdson
Priority: Blocker
  Labels: build
 Attachments: Screen Shot 2013-10-09 at 8.31.20 PM.png


 After modify project in Xcode (change icons, capabilities and localisation 
 language) can not prepare project with command cordova prepare and catch 
 error in console
 $ cordova prepare
 { name: 'SyntaxError',
   message: 'Expected /*, = or [A-Za-z0-9_] but . found.',
   line: 382,
   column: 11 }



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CB-4994) Cordova prepare SyntaxError

2013-11-08 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4994:
---

Thanks so much for the update Braden. If you're looking for votes I vote for a 
new release because the other option isn't as clear/standard procedure for 
me! 

 Cordova prepare SyntaxError
 ---

 Key: CB-4994
 URL: https://issues.apache.org/jira/browse/CB-4994
 Project: Apache Cordova
  Issue Type: Bug
  Components: CLI
Affects Versions: 3.1.0
 Environment: Xcode 5, mac 10.8.5, cordova 3.1.0-0.1.0
Reporter: pushandplay
Assignee: Braden Shepherdson
Priority: Blocker
  Labels: build
 Attachments: Screen Shot 2013-10-09 at 8.31.20 PM.png


 After modify project in Xcode (change icons, capabilities and localisation 
 language) can not prepare project with command cordova prepare and catch 
 error in console
 $ cordova prepare
 { name: 'SyntaxError',
   message: 'Expected /*, = or [A-Za-z0-9_] but . found.',
   line: 382,
   column: 11 }



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CB-4911) Custom AndroidManifest.xml changes being overwritten each $ cordova build

2013-09-25 Thread Chris Emerson (JIRA)
Chris Emerson created CB-4911:
-

 Summary: Custom AndroidManifest.xml changes being overwritten each 
$ cordova build
 Key: CB-4911
 URL: https://issues.apache.org/jira/browse/CB-4911
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android, CLI
Affects Versions: 3.0.0
 Environment: OSX Mountain Lion / Android Dev Tools v22.0.1-685705 / 
Cordova CLI 3.0
Reporter: Chris Emerson


I put the following in my AndroidManifest.xml's activity node so the app will 
would resume, not restart each time the user returns to it: 
android:launchMode=singleTask. However - every time I run $ cordova build my 
AndroidManifest.xml files loses this setting so I have to retype it each time.

I would think either the setting should just stay put or an equivalent flag 
could be put in the cordova config.xml so this (and other?) Android settings 
are retained after each cordova build.

My apologies if this issue already exists in another form here - so far I 
haven't found anything using search (but search is slow so I haven't searched a 
ton).

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


[jira] [Closed] (CB-4911) Custom AndroidManifest.xml changes being overwritten each $ cordova build

2013-09-25 Thread Chris Emerson (JIRA)

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

Chris Emerson closed CB-4911.
-

Resolution: Cannot Reproduce

Sorry - maybe I missed it but the setting just got moved - it was still in the 
manifest post build. 

 Custom AndroidManifest.xml changes being overwritten each $ cordova build
 -

 Key: CB-4911
 URL: https://issues.apache.org/jira/browse/CB-4911
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android, CLI
Affects Versions: 3.0.0
 Environment: OSX Mountain Lion / Android Dev Tools v22.0.1-685705 / 
 Cordova CLI 3.0
Reporter: Chris Emerson
  Labels: Android, CLI, androidmanifest.xml, config.xml,

 I put the following in my AndroidManifest.xml's activity node so the app 
 will would resume, not restart each time the user returns to it: 
 android:launchMode=singleTask. However - every time I run $ cordova build 
 my AndroidManifest.xml files loses this setting so I have to retype it each 
 time.
 I would think either the setting should just stay put or an equivalent flag 
 could be put in the cordova config.xml so this (and other?) Android settings 
 are retained after each cordova build.
 My apologies if this issue already exists in another form here - so far I 
 haven't found anything using search (but search is slow so I haven't searched 
 a ton).

--
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-3020) HideKeyboardFormAccessoryBar and KeyboardShrinksView show white bar instead of removing it

2013-09-20 Thread Chris Emerson (JIRA)

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

Chris Emerson edited comment on CB-3020 at 9/20/13 12:45 PM:
-

Hey guys - I'm using (and need) the following to work: preference 
name=KeyboardShrinksView value=false/.  

I tried the above stuff and something a guy put here: 
https://github.com/cpojer/cordova-ios/commit/883ebf049bfd6a4a2b210f69b7b6bab229269eff
  but nothing got things working for me. By working I mean I *DON'T* want the 
keyboard to shrink my view when it appears ... which is what I need 99.5% of 
the time.

I think I have a working (hack) fix if anyone wants to try/test. All I did was 
comment out the first 3 lines of the keyboardWillShowOrHide method - after 
doing that the keyboard stopped shrinking my view - Yay! If anyone 
tests/confirms the same on their end please let me know.

Update 1: I had some iPad issues so I updated my getting-uglier-by-the-minute 
hack a bit:

{code:title=CDVViewController.m}

- (void)keyboardWillShowOrHide:(NSNotification*)notif
{
// Ignore this conditional statement and just assume 
KeyboardShrinksView=true 
// if (![@true isEqualToString :[self 
settingForKey:@KeyboardShrinksView]]) {
//return;
// }

BOOL showEvent = [notif.name 
isEqualToString:UIKeyboardWillShowNotification];

CGRect keyboardFrame = [notif.userInfo[UIKeyboardFrameEndUserInfoKey] 
CGRectValue];
keyboardFrame = [self.view convertRect:keyboardFrame fromView:nil];

CGRect newFrame = self.view.bounds;
if (showEvent) {
// Add, don't subtract, the keyboard height to webview frame
// newFrame.size.height -= keyboardFrame.size.height;
newFrame.size.height += keyboardFrame.size.height;
// don't allow frame height to exceed 1024 (iPad)
if(newFrame.size.height  1024) newFrame.size.height = 1024;
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 
-keyboardFrame.size.height, 0);
} else {
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 0, 0);
}
// NSLog(@running keyboardWillShowOrHide() [frame height:%f] 
[kb:%f],newFrame.size.height, keyboardFrame.size.height);
self.webView.frame = newFrame;
}
{code}

  was (Author: chrisemersonnc):
Hey guys - I'm using (and need) the following to work: preference 
name=KeyboardShrinksView value=false/.  

I tried the above stuff and something a guy put here: 
https://github.com/cpojer/cordova-ios/commit/883ebf049bfd6a4a2b210f69b7b6bab229269eff
  but nothing got things working for me. By working I mean I *DON'T* want the 
keyboard to shrink my view when it appears ... which is what I need 99.5% of 
the time.

I think I have a working (hack) fix if anyone wants to try/test. All I did was 
comment out the first 3 lines of the keyboardWillShowOrHide method - after 
doing that the keyboard stopped shrinking my view - Yay! If anyone 
tests/confirms the same on their end please let me know.

Update 1: I had some iPad issues w/my hack to I updated my 
getting-uglier-by-the-minute hack a bit:

{code:title=CDVViewController.m}

- (void)keyboardWillShowOrHide:(NSNotification*)notif
{
// Ignore this conditional statement and just assume 
KeyboardShrinksView=true 
// if (![@true isEqualToString :[self 
settingForKey:@KeyboardShrinksView]]) {
//return;
// }

BOOL showEvent = [notif.name 
isEqualToString:UIKeyboardWillShowNotification];

CGRect keyboardFrame = [notif.userInfo[UIKeyboardFrameEndUserInfoKey] 
CGRectValue];
keyboardFrame = [self.view convertRect:keyboardFrame fromView:nil];

CGRect newFrame = self.view.bounds;
if (showEvent) {
// Add, don't subtract, the keyboard height to webview frame
// newFrame.size.height -= keyboardFrame.size.height;
newFrame.size.height += keyboardFrame.size.height;
// don't allow frame height to exceed 1024 (iPad)
if(newFrame.size.height  1024) newFrame.size.height = 1024;
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 
-keyboardFrame.size.height, 0);
} else {
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 0, 0);
}
// NSLog(@running keyboardWillShowOrHide() [frame height:%f] 
[kb:%f],newFrame.size.height, keyboardFrame.size.height);
self.webView.frame = newFrame;
}
{code}
  
 HideKeyboardFormAccessoryBar and KeyboardShrinksView show white bar instead 
 of removing it
 --

 Key: CB-3020
 URL: https://issues.apache.org/jira/browse/CB-3020
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.6.0, 3.0.0
 Environment: ios 

[jira] [Comment Edited] (CB-3020) HideKeyboardFormAccessoryBar and KeyboardShrinksView show white bar instead of removing it

2013-09-20 Thread Chris Emerson (JIRA)

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

Chris Emerson edited comment on CB-3020 at 9/20/13 4:17 PM:


Hey guys - I'm using (and need) the following to work: preference 
name=KeyboardShrinksView value=false/.  



I tried the above stuff and something a guy put here: 
https://github.com/cpojer/cordova-ios/commit/883ebf049bfd6a4a2b210f69b7b6bab229269eff
  but nothing got things working for me. By working I mean I *DON'T* want the 
keyboard to shrink my view when it appears ... which is what I need 99.5% of 
the time.

I think I have a working (hack) fix if anyone wants to try/test. All I did was 
comment out the first 3 lines of the keyboardWillShowOrHide method - after 
doing that the keyboard stopped shrinking my view - Yay! If anyone 
tests/confirms the same on their end please let me know.

*Update 1: I had some iPad issues so I updated my getting-uglier-by-the-minute 
hack a bit*

*Update 2: Looks like it works on the simulator but on the iPad itself this 
hack stops working after a few show/hide instances ... trying to resolve still*

{code:title=CDVViewController.m}

- (void)keyboardWillShowOrHide:(NSNotification*)notif
{
// Ignore this conditional statement and just assume 
KeyboardShrinksView=true 
// if (![@true isEqualToString :[self 
settingForKey:@KeyboardShrinksView]]) {
//return;
// }

BOOL showEvent = [notif.name 
isEqualToString:UIKeyboardWillShowNotification];

CGRect keyboardFrame = [notif.userInfo[UIKeyboardFrameEndUserInfoKey] 
CGRectValue];
keyboardFrame = [self.view convertRect:keyboardFrame fromView:nil];

CGRect newFrame = self.view.bounds;
if (showEvent) {
// Add, don't subtract, the keyboard height to webview frame
// newFrame.size.height -= keyboardFrame.size.height;
newFrame.size.height += keyboardFrame.size.height;
// don't allow frame height to exceed 1024 (iPad)
if(newFrame.size.height  1024) newFrame.size.height = 1024;
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 
-keyboardFrame.size.height, 0);
} else {
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 0, 0);
}
// NSLog(@running keyboardWillShowOrHide() [frame height:%f] 
[kb:%f],newFrame.size.height, keyboardFrame.size.height);
self.webView.frame = newFrame;
}
{code}

  was (Author: chrisemersonnc):
Hey guys - I'm using (and need) the following to work: preference 
name=KeyboardShrinksView value=false/.  

I tried the above stuff and something a guy put here: 
https://github.com/cpojer/cordova-ios/commit/883ebf049bfd6a4a2b210f69b7b6bab229269eff
  but nothing got things working for me. By working I mean I *DON'T* want the 
keyboard to shrink my view when it appears ... which is what I need 99.5% of 
the time.

I think I have a working (hack) fix if anyone wants to try/test. All I did was 
comment out the first 3 lines of the keyboardWillShowOrHide method - after 
doing that the keyboard stopped shrinking my view - Yay! If anyone 
tests/confirms the same on their end please let me know.

Update 1: I had some iPad issues so I updated my getting-uglier-by-the-minute 
hack a bit:

{code:title=CDVViewController.m}

- (void)keyboardWillShowOrHide:(NSNotification*)notif
{
// Ignore this conditional statement and just assume 
KeyboardShrinksView=true 
// if (![@true isEqualToString :[self 
settingForKey:@KeyboardShrinksView]]) {
//return;
// }

BOOL showEvent = [notif.name 
isEqualToString:UIKeyboardWillShowNotification];

CGRect keyboardFrame = [notif.userInfo[UIKeyboardFrameEndUserInfoKey] 
CGRectValue];
keyboardFrame = [self.view convertRect:keyboardFrame fromView:nil];

CGRect newFrame = self.view.bounds;
if (showEvent) {
// Add, don't subtract, the keyboard height to webview frame
// newFrame.size.height -= keyboardFrame.size.height;
newFrame.size.height += keyboardFrame.size.height;
// don't allow frame height to exceed 1024 (iPad)
if(newFrame.size.height  1024) newFrame.size.height = 1024;
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 
-keyboardFrame.size.height, 0);
} else {
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 0, 0);
}
// NSLog(@running keyboardWillShowOrHide() [frame height:%f] 
[kb:%f],newFrame.size.height, keyboardFrame.size.height);
self.webView.frame = newFrame;
}
{code}
  
 HideKeyboardFormAccessoryBar and KeyboardShrinksView show white bar instead 
 of removing it
 --

 Key: CB-3020
 URL: https://issues.apache.org/jira/browse/CB-3020
  

[jira] [Comment Edited] (CB-3020) HideKeyboardFormAccessoryBar and KeyboardShrinksView show white bar instead of removing it

2013-09-20 Thread Chris Emerson (JIRA)

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

Chris Emerson edited comment on CB-3020 at 9/20/13 5:28 PM:


Hey guys - I'm using (and need) the following to work: preference 
name=KeyboardShrinksView value=false/.  



I tried the above stuff and something a guy put here: 
https://github.com/cpojer/cordova-ios/commit/883ebf049bfd6a4a2b210f69b7b6bab229269eff
  but nothing got things working for me. By working I mean I *DON'T* want the 
keyboard to shrink my view when it appears ... which is what I need 99.5% of 
the time.

I think I have a working (hack) fix if anyone wants to try/test. All I did was 
comment out the first 3 lines of the keyboardWillShowOrHide method - after 
doing that the keyboard stopped shrinking my view - Yay! If anyone 
tests/confirms the same on their end please let me know.

*Update 1: I had some iPad issues so I updated my getting-uglier-by-the-minute 
hack a bit* -first version removed-

*Update 2: Looks like it works on the simulator but on the iPad itself this 
hack stops working after a few show/hide instances ... trying to resolve still* 
-second version removed-

*Update 3: Ok - after some more testing/code-mangling I think I got this hack 
working consistently now - on both IOS devices AND the simulator*. I can't 
claim to know how/why really as this issue is so quirky - but at least my view 
isn't being shrunk by the keyboard for now! Dear God please someone fix w/a 
clean/logical fix when you can!

{code:title=CDVViewController.m}

- (void)keyboardWillShowOrHide:(NSNotification*)notif
{
// Ignore this conditional statement and just assume 
KeyboardShrinksView=true
// if (![@true isEqualToString :[self 
settingForKey:@KeyboardShrinksView]]) {
//return;
// }

BOOL showEvent = [notif.name 
isEqualToString:UIKeyboardWillShowNotification];

CGRect keyboardFrame = [notif.userInfo[UIKeyboardFrameEndUserInfoKey] 
CGRectValue];
keyboardFrame = [self.view convertRect:keyboardFrame fromView:nil];

CGRect newFrame = self.view.bounds;

if (showEvent) {
// Add, don't subtract, the keyboard height to webview frame
// newFrame.size.height -= keyboardFrame.size.height;
newFrame.size.height += keyboardFrame.size.height;
// don't allow frame height to exceed 1024 (iPad)
if(newFrame.size.height  1024) newFrame.size.height = 1024;
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 0, 0); 
//-keyboardFrame.size.height, 0);
} else {
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 0, 0);
}

// NSLog(@keyboardWillShowOrHide() [webView height:%f | keyboardFrame 
height:%f],newFrame.size.height, keyboardFrame.size.height);

// this seems to be needed every pass otherwise the device (iPad)
// starts shrinking the webview again
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 0, 0);

self.webView.frame = newFrame;
}
{code}

  was (Author: chrisemersonnc):
Hey guys - I'm using (and need) the following to work: preference 
name=KeyboardShrinksView value=false/.  



I tried the above stuff and something a guy put here: 
https://github.com/cpojer/cordova-ios/commit/883ebf049bfd6a4a2b210f69b7b6bab229269eff
  but nothing got things working for me. By working I mean I *DON'T* want the 
keyboard to shrink my view when it appears ... which is what I need 99.5% of 
the time.

I think I have a working (hack) fix if anyone wants to try/test. All I did was 
comment out the first 3 lines of the keyboardWillShowOrHide method - after 
doing that the keyboard stopped shrinking my view - Yay! If anyone 
tests/confirms the same on their end please let me know.

*Update 1: I had some iPad issues so I updated my getting-uglier-by-the-minute 
hack a bit*

*Update 2: Looks like it works on the simulator but on the iPad itself this 
hack stops working after a few show/hide instances ... trying to resolve still*

{code:title=CDVViewController.m}

- (void)keyboardWillShowOrHide:(NSNotification*)notif
{
// Ignore this conditional statement and just assume 
KeyboardShrinksView=true 
// if (![@true isEqualToString :[self 
settingForKey:@KeyboardShrinksView]]) {
//return;
// }

BOOL showEvent = [notif.name 
isEqualToString:UIKeyboardWillShowNotification];

CGRect keyboardFrame = [notif.userInfo[UIKeyboardFrameEndUserInfoKey] 
CGRectValue];
keyboardFrame = [self.view convertRect:keyboardFrame fromView:nil];

CGRect newFrame = self.view.bounds;
if (showEvent) {
// Add, don't subtract, the keyboard height to webview frame
// newFrame.size.height -= keyboardFrame.size.height;
newFrame.size.height += keyboardFrame.size.height;
// don't allow frame height to exceed 1024 (iPad)

[jira] [Commented] (CB-3020) HideKeyboardFormAccessoryBar and KeyboardShrinksView show white bar instead of removing it

2013-09-20 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-3020:
---

@Miguel - yeah I do think there's possibly a timing element to this issue 
and/or my hack. Not sure I'm seeing this toolbar thing yet though - my use may 
be diff than yours? (share screenshot?)

I hacked my fix a bit more (and moved it to a Gist) - see above if you can use 
and/or help make it better.

 HideKeyboardFormAccessoryBar and KeyboardShrinksView show white bar instead 
 of removing it
 --

 Key: CB-3020
 URL: https://issues.apache.org/jira/browse/CB-3020
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.6.0, 3.0.0
 Environment: ios 6.1.3
Reporter: Horst Perfect
Assignee: Shazron Abdullah
Priority: Minor
  Labels: bug, ios, ios6.1.3

 I use phonegap 2.6 with the two new preferences HideKeyboardFormAccessoryBar 
 KeyboardShrinksView set to true. Instead of the AccessoryBar a white bar 
 appears ([screenshot|http://i.stack.imgur.com/3fgV8.png]).
 This is just happening when i set *both* of the preferences to true. When i 
 just set the AccessoryBar preference to true the bar disappears as planned.
 Horst

--
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-3020) HideKeyboardFormAccessoryBar and KeyboardShrinksView show white bar instead of removing it

2013-09-20 Thread Chris Emerson (JIRA)

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

Chris Emerson edited comment on CB-3020 at 9/20/13 6:57 PM:


Hey guys - I'm using (and need) the following to work: preference 
name=KeyboardShrinksView value=false/.  



I tried the above stuff and something a guy put here: 
https://github.com/cpojer/cordova-ios/commit/883ebf049bfd6a4a2b210f69b7b6bab229269eff
  but nothing got things working for me. By working I mean I *DON'T* want the 
keyboard to shrink my view when it appears ... which is what I need 99.5% of 
the time.

I think I have a working (hack) fix if anyone wants to try/test. All I did was 
comment out the first 3 lines of the keyboardWillShowOrHide method - after 
doing that the keyboard stopped shrinking my view - Yay! If anyone 
tests/confirms the same on their end please let me know.

-Update 1: I had some iPad issues so I updated my hack a bit-

-Update 2: Looks like it works on the simulator but on the iPad itself this 
hack stops working after a few show/hide instances ... trying to resolve still-

-Update 3: Ok - after some more testing/code-mangling I think I got this hack 
working consistently now - on both IOS devices AND the simulator. I can't claim 
to know how/why really as this issue is so quirky - but at least my view isn't 
being shrunk by the keyboard for now!-

Update 4: This is getting ridiculous I know. This hack fix now includes way to 
add a css class to body on keyboard show/hide. This is something I may/may 
not keep using going forward - though I suppose thing belongs in a plugin not 
the CDVViewController.m file ... but alas it remains in this keyboardshrinkview 
fix for now. I've also moved my scary hack code to a Gist here to spare this 
thread any unnecessary pain and suffering

h4. https://gist.github.com/cemerson/6642026

I will stay tuned for a cleaner/actual fix for this issue ...




  was (Author: chrisemersonnc):
Hey guys - I'm using (and need) the following to work: preference 
name=KeyboardShrinksView value=false/.  



I tried the above stuff and something a guy put here: 
https://github.com/cpojer/cordova-ios/commit/883ebf049bfd6a4a2b210f69b7b6bab229269eff
  but nothing got things working for me. By working I mean I *DON'T* want the 
keyboard to shrink my view when it appears ... which is what I need 99.5% of 
the time.

I think I have a working (hack) fix if anyone wants to try/test. All I did was 
comment out the first 3 lines of the keyboardWillShowOrHide method - after 
doing that the keyboard stopped shrinking my view - Yay! If anyone 
tests/confirms the same on their end please let me know.

*Update 1: I had some iPad issues so I updated my getting-uglier-by-the-minute 
hack a bit* -first version removed-

*Update 2: Looks like it works on the simulator but on the iPad itself this 
hack stops working after a few show/hide instances ... trying to resolve still* 
-second version removed-

*Update 3: Ok - after some more testing/code-mangling I think I got this hack 
working consistently now - on both IOS devices AND the simulator*. I can't 
claim to know how/why really as this issue is so quirky - but at least my view 
isn't being shrunk by the keyboard for now! Dear God please someone fix w/a 
clean/logical fix when you can!

{code:title=CDVViewController.m}

- (void)keyboardWillShowOrHide:(NSNotification*)notif
{
// Ignore this conditional statement and just assume 
KeyboardShrinksView=true
// if (![@true isEqualToString :[self 
settingForKey:@KeyboardShrinksView]]) {
//return;
// }

BOOL showEvent = [notif.name 
isEqualToString:UIKeyboardWillShowNotification];

CGRect keyboardFrame = [notif.userInfo[UIKeyboardFrameEndUserInfoKey] 
CGRectValue];
keyboardFrame = [self.view convertRect:keyboardFrame fromView:nil];

CGRect newFrame = self.view.bounds;

if (showEvent) {
// Add, don't subtract, the keyboard height to webview frame
// newFrame.size.height -= keyboardFrame.size.height;
newFrame.size.height += keyboardFrame.size.height;
// don't allow frame height to exceed 1024 (iPad)
if(newFrame.size.height  1024) newFrame.size.height = 1024;
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 0, 0); 
//-keyboardFrame.size.height, 0);
} else {
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 0, 0);
}

// NSLog(@keyboardWillShowOrHide() [webView height:%f | keyboardFrame 
height:%f],newFrame.size.height, keyboardFrame.size.height);

// this seems to be needed every pass otherwise the device (iPad)
// starts shrinking the webview again
self.webView.scrollView.contentInset = UIEdgeInsetsMake(0, 0, 0, 0);

self.webView.frame = newFrame;
}
{code}
  
 HideKeyboardFormAccessoryBar and 

[jira] [Commented] (CB-4708) injectPluginScript() can't find cordova_plugins.js when app is on an HTML file in a sub folder of www

2013-09-03 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4708:
---

I tried throwing together a test app this AM to show the behavior here - but 
findCordovaPath() actually seems to be working regardless if I do my cordova.js 
include via script on the HTML page or via a document.write via my app.js 
file - so it's possible there is another twist/condition that my main app is 
introducing here that is causing the core issue. I'll research more and post 
back when I have more detail.

 injectPluginScript() can't find cordova_plugins.js when app is on an HTML 
 file in a sub folder of www
 -

 Key: CB-4708
 URL: https://issues.apache.org/jira/browse/CB-4708
 Project: Apache Cordova
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: iOS / Xcode 4.6.3 (4H1503)
 OS X 10.8.4
Reporter: Chris Emerson
Assignee: Andrew Grieve
  Labels: cordova_plugins.js,, injectPluginScript, plugins,

 Summary: 
 injectPluginScript() can't find cordova_plugins.js when app is on an HTML 
 file in a sub folder of www. 
 Details:
 I've confirmed that the cordova_plugins.js file that sits in the www folder 
 never gets loaded if the app has navigated to an html file in a sub folder of 
 www. 
 In my app/tests I have 14 plugins loading. The [moduleList] object that is 
 instantiated and set in cordova.js confirms this when I check 
 moduleList.length on the initial load of the app. However, when I check after 
 navigating to a html file in a sub folder of www the moduleList object is 
 empty. 
 The final confirmation of my theory/issue is that if I copy the current 
 cordova_plugins.js file to the sub folder where my app has navigated to the 
 moduleList object *does* get populated correctly, the finishPluginLoading() 
 in cordova.js finishes successfully and my plugins are available in the app 
 once again.

--
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-4708) injectPluginScript() can't find cordova_plugins.js when app is on an HTML file in a sub folder of www

2013-08-30 Thread Chris Emerson (JIRA)
Chris Emerson created CB-4708:
-

 Summary: injectPluginScript() can't find cordova_plugins.js when 
app is on an HTML file in a sub folder of www
 Key: CB-4708
 URL: https://issues.apache.org/jira/browse/CB-4708
 Project: Apache Cordova
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: iOS / Xcode 4.6.3 (4H1503)
OS X 10.8.4

Reporter: Chris Emerson


Summary: 
injectPluginScript() can't find cordova_plugins.js when app is on an HTML file 
in a sub folder of www. 

Details:
I've confirmed that the cordova_plugins.js file that sits in the www folder 
never gets loaded if the app has navigated to an html file in a sub folder of 
www. 

In my app/tests I have 14 plugins loading. The [moduleList] object that is 
instantiated and set in cordova.js confirms this when I check moduleList.length 
on the initial load of the app. However, when I check after navigating to a 
html file in a sub folder of www the moduleList object is empty. 

The final confirmation of my theory/issue is that if I copy the current 
cordova_plugins.js file to the sub folder where my app has navigated to the 
moduleList object *does* get populated correctly, the finishPluginLoading() in 
cordova.js finishes successfully and my plugins are available in the app once 
again.

--
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-4708) injectPluginScript() can't find cordova_plugins.js when app is on an HTML file in a sub folder of www

2013-08-30 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4708:
---

May be result of findCordovaPath() always returning null (?) - just a theory.

 injectPluginScript() can't find cordova_plugins.js when app is on an HTML 
 file in a sub folder of www
 -

 Key: CB-4708
 URL: https://issues.apache.org/jira/browse/CB-4708
 Project: Apache Cordova
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: iOS / Xcode 4.6.3 (4H1503)
 OS X 10.8.4
Reporter: Chris Emerson
  Labels: cordova_plugins.js,, injectPluginScript, plugins,

 Summary: 
 injectPluginScript() can't find cordova_plugins.js when app is on an HTML 
 file in a sub folder of www. 
 Details:
 I've confirmed that the cordova_plugins.js file that sits in the www folder 
 never gets loaded if the app has navigated to an html file in a sub folder of 
 www. 
 In my app/tests I have 14 plugins loading. The [moduleList] object that is 
 instantiated and set in cordova.js confirms this when I check 
 moduleList.length on the initial load of the app. However, when I check after 
 navigating to a html file in a sub folder of www the moduleList object is 
 empty. 
 The final confirmation of my theory/issue is that if I copy the current 
 cordova_plugins.js file to the sub folder where my app has navigated to the 
 moduleList object *does* get populated correctly, the finishPluginLoading() 
 in cordova.js finishes successfully and my plugins are available in the app 
 once again.

--
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-4708) injectPluginScript() can't find cordova_plugins.js when app is on an HTML file in a sub folder of www

2013-08-30 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4708:
---

Yep - about 95% sure findCordovaPath() (in cordova.js) is the culprit.

findCordovaPath() depends on the user having script src=cordova.js/script 
in the HTML page otherwise it fails and returns null. 

In my case I have abstracted the base init methods for my app into a app.js 
file. To maintain a DRY programming style I have my cordova.js call in that 
app.js file not my HTML files. It is setup like this:

if(isMobile.any()){
document.write(script type='text/javascript' src=' + rootURL + 
cordova.js'/script);
}else{
window.console.log('NOT-DEVICE-MODE: Skipping loading of [cordova.js] and 
plugins...');
}

Personally I think this is a better model than putting a script 
src=cordova.js tag on every HTML page in my app so I'd prefer that 
findCordovaPath is updated to be smarter if possible. 

For now I'll comment out my above code and put the script tag on all my app's 
HTML files - but I look forward to hearing from others/anyone here on a hopeful 
fix so I can go back to keeping things nice and DRY. :)

Thanks.


 injectPluginScript() can't find cordova_plugins.js when app is on an HTML 
 file in a sub folder of www
 -

 Key: CB-4708
 URL: https://issues.apache.org/jira/browse/CB-4708
 Project: Apache Cordova
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: iOS / Xcode 4.6.3 (4H1503)
 OS X 10.8.4
Reporter: Chris Emerson
  Labels: cordova_plugins.js,, injectPluginScript, plugins,

 Summary: 
 injectPluginScript() can't find cordova_plugins.js when app is on an HTML 
 file in a sub folder of www. 
 Details:
 I've confirmed that the cordova_plugins.js file that sits in the www folder 
 never gets loaded if the app has navigated to an html file in a sub folder of 
 www. 
 In my app/tests I have 14 plugins loading. The [moduleList] object that is 
 instantiated and set in cordova.js confirms this when I check 
 moduleList.length on the initial load of the app. However, when I check after 
 navigating to a html file in a sub folder of www the moduleList object is 
 empty. 
 The final confirmation of my theory/issue is that if I copy the current 
 cordova_plugins.js file to the sub folder where my app has navigated to the 
 moduleList object *does* get populated correctly, the finishPluginLoading() 
 in cordova.js finishes successfully and my plugins are available in the app 
 once again.

--
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-4708) injectPluginScript() can't find cordova_plugins.js when app is on an HTML file in a sub folder of www

2013-08-30 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4708:
---

Well my app.js does a document.write so the DOM eventually has a script tag 
with a src=SOME_PATH/cordova.js but apparently not in time or not in the 
format it (findCordovaPath()) is looking for because unless I have a 
traditional script tag on my HTML page (i.e. not a document.write version in 
my app.js) findCordovaPath() consistently returns null.

If findCordovaPath() could just be modified to base it's search on something 
else (like just figuring out the root of the app for the particular platform?) 
then this issue would be resolved. But for now the way it hunts for a 
traditional script already on the HTML page is not working for my setup. 

I suppose the Cordova guys could just tell me to go back to putting script on 
every HTML but I am hoping they will support my attempt to keep things DRY here 
and find a way to get it working for setups like mine.

 injectPluginScript() can't find cordova_plugins.js when app is on an HTML 
 file in a sub folder of www
 -

 Key: CB-4708
 URL: https://issues.apache.org/jira/browse/CB-4708
 Project: Apache Cordova
  Issue Type: Bug
Affects Versions: 3.0.0
 Environment: iOS / Xcode 4.6.3 (4H1503)
 OS X 10.8.4
Reporter: Chris Emerson
Assignee: Andrew Grieve
  Labels: cordova_plugins.js,, injectPluginScript, plugins,

 Summary: 
 injectPluginScript() can't find cordova_plugins.js when app is on an HTML 
 file in a sub folder of www. 
 Details:
 I've confirmed that the cordova_plugins.js file that sits in the www folder 
 never gets loaded if the app has navigated to an html file in a sub folder of 
 www. 
 In my app/tests I have 14 plugins loading. The [moduleList] object that is 
 instantiated and set in cordova.js confirms this when I check 
 moduleList.length on the initial load of the app. However, when I check after 
 navigating to a html file in a sub folder of www the moduleList object is 
 empty. 
 The final confirmation of my theory/issue is that if I copy the current 
 cordova_plugins.js file to the sub folder where my app has navigated to the 
 moduleList object *does* get populated correctly, the finishPluginLoading() 
 in cordova.js finishes successfully and my plugins are available in the app 
 once again.

--
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-4597) Changes to plugins do not propagate during local build

2013-08-16 Thread Chris Emerson (JIRA)

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

Chris Emerson commented on CB-4597:
---

Related thread @ Google groups (is it ok to post this kind of reference here?)
https://groups.google.com/forum/#!topic/phonegap/VDwgor33lek

 Changes to plugins do not propagate during local build
 --

 Key: CB-4597
 URL: https://issues.apache.org/jira/browse/CB-4597
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 3.0.0
 Environment: OSX
Reporter: Benjamin Hill
Assignee: Shazron Abdullah

 After modifying a plugin's .h and .m files, and building the project 
 (phonegap local build ios), the changes to the files are not propagated to 
 the build.
 Which is unexpected, because changes to files in /www are.  It also makes me 
 suspect that changes to the plugins from updates are also not propagated?
 I tried changing the version number in the plugin XML file, it had no effect.
 Workaround: Copy and pasting the files manually before building the project.

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