[jira] [Commented] (CB-5989) Properties defined in plugin.xml are not created in *-Info.plist
[ https://issues.apache.org/jira/browse/CB-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090418#comment-14090418 ] Kelvin Dart commented on CB-5989: - Wow - that's a great help, thank you [~Spenc3]! This does indeed work. Properties defined in plugin.xml are not created in *-Info.plist Key: CB-5989 URL: https://issues.apache.org/jira/browse/CB-5989 Project: Apache Cordova Issue Type: Bug Components: CLI, Plugman Affects Versions: 3.3.0 Environment: Mavericks 10.9.1; Xcode 5.0.2; Cordova 3.3.1-0.3.0 Reporter: Kelvin Dart Labels: CLI, Plugin Attachments: after_platform_add_plist_fix.sh, before_platform_add_plist_fix.sh I have the following tag in my platforms=ios tag, within plugin.xml: config-file target=*-Info.plist parent=UISupportedExternalAccessoryProtocols array stringjp.star-m.starpro/string /array /config-file However, whenever I attempt to add in my plugin, this setting is not applied to my project's plist file and I have to do it manually. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5989) Properties defined in plugin.xml are not created in *-Info.plist
[ https://issues.apache.org/jira/browse/CB-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090433#comment-14090433 ] Kelvin Dart commented on CB-5989: - Oh I see, you're suffixing any non-project related plist files with .tmp so they fail the Cordova plugin parser on *-Info.plist - good work! Properties defined in plugin.xml are not created in *-Info.plist Key: CB-5989 URL: https://issues.apache.org/jira/browse/CB-5989 Project: Apache Cordova Issue Type: Bug Components: CLI, Plugman Affects Versions: 3.3.0 Environment: Mavericks 10.9.1; Xcode 5.0.2; Cordova 3.3.1-0.3.0 Reporter: Kelvin Dart Labels: CLI, Plugin Attachments: after_platform_add_plist_fix.sh, before_platform_add_plist_fix.sh I have the following tag in my platforms=ios tag, within plugin.xml: config-file target=*-Info.plist parent=UISupportedExternalAccessoryProtocols array stringjp.star-m.starpro/string /array /config-file However, whenever I attempt to add in my plugin, this setting is not applied to my project's plist file and I have to do it manually. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-4897) Support window.postMessage for two way communication between local and remote content
[ https://issues.apache.org/jira/browse/CB-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090435#comment-14090435 ] alexgzhou commented on CB-4897: --- this would be very much useful if achieved!!! looking forward to .. Support window.postMessage for two way communication between local and remote content - Key: CB-4897 URL: https://issues.apache.org/jira/browse/CB-4897 Project: Apache Cordova Issue Type: New Feature Components: Plugin InAppBrowser Affects Versions: 3.0.0 Reporter: Lachlan Hunt For developing a hybrid web app that will use the device APIs provided by Cordova plugins in combination with a remotely hosted web application, it is necessary to be able to communicate between the local and remotely hosted components. The InAppBrowser plugin currently only provides limited support for mostly one-way communication using executeScript to inject a new script into the remote document. But this is limited because it only allows a single return value, and doesn't directly allow for ongoing communication. It would be very useful if window.postMessage were supported by the plugin. When a message is received by the remote page (via the window.onmessage handler), the evt.source property can provide a WindowProxy or MessagePort to be used for subsequent communication from the remote page to the local page. Other solutions I have considered: * Using iframe instead of InAppBrowser, absolutely positioned and covering the full height and width of the screen. This works, because the Window objects are accessible to both, and posting a message to iframe.contentWinow from the local content provides a reference to evt.source (The local Window object). This isn't ideal because it prevents using InAppBrowser's executeScript feature to first inject a script to enable the two-way communication features. Ideally, I don't want the server to include it because I don't want the web app to enable the feature when the remote page is loaded outside of the native app. * Creating a new MessageChannel() object and returning one of the ports via the executeScript return value. This doesn't work because the MessageChannel() constructor is not yet supported by WebKit on the devices. * Loading a remote script directly into the local content, and having that script populate the DOM with content as needed. This isn't ideal because the base URL of the document is not a URL to the remote host, so relative paths don't work, and setting base href causes other problems. * Communication via SharedWorker This method is the best I've found so far, but is quite complex to setup and operate securely. Setup for local page: * Embed iframe src=http://remote.example.com/bridge.html;/iframe * Generate a secure shared secret key using window.crypto DOM API. (Don't use Math.random() because it could potentially allow attackers to guess the shared secret.) * use iframe.contentWindow.postMessage() to send messages to bridge.html. * Send initialisation message with the shared secret key to the bridge. * var win = window.open(http://remote.example.com/;, ...) * When loaded, use win.executeScript(...) to inject the same bridge.html iframe and the shared secret key into the remote page Setup for remote page (from executeScript call): * Embed iframe src=http://remote.example.com/bridge.html;/iframe * postMessage() initialisation to the bridge with the shared secret key Bridge.html * Creates a new SharedWorker(bridge.js) * Messages received by the SharedWorker are broadcast out to all other listeners that have initialised with the same shared secret key. Because bridge.html may potentially be embedded into any site and access the same SharedWorker, the shared secret key lets the worker know which pages are authorised to post messages, and reject messages received from other sources. The complexity of that solution would be solved by having native support for window.postMessage() in the InAppBrowser plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-7262) Update device plugin with support of universal windows apps.
[
https://issues.apache.org/jira/browse/CB-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kotikov resolved CB-7262.
--
Resolution: Fixed
Update device plugin with support of universal windows apps.
Key: CB-7262
URL: https://issues.apache.org/jira/browse/CB-7262
Project: Apache Cordova
Issue Type: Task
Components: Plugin Device
Reporter: Vladimir Kotikov
Current realization of device plugin doesn't support Universal windows
platform.
It reports {{device.platform}} incorrectly and causes critical errors (app
won't start properly) when trying to run Universal app on Windows Phone 8.1
device/emulator with following error
{noformat}
Exception calling native with command :: Device :: getDeviceInfo
::exception=TypeError: Unable to get property '1' of undefined or null
reference
deviceready has not fired after 5 seconds.
Channel not fired: onCordovaInfoReady
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (CB-7262) Update device plugin with support of universal windows apps.
[
https://issues.apache.org/jira/browse/CB-7262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kotikov closed CB-7262.
Merged https://github.com/apache/cordova-plugin-device/pull/19
Update device plugin with support of universal windows apps.
Key: CB-7262
URL: https://issues.apache.org/jira/browse/CB-7262
Project: Apache Cordova
Issue Type: Task
Components: Plugin Device
Reporter: Vladimir Kotikov
Current realization of device plugin doesn't support Universal windows
platform.
It reports {{device.platform}} incorrectly and causes critical errors (app
won't start properly) when trying to run Universal app on Windows Phone 8.1
device/emulator with following error
{noformat}
Exception calling native with command :: Device :: getDeviceInfo
::exception=TypeError: Unable to get property '1' of undefined or null
reference
deviceready has not fired after 5 seconds.
Channel not fired: onCordovaInfoReady
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-7276) correctOrientation is applied only for JPEG images
Petrus Repo created CB-7276: --- Summary: correctOrientation is applied only for JPEG images Key: CB-7276 URL: https://issues.apache.org/jira/browse/CB-7276 Project: Apache Cordova Issue Type: Bug Components: Plugin Camera Affects Versions: 3.5.0 Environment: Android Reporter: Petrus Repo Some Android devices (eg. Samsung S3 running Android 4.1 and Android 4.3) will set wrong orientation for pictures. Using correctOrientation==true will fix the resulting image to have the correct orientation. However, orientation is only corrected for JPEG images. If you set Camera.EncodingType.PNG then the resulting image will have wrong orientation on those devices carrying this bug. (eg. Nexus5 on 4.4 does not have the bug so it's not affected, but Samsung S3s are) Line CameraLauncher#processResultFromCamera:344 (*) has if (this.encodingType == JPEG) and inside the orientation is inspected. There should be no reason limit the orientation fix only for JPEG images. rotate = N is needed in order to apply the orientation fix (**). (*) https://github.com/apache/cordova-plugin-camera/blob/e4ab155fd097381151357b64e69a1e6f40b076a5/src/android/CameraLauncher.java#L344 (**) https://github.com/apache/cordova-plugin-camera/blob/e4ab155fd097381151357b64e69a1e6f40b076a5/src/android/CameraLauncher.java#L371 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-7277) watchPosition and getCurrentPosition give timeout errors and never a location in iOS 8 Betas
David Eisner created CB-7277: Summary: watchPosition and getCurrentPosition give timeout errors and never a location in iOS 8 Betas Key: CB-7277 URL: https://issues.apache.org/jira/browse/CB-7277 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin Geolocation Affects Versions: 3.5.0, 3.4.0 Environment: iPhone 4S running iOS 8 Beta 3, iOS 8 Beta 4, iOS 8 Beta 5 building from matching SDK/Xcode beta tools on OS X 10.9.3 Reporter: David Eisner Testing this (https://itunes.apple.com/gb/app/survey-me/id507125950) app on iOS 8 Beta 5, the geolocation behaviour is different to iOS 6 and 7. The main features of this app cannot be used in iOS 8 Beta 5 because it never gets any coordinates. Expected: 1. Open app installed from the store in iOS 8 Beta 5 2. Answer OK to the location dialog, should one appear 3. Click Find Rewards Actual: 1. No dialog about using geolocation appears 2. There may be a dialog: Location unavailable 3. A progress dialog saying, Getting one's bearings... appears and does not progress or disappear The same process can be followed with the app rebuilt with the appropriate beta sdk and latest cordova plugins. This gives the same results. I am attempting now to test with mobile-spec and to test the Safari geolocation API without the plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7158) Geolocation not working when built with Xcode 6
[ https://issues.apache.org/jira/browse/CB-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090756#comment-14090756 ] David Eisner commented on CB-7158: -- Having submitted a new issue for geolocation in iOS 8, I discovered this issue pointing to Xcode 6 as the issue. I was trying matching iOS/SDK versions, so my issue may be a duplicate of this. I need to retest the published app and test with Xcode 5. Geolocation not working when built with Xcode 6 --- Key: CB-7158 URL: https://issues.apache.org/jira/browse/CB-7158 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: Master Environment: Xcode 6, IOS 8 Beta 3 Reporter: Eric Weiterman When a project is built using Xcode 6 for IOS 8 the geolocation plugin seems to be failing. I created a mobilespec project from Master and first noticed that the geolocation automated tests were failing. I then tried the geolocadtion manual tests which also failed. I then created a sample plain Cordova project and tried to see if I could use getCurrentPosition(..). The first call to it did nothing but subsequent calls saw it returning the error callback. Geolocation works for both mobilespec and my sample project if I use Xcode 5.1.1 to build the project. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6481) Add unified hooks support for cordova app and plugins
[ https://issues.apache.org/jira/browse/CB-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090758#comment-14090758 ] ASF GitHub Bot commented on CB-6481: Github user csantanapr commented on the pull request: https://github.com/apache/cordova-lib/pull/55#issuecomment-51601294 @sgrebnov So far I have found one problem. When I have the hooks tags inside a platform, the second tag for after_prepare doesn't work. This is because options.plugin get set in the Context.opts when calling before_prepare affecting the search for scripts in after_prepare if the two tags are outside the platform tag then it finds the script, but inside the platform tag it doesn't create a plugin.xml like this: You will notice that iosAfterPrepare.js never runs ?xml version=1.0 encoding=UTF-8? plugin xmlns=http://apache.org/cordova/ns/plugins/1.0; xmlns:android=http://schemas.android.com/apk/res/android; id=com.plugin.withhooks version=0.0.1 namePlugin with hooks/name platform name=ios hook type=before_prepare src=scripts/ios/iosBeforePrepare.js / hook type=after_prepare src=scripts/ios/iosAfterPrepare.js / /platform /plugin One way to fix it is doing a Copy in Context.js, and do a copy of opts, this way opts can be use in other places without the chance of being modify. Here is a change I did: https://github.com/csantanapr/cordova-lib/commit/a0ef4ef172f8818c3bc770899dba5dbab06fa03e#diff-d41d8cd98f00b204e9800998ecf8427e This might be one, avoid modifying context and doing a copy of opts: https://github.com/MSOpenTech/cordova-lib/blob/CB-6481-hooks/cordova-lib/src/hooks/HooksRunner.js#L161 Add unified hooks support for cordova app and plugins - Key: CB-6481 URL: https://issues.apache.org/jira/browse/CB-6481 Project: Apache Cordova Issue Type: New Feature Components: CLI, Plugman Reporter: Sergey Grebnov Assignee: Sergey Grebnov As per Proposal: hooks support for plugins dev mail thread discussion Hi, I have an idea how we can add more flexibility to plugin developers. Note, right now we have Application Developers – someone who use Cordova for developing applications and Plugin Developers – someone who creates plugins so that Application Developers can use them. For Application Developers we expose hooks so that they can customize their build/package/etc process. I want us to provide similar sort of flexibility to Plugin Developers so that they can go beyond of source/, framework/ tags and get mechanism to add custom installation, build logic required by a plugin. Example usage will include: downloading/compiling additional binaries, marking source file to be copied to output dir, changing target build platform, etc. At present time the steps described could be only achieved by hooks manually added by Application Developer, but the right way is to allow Plugin Developer to expose this as part of plugin definition. Example configuration could look like ``` script type=postinstall src=scripts/postinstall.js / script type=preinstall src=scripts/preinstall.js / script type=install src=scripts/install.js / ``` beforeinstall/preinstall – run before plugin is installed install/postinstall/afterinstall – run after plugin is installed uninstall – run after plugin is uninstalled -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-7277) watchPosition and getCurrentPosition give timeout errors and never a location in iOS 8 Betas
[ https://issues.apache.org/jira/browse/CB-7277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eisner updated CB-7277: - Description: Testing this (https://itunes.apple.com/gb/app/survey-me/id507125950) app on iOS 8 Beta 5, the geolocation behaviour is different to iOS 6 and 7. The main features of this app cannot be used in iOS 8 Beta 5 because it never gets any coordinates. [Edit: The issue seems to be with using Xcode 6. See the linked issue . ] Expected: 1. Open app installed from the store in iOS 8 Beta 5 2. Answer OK to the location dialog, should one appear 3. Click Find Rewards Actual: 1. No dialog about using geolocation appears 2. There may be a dialog: Location unavailable 3. A progress dialog saying, Getting one's bearings... appears and does not progress or disappear The same process can be followed with the app rebuilt with the appropriate beta sdk and latest cordova plugins. This gives the same results. I am attempting now to test with mobile-spec and to test the Safari geolocation API without the plugin. was: Testing this (https://itunes.apple.com/gb/app/survey-me/id507125950) app on iOS 8 Beta 5, the geolocation behaviour is different to iOS 6 and 7. The main features of this app cannot be used in iOS 8 Beta 5 because it never gets any coordinates. Expected: 1. Open app installed from the store in iOS 8 Beta 5 2. Answer OK to the location dialog, should one appear 3. Click Find Rewards Actual: 1. No dialog about using geolocation appears 2. There may be a dialog: Location unavailable 3. A progress dialog saying, Getting one's bearings... appears and does not progress or disappear The same process can be followed with the app rebuilt with the appropriate beta sdk and latest cordova plugins. This gives the same results. I am attempting now to test with mobile-spec and to test the Safari geolocation API without the plugin. watchPosition and getCurrentPosition give timeout errors and never a location in iOS 8 Betas Key: CB-7277 URL: https://issues.apache.org/jira/browse/CB-7277 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin Geolocation Affects Versions: 3.4.0, 3.5.0 Environment: iPhone 4S running iOS 8 Beta 3, iOS 8 Beta 4, iOS 8 Beta 5 building from matching SDK/Xcode beta tools on OS X 10.9.3 Reporter: David Eisner Testing this (https://itunes.apple.com/gb/app/survey-me/id507125950) app on iOS 8 Beta 5, the geolocation behaviour is different to iOS 6 and 7. The main features of this app cannot be used in iOS 8 Beta 5 because it never gets any coordinates. [Edit: The issue seems to be with using Xcode 6. See the linked issue . ] Expected: 1. Open app installed from the store in iOS 8 Beta 5 2. Answer OK to the location dialog, should one appear 3. Click Find Rewards Actual: 1. No dialog about using geolocation appears 2. There may be a dialog: Location unavailable 3. A progress dialog saying, Getting one's bearings... appears and does not progress or disappear The same process can be followed with the app rebuilt with the appropriate beta sdk and latest cordova plugins. This gives the same results. I am attempting now to test with mobile-spec and to test the Safari geolocation API without the plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-7277) watchPosition and getCurrentPosition give timeout errors and never a location in iOS 8 Betas
[ https://issues.apache.org/jira/browse/CB-7277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eisner updated CB-7277: - Description: Testing this (https://itunes.apple.com/gb/app/survey-me/id507125950) app on iOS 8 Beta 5, the geolocation behaviour is different to iOS 6 and 7. The main features of this app cannot be used in iOS 8 Beta 5 because it never gets any coordinates. [Edit: The issue seems to be with using Xcode 6. See the linked issue, CB-7158.] Expected: 1. Open app installed from the store in iOS 8 Beta 5 2. Answer OK to the location dialog, should one appear 3. Click Find Rewards Actual: 1. No dialog about using geolocation appears 2. There may be a dialog: Location unavailable 3. A progress dialog saying, Getting one's bearings... appears and does not progress or disappear The same process can be followed with the app rebuilt with the appropriate beta sdk and latest cordova plugins. This gives the same results. I am attempting now to test with mobile-spec and to test the Safari geolocation API without the plugin. was: Testing this (https://itunes.apple.com/gb/app/survey-me/id507125950) app on iOS 8 Beta 5, the geolocation behaviour is different to iOS 6 and 7. The main features of this app cannot be used in iOS 8 Beta 5 because it never gets any coordinates. [Edit: The issue seems to be with using Xcode 6. See the linked issue . ] Expected: 1. Open app installed from the store in iOS 8 Beta 5 2. Answer OK to the location dialog, should one appear 3. Click Find Rewards Actual: 1. No dialog about using geolocation appears 2. There may be a dialog: Location unavailable 3. A progress dialog saying, Getting one's bearings... appears and does not progress or disappear The same process can be followed with the app rebuilt with the appropriate beta sdk and latest cordova plugins. This gives the same results. I am attempting now to test with mobile-spec and to test the Safari geolocation API without the plugin. watchPosition and getCurrentPosition give timeout errors and never a location in iOS 8 Betas Key: CB-7277 URL: https://issues.apache.org/jira/browse/CB-7277 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin Geolocation Affects Versions: 3.4.0, 3.5.0 Environment: iPhone 4S running iOS 8 Beta 3, iOS 8 Beta 4, iOS 8 Beta 5 building from matching SDK/Xcode beta tools on OS X 10.9.3 Reporter: David Eisner Testing this (https://itunes.apple.com/gb/app/survey-me/id507125950) app on iOS 8 Beta 5, the geolocation behaviour is different to iOS 6 and 7. The main features of this app cannot be used in iOS 8 Beta 5 because it never gets any coordinates. [Edit: The issue seems to be with using Xcode 6. See the linked issue, CB-7158.] Expected: 1. Open app installed from the store in iOS 8 Beta 5 2. Answer OK to the location dialog, should one appear 3. Click Find Rewards Actual: 1. No dialog about using geolocation appears 2. There may be a dialog: Location unavailable 3. A progress dialog saying, Getting one's bearings... appears and does not progress or disappear The same process can be followed with the app rebuilt with the appropriate beta sdk and latest cordova plugins. This gives the same results. I am attempting now to test with mobile-spec and to test the Safari geolocation API without the plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7249) Translations for August
[ https://issues.apache.org/jira/browse/CB-7249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090786#comment-14090786 ] ASF subversion and git services commented on CB-7249: - Commit d77710f4322c0400ff030a5388702ba521f57776 in cordova-plugin-device-orientation's branch refs/heads/master from [~ldeluca] [ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-device-orientation.git;h=d77710f ] CB-7249cordova-plugin-device-orientation documentation translation: cordova-plugin-device-orientation Translations for August --- Key: CB-7249 URL: https://issues.apache.org/jira/browse/CB-7249 Project: Apache Cordova Issue Type: Improvement Components: Translation Reporter: Lisa Seacat DeLuca Assignee: Lisa Seacat DeLuca Priority: Minor -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7129) Switch to nodejs for windows platform scripts
[ https://issues.apache.org/jira/browse/CB-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090798#comment-14090798 ] ASF GitHub Bot commented on CB-7129: Github user sgrebnov commented on the pull request: https://github.com/apache/cordova-windows/pull/38#issuecomment-51608724 1. Build/run logic refactoring and improvements (many command failed if run with --help wsitches). 2. Added option to specify target version for store apps with config.xml * added ConfigParser 3. removed MyTemplate.vstemplate since it currently outdated and I can't find if it is really used Switch to nodejs for windows platform scripts - Key: CB-7129 URL: https://issues.apache.org/jira/browse/CB-7129 Project: Apache Cordova Issue Type: Improvement Components: Windows 8 Affects Versions: 3.6.0 Reporter: Vladimir Kotikov Assignee: Jesse MacFadyen Fix For: 3.6.0 Current realization of platform/tooling scripts on Windows is using WSH (Windows Scripting Host) as JS engine which works unpredictable with unicode symbols (incorrect reading/writing of UTF-8 encoded files, incorect passing of unicode paths as arguments to another scripts, etc.) Switching to NodeJS can help to resolve many of unicode related issues in cordova-windows projects. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7129) Switch to nodejs for windows platform scripts
[ https://issues.apache.org/jira/browse/CB-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090901#comment-14090901 ] ASF GitHub Bot commented on CB-7129: Github user sgrebnov commented on the pull request: https://github.com/apache/cordova-windows/pull/38#issuecomment-51620450 Jesse, please let me know your consideration regarding promises usage and if there are places which should be improved. I personally tried to do my best to make code as readable as possible, but it's not so easy taking into account async nature of shell commands. I see, there is the same situation on Android where there are many async methods. https://github.com/apache/cordova-android/blob/master/bin/templates/cordova/lib/run.js#L95 Promises helps here a lot since we don't need to manually manage success/error callbacks/cases and can chain them. Switch to nodejs for windows platform scripts - Key: CB-7129 URL: https://issues.apache.org/jira/browse/CB-7129 Project: Apache Cordova Issue Type: Improvement Components: Windows 8 Affects Versions: 3.6.0 Reporter: Vladimir Kotikov Assignee: Jesse MacFadyen Fix For: 3.6.0 Current realization of platform/tooling scripts on Windows is using WSH (Windows Scripting Host) as JS engine which works unpredictable with unicode symbols (incorrect reading/writing of UTF-8 encoded files, incorect passing of unicode paths as arguments to another scripts, etc.) Switching to NodeJS can help to resolve many of unicode related issues in cordova-windows projects. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7158) Geolocation not working when built with Xcode 6
[ https://issues.apache.org/jira/browse/CB-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090940#comment-14090940 ] Wei Li commented on CB-7158: Hi. I created a patch for this issue: https://github.com/apache/cordova-plugin-geolocation/pull/21. Can some one review it? Thanks. Geolocation not working when built with Xcode 6 --- Key: CB-7158 URL: https://issues.apache.org/jira/browse/CB-7158 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: Master Environment: Xcode 6, IOS 8 Beta 3 Reporter: Eric Weiterman When a project is built using Xcode 6 for IOS 8 the geolocation plugin seems to be failing. I created a mobilespec project from Master and first noticed that the geolocation automated tests were failing. I then tried the geolocadtion manual tests which also failed. I then created a sample plain Cordova project and tried to see if I could use getCurrentPosition(..). The first call to it did nothing but subsequent calls saw it returning the error callback. Geolocation works for both mobilespec and my sample project if I use Xcode 5.1.1 to build the project. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7158) Geolocation not working when built with Xcode 6
[ https://issues.apache.org/jira/browse/CB-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14090939#comment-14090939 ] ASF GitHub Bot commented on CB-7158: GitHub user weili-feedhenry opened a pull request: https://github.com/apache/cordova-plugin-geolocation/pull/21 [CB-7158] fix geolocation for ios 8 See https://issues.apache.org/jira/browse/CB-7158 You can merge this pull request into a Git repository by running: $ git pull https://github.com/weili-feedhenry/cordova-plugin-geolocation master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-geolocation/pull/21.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #21 commit 9a85d34cbaf95df115be967009c5221ed50336a1 Author: Wei Li wei...@feedhenry.com Date: 2014-08-07T17:36:36Z fix geolocation for ios 8 Geolocation not working when built with Xcode 6 --- Key: CB-7158 URL: https://issues.apache.org/jira/browse/CB-7158 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: Master Environment: Xcode 6, IOS 8 Beta 3 Reporter: Eric Weiterman When a project is built using Xcode 6 for IOS 8 the geolocation plugin seems to be failing. I created a mobilespec project from Master and first noticed that the geolocation automated tests were failing. I then tried the geolocadtion manual tests which also failed. I then created a sample plain Cordova project and tried to see if I could use getCurrentPosition(..). The first call to it did nothing but subsequent calls saw it returning the error callback. Geolocation works for both mobilespec and my sample project if I use Xcode 5.1.1 to build the project. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-7278) Allow plugin modules to be .json files
Joseph Frazier created CB-7278: -- Summary: Allow plugin modules to be .json files Key: CB-7278 URL: https://issues.apache.org/jira/browse/CB-7278 Project: Apache Cordova Issue Type: Improvement Components: CordovaLib Affects Versions: 3.5.0 Reporter: Joseph Frazier Priority: Trivial [Node.js modules can be .json files|https://github.com/joyent/node/commit/588d885e81dec667920383ac7246daceeb7f99fd], in which case module.exports is simply the parsed object. Cordova modules should also have this ability, so that modular plugins don't have to be bundled before Cordova prepares them. I've submitted a pull request for this on github: https://github.com/apache/cordova-lib/pull/71 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7278) Allow plugin modules to be .json files
[ https://issues.apache.org/jira/browse/CB-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091185#comment-14091185 ] ASF GitHub Bot commented on CB-7278: Github user joseph-onsip commented on the pull request: https://github.com/apache/cordova-lib/pull/71#issuecomment-51646216 Sure, I work on a [project](https://github.com/onsip/SIP.js) that [requires its package.json](https://github.com/onsip/SIP.js/blob/817c7038c0be0d66a68d4c1f5d5e99678017186b/src/SIP.js#L10-L19). In order to make the project usable as a Cordova plugin, I had to copy the relevant portions of package.json into a separate file, [cordova_package.json.js](https://github.com/onsip/SIP.js/commit/0862df7c825b27f90a5665f584334b232eddf644#diff-0), then [specify *that* file as the src of the package.json module](https://github.com/onsip/SIP.js/commit/0862df7c825b27f90a5665f584334b232eddf644#diff-53f390d375398624afe1cfe1125f42bfR7). If plugin modules could be .json files, I could just specify package.json as the src of the module, instead of needing to manually synchronize cordova_package.json.js with package.json. I opened [CB-7278](https://issues.apache.org/jira/browse/CB-7278) on JIRA, as well. Allow plugin modules to be .json files -- Key: CB-7278 URL: https://issues.apache.org/jira/browse/CB-7278 Project: Apache Cordova Issue Type: Improvement Components: CordovaLib Affects Versions: 3.5.0 Reporter: Joseph Frazier Priority: Trivial Labels: json, module, plugin, require Original Estimate: 0h Remaining Estimate: 0h [Node.js modules can be .json files|https://github.com/joyent/node/commit/588d885e81dec667920383ac7246daceeb7f99fd], in which case module.exports is simply the parsed object. Cordova modules should also have this ability, so that modular plugins don't have to be bundled before Cordova prepares them. I've submitted a pull request for this on github: https://github.com/apache/cordova-lib/pull/71 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7272) Docs for File plugin use o for... something
[ https://issues.apache.org/jira/browse/CB-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091245#comment-14091245 ] Ian Clelland commented on CB-7272: -- Without looking at the docs in question, I suspect that r/o stands for read only (where the / is a vestige of some print standard for abbreviations). Docs for File plugin use o for... something - Key: CB-7272 URL: https://issues.apache.org/jira/browse/CB-7272 Project: Apache Cordova Issue Type: Bug Components: Plugin File Reporter: Raymond Camden Priority: Minor Labels: documentation In the tables regarding read/write access for various OS, I see: r/o under the r/w table. What does read/oh mean? If it means yes to read and no to write, why not just have r there? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7272) Docs for File plugin use o for... something
[ https://issues.apache.org/jira/browse/CB-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091249#comment-14091249 ] Raymond Camden commented on CB-7272: Probably, although r/o really doesn't seem to imply read only (specifically the / in it). Either way - it should be documented. Docs for File plugin use o for... something - Key: CB-7272 URL: https://issues.apache.org/jira/browse/CB-7272 Project: Apache Cordova Issue Type: Bug Components: Plugin File Reporter: Raymond Camden Priority: Minor Labels: documentation In the tables regarding read/write access for various OS, I see: r/o under the r/w table. What does read/oh mean? If it means yes to read and no to write, why not just have r there? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CB-6174) Cordova CLI Android Project issues with Gradle
[ https://issues.apache.org/jira/browse/CB-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Clelland closed CB-6174. Resolution: Duplicate Pretty sure this question is covered by CB-3445 Cordova CLI Android Project issues with Gradle -- Key: CB-6174 URL: https://issues.apache.org/jira/browse/CB-6174 Project: Apache Cordova Issue Type: Improvement Components: Android Affects Versions: 3.4.0 Environment: Mac 10.9, Android Studio Reporter: Mike Hartington Priority: Minor The CLI still creates a project that uses Ant as it's build process while Google has moved to Gradle as its build process. So when I import a project into Android Studio, there are a bunch of project config issues that cannot be resolved. Is there any plan to move to Gradle any time soon? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7001) Create a --browserify option for run/prepare actions
[ https://issues.apache.org/jira/browse/CB-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091283#comment-14091283 ] ASF GitHub Bot commented on CB-7001: Github user surajpindoria commented on the pull request: https://github.com/apache/cordova-cli/pull/185#issuecomment-51656189 @andrewreedy No, it will just copy each asset into the www/ for each platform Create a --browserify option for run/prepare actions Key: CB-7001 URL: https://issues.apache.org/jira/browse/CB-7001 Project: Apache Cordova Issue Type: Sub-task Components: CLI, CordovaLib Affects Versions: 3.5.0 Reporter: Anis Kadri Assignee: Suraj Pindoria Fix For: 3.6.0 Add a --browserify option to run/prepare actions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CB-7255) prepare writes plist unescaped
[ https://issues.apache.org/jira/browse/CB-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulrich Geilmann closed CB-7255. --- Resolution: Fixed Fix Version/s: Master prepare writes plist unescaped -- Key: CB-7255 URL: https://issues.apache.org/jira/browse/CB-7255 Project: Apache Cordova Issue Type: Bug Components: CordovaLib Reporter: Ulrich Geilmann Fix For: Master When the iOS-project's plist is updated during prepare, data is written out unescaped. The consequence is a failing build when the plist contains the (properly escaped) characters . -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7072) Safari, on loading my website with cordova.js in the assets, complains There is no application set to open the URL gap://ready' in a popup.
[ https://issues.apache.org/jira/browse/CB-7072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091358#comment-14091358 ] Craig Payne commented on CB-7072: - I had to ensure that I was not loading any cordova.js file, except when loading a page via my Cordova App. Safari, on loading my website with cordova.js in the assets, complains There is no application set to open the URL gap://ready' in a popup. Key: CB-7072 URL: https://issues.apache.org/jira/browse/CB-7072 Project: Apache Cordova Issue Type: Bug Components: CordovaJS Affects Versions: 3.5.0 Environment: MacOS 10.4.9, iOS 6.1.6 (I use the InAppBrowser plugin to open the system browser on an iPhone). Reporter: Craig Payne Priority: Minor It appears that cordova.js sets execIframe.src to gap://ready in pokeNativeViaIframe(). Neither Firefox nor Chrome complain. It seems limited to iOS/OSX Safari hybrid apps which are loading cordova.js. I will look for a workaround on my site to see if I can conditionally load the cordova.js Asset only when loading into my cordova-based app, but a Cordova-based solution would be preferable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7268) Provide option for adding Windows universal platform to mobilespec application
[ https://issues.apache.org/jira/browse/CB-7268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091375#comment-14091375 ] ASF subversion and git services commented on CB-7268: - Commit 988e80efe53d7ae740b97c64031c8d979fb710dc in cordova-mobile-spec's branch refs/heads/master from [~vladimir.kotikov] [ https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;h=988e80e ] CB-7268 Adds option for creating mobilespec application with windows platform Provide option for adding Windows universal platform to mobilespec application -- Key: CB-7268 URL: https://issues.apache.org/jira/browse/CB-7268 Project: Apache Cordova Issue Type: Improvement Components: mobile-spec Reporter: Vladimir Kotikov Priority: Minor Labels: mobilespec, windows Since Windows universal apps support landed to cordova-windows master, mobile-spec project still doesn't have an option for adding Univarsal windows platform to mobilespec application. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7269) Cordova mobilespec app won't start automatic tests on windows phone 8.1
[ https://issues.apache.org/jira/browse/CB-7269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091378#comment-14091378 ] ASF GitHub Bot commented on CB-7269: Github user asfgit closed the pull request at: https://github.com/apache/cordova-mobile-spec/pull/102 Cordova mobilespec app won't start automatic tests on windows phone 8.1 --- Key: CB-7269 URL: https://issues.apache.org/jira/browse/CB-7269 Project: Apache Cordova Issue Type: Bug Components: mobile-spec Reporter: Vladimir Kotikov Labels: cordova-windows, mobilespec, windows-phone-81 Origin of this issue is that autotests page uses special logic to detect cordova.js loading options, which depends from device/os. Current logic detects that we are running on Windows phone 8 and use WP8 specific logic. Repro steps: 1. Create mobilespec app (via createmobilespec script in mobilespec repo) 2. cd to created app 3. run it on windows phone (cordova run --phone) 4. Navigate to 'Automatic tests' page, then click 'run all tests' button Expected: Tests are started Actual: No tests are running, blank page is displayed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7268) Provide option for adding Windows universal platform to mobilespec application
[ https://issues.apache.org/jira/browse/CB-7268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091377#comment-14091377 ] ASF GitHub Bot commented on CB-7268: Github user asfgit closed the pull request at: https://github.com/apache/cordova-mobile-spec/pull/101 Provide option for adding Windows universal platform to mobilespec application -- Key: CB-7268 URL: https://issues.apache.org/jira/browse/CB-7268 Project: Apache Cordova Issue Type: Improvement Components: mobile-spec Reporter: Vladimir Kotikov Priority: Minor Labels: mobilespec, windows Since Windows universal apps support landed to cordova-windows master, mobile-spec project still doesn't have an option for adding Univarsal windows platform to mobilespec application. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7268) Provide option for adding Windows universal platform to mobilespec application
[ https://issues.apache.org/jira/browse/CB-7268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091379#comment-14091379 ] ASF subversion and git services commented on CB-7268: - Commit 92bca18dd07644aebe5bffba7d1e4380a9dfaf87 in cordova-mobile-spec's branch refs/heads/master from [~purplecabbage] [ https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;h=92bca18 ] Merge branch 'CB-7268' of https://github.com/MSOpenTech/cordova-mobile-spec Provide option for adding Windows universal platform to mobilespec application -- Key: CB-7268 URL: https://issues.apache.org/jira/browse/CB-7268 Project: Apache Cordova Issue Type: Improvement Components: mobile-spec Reporter: Vladimir Kotikov Priority: Minor Labels: mobilespec, windows Since Windows universal apps support landed to cordova-windows master, mobile-spec project still doesn't have an option for adding Univarsal windows platform to mobilespec application. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7129) Switch to nodejs for windows platform scripts
[ https://issues.apache.org/jira/browse/CB-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091422#comment-14091422 ] ASF GitHub Bot commented on CB-7129: Github user asfgit closed the pull request at: https://github.com/apache/cordova-windows/pull/38 Switch to nodejs for windows platform scripts - Key: CB-7129 URL: https://issues.apache.org/jira/browse/CB-7129 Project: Apache Cordova Issue Type: Improvement Components: Windows 8 Affects Versions: 3.6.0 Reporter: Vladimir Kotikov Assignee: Jesse MacFadyen Fix For: 3.6.0 Current realization of platform/tooling scripts on Windows is using WSH (Windows Scripting Host) as JS engine which works unpredictable with unicode symbols (incorrect reading/writing of UTF-8 encoded files, incorect passing of unicode paths as arguments to another scripts, etc.) Switching to NodeJS can help to resolve many of unicode related issues in cordova-windows projects. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-7129) Switch to nodejs for windows platform scripts
[ https://issues.apache.org/jira/browse/CB-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091421#comment-14091421 ] ASF subversion and git services commented on CB-7129: - Commit f6cc12510471ec4a96f7baec59c50416c57b6ae7 in cordova-windows's branch refs/heads/master from sgrebnov [ https://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;h=f6cc125 ] CB-7129 spellcheck Switch to nodejs for windows platform scripts - Key: CB-7129 URL: https://issues.apache.org/jira/browse/CB-7129 Project: Apache Cordova Issue Type: Improvement Components: Windows 8 Affects Versions: 3.6.0 Reporter: Vladimir Kotikov Assignee: Jesse MacFadyen Fix For: 3.6.0 Current realization of platform/tooling scripts on Windows is using WSH (Windows Scripting Host) as JS engine which works unpredictable with unicode symbols (incorrect reading/writing of UTF-8 encoded files, incorect passing of unicode paths as arguments to another scripts, etc.) Switching to NodeJS can help to resolve many of unicode related issues in cordova-windows projects. -- This message was sent by Atlassian JIRA (v6.2#6252)
