[jira] [Commented] (CB-5454) Plugin Mapping Issue
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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