[jira] [Commented] (CB-6911) Geolocation fails in iOS 8 - deprecated attempt to access property errors
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126705#comment-14126705 ] Shazron Abdullah commented on CB-6911: -- This problem crops up whenever any object off navigator is called after cordova.js is loaded. I didn't have any plugins loaded. To test this, I have a button that will alert the navigator.userAgent value to the screen. 1. If cordova.js is loaded before the alert is triggered, the error shows in the console 2. If cordova.js is not loaded at all, and the alert is triggered, no error is show in the console Something in cordova.js is causing this. This error seems to be harmless however (so far -- but eventually this has to be fixed), the values off navigator can be accessed properly. Changing this component to a cordova-js issue. Geolocation fails in iOS 8 - deprecated attempt to access property errors --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: Plugin Geolocation Environment: iOS 8 beta 1 Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CB-6911) Geolocation fails in iOS 8 - deprecated attempt to access property errors
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-6911: - Component/s: (was: Plugin Geolocation) CordovaJS Geolocation fails in iOS 8 - deprecated attempt to access property errors --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: CordovaJS Environment: iOS 8 beta 1 Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-6911: - Summary: iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator (was: Geolocation fails in iOS 8 - deprecated attempt to access property errors) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: CordovaJS Environment: iOS 8 beta 1 Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-6911: - Environment: iOS 8 beta 5 (device) (was: iOS 8 beta 1) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: CordovaJS Environment: iOS 8 beta 5 (device) Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126708#comment-14126708 ] Shazron Abdullah commented on CB-6911: -- The JS that is causing this: https://github.com/apache/cordova-js/blob/26e3e49e49b2fb61ca836572af85c7a776ea9f1c/src/common/init.js#L46-L65 iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: CordovaJS Environment: iOS 8 beta 5 (device) Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7452) Windows. Rewrite ApplyPlatformConfig.ps1 using NodeJS
[ https://issues.apache.org/jira/browse/CB-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126735#comment-14126735 ] ASF GitHub Bot commented on CB-7452: Github user sgrebnov commented on the pull request: https://github.com/apache/cordova-windows/pull/42#issuecomment-54937775 @purplecabbage Hey Jesse, could you please take a look and let me know your opinion regarding this? Windows. Rewrite ApplyPlatformConfig.ps1 using NodeJS - Key: CB-7452 URL: https://issues.apache.org/jira/browse/CB-7452 Project: Apache Cordova Issue Type: Bug Components: Windows Affects Versions: 3.6.0 Reporter: Sergey Grebnov Assignee: Jesse MacFadyen Labels: Windows We've recently switched to NodeJS tooling but still continue to use Powershell to parse config.xml and apply configuration params (ApplyPlatformConfig.ps1). I see the following motivation to re-write ApplyPlatformConfig using NodeJS. 1. More easy to contribute since most of Cordova contributors are experienced in Node and don't know PS 2. More easy to maintain and modify in the future, better integration with the rest of Node tooling 3. We already have most of the configuration processing logic for Windows in cordova-lib so switching to Node should be easy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CB-7452) Windows. Rewrite ApplyPlatformConfig.ps1 using NodeJS
[ https://issues.apache.org/jira/browse/CB-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Grebnov updated CB-7452: --- Assignee: Jesse MacFadyen (was: Sergey Grebnov) Windows. Rewrite ApplyPlatformConfig.ps1 using NodeJS - Key: CB-7452 URL: https://issues.apache.org/jira/browse/CB-7452 Project: Apache Cordova Issue Type: Bug Components: Windows Affects Versions: 3.6.0 Reporter: Sergey Grebnov Assignee: Jesse MacFadyen Labels: Windows We've recently switched to NodeJS tooling but still continue to use Powershell to parse config.xml and apply configuration params (ApplyPlatformConfig.ps1). I see the following motivation to re-write ApplyPlatformConfig using NodeJS. 1. More easy to contribute since most of Cordova contributors are experienced in Node and don't know PS 2. More easy to maintain and modify in the future, better integration with the rest of Node tooling 3. We already have most of the configuration processing logic for Windows in cordova-lib so switching to Node should be easy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7494) cordova-windows fails to build app with unicode name using cordova/build.bat script
[
https://issues.apache.org/jira/browse/CB-7494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126741#comment-14126741
]
ASF GitHub Bot commented on CB-7494:
Github user sgrebnov commented on a diff in the pull request:
https://github.com/apache/cordova-windows/pull/44#discussion_r17287461
--- Diff: windows/bin/lib/create.js ---
@@ -66,8 +68,8 @@ module.exports.run = function (argv) {
[package.windows.appxmanifest, package.windows80.appxmanifest,
package.phone.appxmanifest].forEach(function (file) {
var fileToReplace = path.join(projectPath, file);
shell.sed('-i', /\$guid1\$/g, guid, fileToReplace);
-shell.sed('-i', /\$safeprojectname\$/g, safeAppName,
fileToReplace);
-shell.sed('-i', /\$projectname\$/g, packageName, fileToReplace);
+shell.sed('-i', /\$safeprojectname\$/g, packageName,
fileToReplace);
--- End diff --
Vladimir, could you please also file separate issue to correct placeholders
names; looks like
$(safe)projectname is actually a package name. I would refine those names
moving forward
cordova-windows fails to build app with unicode name using cordova/build.bat
script
---
Key: CB-7494
URL: https://issues.apache.org/jira/browse/CB-7494
Project: Apache Cordova
Issue Type: Bug
Components: Windows
Reporter: Vladimir Kotikov
Repro steps (in cordova-windows repo):
{{windows\bin\create testcreate 応用 com.test.app 応用}}
{{.windows\testcreate 応用\cordova\build}}
Expected:
App builds successfully.
Actual:
{noformat}
package.windows80.appxmanifest(35,22): error APPX3032: App manifest
validation failed.
Value '応用' of attribute '/Package/Applications/Application/@Id' is n ot a
valid ASCII Windows ID.
It must contain one or more parts, separated with periods, where each part
contains only characters a-z, A-Z, 0-9, and does no t start with a digit.
[d:\cordova\cordova-windows\windows\testcreate 応用\CordovaApp.Windows80.jsproj]
{noformat}
This doesn't affects CLI
The reason is that bin/create script write app name and app id in wrong
places at *.manifest files
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126748#comment-14126748 ] Shazron Abdullah commented on CB-6911: -- The WebKit error source: https://github.com/WebKit/webkit/blob/master/Source/WebCore/bindings/js/JSDOMBinding.cpp#L543 WebKit issues: https://bugs.webkit.org/show_bug.cgi?id=133559 http://trac.webkit.org/changeset/168385 Tests: https://github.com/WebKit/webkit/blob/0190dd5b8c0272beaa705dbc10863a84a3e6af5e/LayoutTests/js/dom/shadow-navigator-geolocation-in-strict-mode-does-not-throw-expected.txt Basically, what shows up as an error in the Web Inspector, is a warning, and it only shows the first time, when clobbering. If you clobber again, it won't show the warning again. Not sure right now how to fix this warning yet. iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: CordovaJS Environment: iOS 8 beta 5 (device) Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-6259) Add StatusBar row to Platform Support
[ https://issues.apache.org/jira/browse/CB-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126773#comment-14126773 ] ASF GitHub Bot commented on CB-6259: GitHub user kant2002 opened a pull request: https://github.com/apache/cordova-docs/pull/232 CB-6259 Add StatusBar row to Platform Support Addede StatusBar row to Platform Support table. You can merge this pull request into a Git repository by running: $ git pull https://github.com/kant2002/cordova-docs master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-docs/pull/232.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 #232 commit 452727a280d1ad297485753a50373dcc2df86514 Author: Andrey Kurdyumov kant2...@gmail.com Date: 2014-09-09T08:55:06Z CB-6259 Add StatusBar row to Platform Support Addede StatusBar row to Platform Support table. Add StatusBar row to Platform Support - Key: CB-6259 URL: https://issues.apache.org/jira/browse/CB-6259 Project: Apache Cordova Issue Type: Bug Components: Docs Reporter: Shazron Abdullah Platform Support: http://cordova.apache.org/docs/en/3.4.0/guide_support_index.md.html#Platform%20Support StatusBar Docs: https://github.com/apache/cordova-plugin-statusbar/blob/dev/README.md -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[
https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126787#comment-14126787
]
Shazron Abdullah commented on CB-6911:
--
Solved, I think.
Add this:
{code}
} else {
(function(k) {
newNavigator.__defineGetter__(k, function(){
return origNavigator[k];
});
})(key);
}
{code}
... by replacing this line:
https://github.com/apache/cordova-js/blob/26e3e49e49b2fb61ca836572af85c7a776ea9f1c/src/common/init.js#L58
iOS 8 - deprecated attempt to access property errors when accessing
anything off window.navigator
---
Key: CB-6911
URL: https://issues.apache.org/jira/browse/CB-6911
Project: Apache Cordova
Issue Type: Sub-task
Components: CordovaJS
Environment: iOS 8 beta 5 (device)
Reporter: Jeff Schilling
Assignee: Shazron Abdullah
Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot
2014-09-04 at 9.30.58 pm.png
references to window.navigator.* (platform, geolocation) etc fail with
Deprecated attempt to access property 'geolocation' on a non-Navigator object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[
https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126787#comment-14126787
]
Shazron Abdullah edited comment on CB-6911 at 9/9/14 9:51 AM:
--
Solved, I think.
Add this non-standard (browser support:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/__defineGetter__#Browser_compatibility):
{code}
} else {
(function(k) {
newNavigator.__defineGetter__(k, function(){
return origNavigator[k];
});
})(key);
}
{code}
OR this standard usage (browser support:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/__defineGetter__#Browser_compatibility)
{code}
} else {
(function(k) {
Object.defineProperty(newNavigator, k, {
get: function() {
return origNavigator[k];
},
configurable: true,
enumerable: true
});
})(key);
}
{code}
... by replacing this line:
https://github.com/apache/cordova-js/blob/26e3e49e49b2fb61ca836572af85c7a776ea9f1c/src/common/init.js#L58
was (Author: shazron):
Solved, I think.
Add this:
{code}
} else {
(function(k) {
newNavigator.__defineGetter__(k, function(){
return origNavigator[k];
});
})(key);
}
{code}
... by replacing this line:
https://github.com/apache/cordova-js/blob/26e3e49e49b2fb61ca836572af85c7a776ea9f1c/src/common/init.js#L58
iOS 8 - deprecated attempt to access property errors when accessing
anything off window.navigator
---
Key: CB-6911
URL: https://issues.apache.org/jira/browse/CB-6911
Project: Apache Cordova
Issue Type: Sub-task
Components: CordovaJS
Environment: iOS 8 beta 5 (device)
Reporter: Jeff Schilling
Assignee: Shazron Abdullah
Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot
2014-09-04 at 9.30.58 pm.png
references to window.navigator.* (platform, geolocation) etc fail with
Deprecated attempt to access property 'geolocation' on a non-Navigator object.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126822#comment-14126822 ] Angus Bremner commented on CB-6911: --- Hi Shazron Thanks for looking into this. I am trying to see if your patch works, although every time I build my cordova.js is overwritten and the fix is removed. Is there a way to update this on an existing cordova project? Thanks. iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: CordovaJS Environment: iOS 8 beta 5 (device) Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7490) InAppBrowser manual tests crashes application on windows platform
[ https://issues.apache.org/jira/browse/CB-7490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126863#comment-14126863 ] ASF subversion and git services commented on CB-7490: - Commit f90e5714304235f739a4afabeea990ecb4869868 in cordova-plugin-inappbrowser's branch refs/heads/master from [~vladimir.kotikov] [ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-inappbrowser.git;h=f90e571 ] CB-7490 Fixes InAppBrowser manual tests crash on windows platform InAppBrowser manual tests crashes application on windows platform - Key: CB-7490 URL: https://issues.apache.org/jira/browse/CB-7490 Project: Apache Cordova Issue Type: Bug Components: Plugin InAppBrowser Environment: Windows 8/8.1/WP8.1 device. Reporter: Vladimir Kotikov Mobilespec application crashes when trying to start InAppBrowser plugin manual tests. When opened in Visual Studio, following error message is shown before failure: !https://raw.githubusercontent.com/MSOpenTech/winstore-jscompat/master/error.PNG?token=3019602__eyJzY29wZSI6IlJhd0Jsb2I6TVNPcGVuVGVjaC93aW5zdG9yZS1qc2NvbXBhdC9tYXN0ZXIvZXJyb3IuUE5HIiwiZXhwaXJlcyI6MTQwNjU3OTYyOX0%3D--101970399d1c4e94bbe251e71e78f8be6af6d7ba! Problem is that manipulating DOM using innerHtml property of elemets is considered unsafe on windows platform and may cause exceptions, when injected HTM is invalid or contains unsafe elements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CB-7490) InAppBrowser manual tests crashes application on windows platform
[ https://issues.apache.org/jira/browse/CB-7490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Kotikov resolved CB-7490. -- Resolution: Fixed InAppBrowser manual tests crashes application on windows platform - Key: CB-7490 URL: https://issues.apache.org/jira/browse/CB-7490 Project: Apache Cordova Issue Type: Bug Components: Plugin InAppBrowser Environment: Windows 8/8.1/WP8.1 device. Reporter: Vladimir Kotikov Mobilespec application crashes when trying to start InAppBrowser plugin manual tests. When opened in Visual Studio, following error message is shown before failure: !https://raw.githubusercontent.com/MSOpenTech/winstore-jscompat/master/error.PNG?token=3019602__eyJzY29wZSI6IlJhd0Jsb2I6TVNPcGVuVGVjaC93aW5zdG9yZS1qc2NvbXBhdC9tYXN0ZXIvZXJyb3IuUE5HIiwiZXhwaXJlcyI6MTQwNjU3OTYyOX0%3D--101970399d1c4e94bbe251e71e78f8be6af6d7ba! Problem is that manipulating DOM using innerHtml property of elemets is considered unsafe on windows platform and may cause exceptions, when injected HTM is invalid or contains unsafe elements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126877#comment-14126877 ] Fabian Diehl commented on CB-6911: -- Hi Shazron, I can confirm both of your replacements work fine! iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: CordovaJS Environment: iOS 8 beta 5 (device) Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126822#comment-14126822 ] Angus Bremner edited comment on CB-6911 at 9/9/14 11:05 AM: Hi Shazron Thanks for looking into this. I am trying to see if your patch works, although every time I build my cordova.js is overwritten and the fix is removed. Is there a way to update this on an existing cordova project? EDIT: I was able to edit cordova.js directly in Xcode and can also confirm the deprecated attempt to access property errors no longer appear. Thanks! was (Author: abremner): Hi Shazron Thanks for looking into this. I am trying to see if your patch works, although every time I build my cordova.js is overwritten and the fix is removed. Is there a way to update this on an existing cordova project? Thanks. iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: CordovaJS Environment: iOS 8 beta 5 (device) Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7499) Cordova dialogs should support BIDI text
[
https://issues.apache.org/jira/browse/CB-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14126974#comment-14126974
]
ASF GitHub Bot commented on CB-7499:
GitHub user mbillau opened a pull request:
https://github.com/apache/cordova-plugin-dialogs/pull/32
Set dialog text dir to locale
First part of the patch for CB-7499; sets the text direction on dialog
messages to follow the locale.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/mbillau/cordova-plugin-dialogs CB-7499
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cordova-plugin-dialogs/pull/32.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 #32
commit c88acd6ae9b4533d76605ee4876bf914ccd252e0
Author: mbillau mike.bil...@gmail.com
Date: 2014-09-09T13:20:33Z
Set dialog text dir to locale
Cordova dialogs should support BIDI text
Key: CB-7499
URL: https://issues.apache.org/jira/browse/CB-7499
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Dialogs
Affects Versions: Master
Reporter: Mike Billau
Assignee: Mike Billau
Priority: Minor
Labels: bidirectional, globalization
Since API 19, Andorid has had the facilities to deal with bidirectional text,
however, current Cordova notification implementation does not correctly
handle bidirectional text in dialogs.
We can see this is the case by first setting the language to Hebrew and then
launching the following dialogs:
navigator.notification.confirm(Pure English !!!, function(){}, 7);
navigator.notification.confirm(עברית היא שפה מדוברת בIsrael !,
function(){}, 8);
Since we are in Hebrew, the base text direction will be RTL. This means that
when we see the second notification with the Hebrew text, it will be
right-justified. When we click and see the Pure English !!! notication,
because locale is RTL, we should expect to see: !!! Pure English and it
should be right-justified, however, we still see Pure English !!!, left
justified.
http://w3-03.ibm.com/globalization/page/publish/4353
Ideally you should be able to just add android:supportsRtl=true to the
manifest, however, this is doesn't seem to ne enough without setting the text
direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CB-7493) Add e2e test for 'space-in-path' and 'unicode in path/name' for core platforms.
[ https://issues.apache.org/jira/browse/CB-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Kotikov updated CB-7493: - Description: Since we have several issues with unicode in paths and app names it will be great to have automated testing of these cases. Best place to keep these tests is platform repo, so these tests can be ran via come CI service (Appveyor for WP8 and Windows, Travis CI for Android and iOS) For WP8 and windows platforms we already have such tests, so we need just to improve them to test new cases. For Android and iOS it will be necessary to implement tests. Implementation will be very similar to windows/wp8 implementation. was: Since we have several issues with unicode in paths and app names it will be great to have automated testing of these cases. Best place to keep these tests is platform repo, so these tests can be ran via come CI service (Appveyor for WP8 and Windows, Travis CI for Android and iOS) Add e2e test for 'space-in-path' and 'unicode in path/name' for core platforms. --- Key: CB-7493 URL: https://issues.apache.org/jira/browse/CB-7493 Project: Apache Cordova Issue Type: Bug Components: Android, iOS, Windows, WP8 Reporter: Vladimir Kotikov Assignee: Jesse MacFadyen Since we have several issues with unicode in paths and app names it will be great to have automated testing of these cases. Best place to keep these tests is platform repo, so these tests can be ran via come CI service (Appveyor for WP8 and Windows, Travis CI for Android and iOS) For WP8 and windows platforms we already have such tests, so we need just to improve them to test new cases. For Android and iOS it will be necessary to implement tests. Implementation will be very similar to windows/wp8 implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=14126999#comment-14126999 ] ASF GitHub Bot commented on CB-7158: Github user weili-feedhenry closed the pull request at: https://github.com/apache/cordova-plugin-geolocation/pull/21 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: Sub-task Components: Plugin Geolocation Affects Versions: Master Environment: Xcode 6, IOS 8 Beta 3 Reporter: Eric Weiterman Assignee: Shazron Abdullah 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.3.4#6332)
[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=14126998#comment-14126998 ] ASF GitHub Bot commented on CB-7158: Github user weili-feedhenry commented on the pull request: https://github.com/apache/cordova-plugin-geolocation/pull/21#issuecomment-54972445 @shazron Thanks. I will close this now. 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: Sub-task Components: Plugin Geolocation Affects Versions: Master Environment: Xcode 6, IOS 8 Beta 3 Reporter: Eric Weiterman Assignee: Shazron Abdullah 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.3.4#6332)
[jira] [Commented] (CB-7493) Add e2e test for 'space-in-path' and 'unicode in path/name' for core platforms.
[ https://issues.apache.org/jira/browse/CB-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127019#comment-14127019 ] ASF GitHub Bot commented on CB-7493: GitHub user vladimir-kotikov opened a pull request: https://github.com/apache/cordova-android/pull/119 CB-7493 Adds test-build command to package.json Fix for https://issues.apache.org/jira/browse/CB-7493 \+ bonus - travis configuration file. Succesful build log: https://travis-ci.org/vladimir-kotikov/cordova-android You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-android CB-7493 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-android/pull/119.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 #119 commit d52ca93ba64a79422e65ddeaef633e2c21f38bdb Author: Vladimir Kotikov v-vlk...@microsoft.com Date: 2014-09-09T05:59:34Z CB-7493 Adds test-build command to package.json Add e2e test for 'space-in-path' and 'unicode in path/name' for core platforms. --- Key: CB-7493 URL: https://issues.apache.org/jira/browse/CB-7493 Project: Apache Cordova Issue Type: Bug Components: Android, iOS, Windows, WP8 Reporter: Vladimir Kotikov Assignee: Jesse MacFadyen Since we have several issues with unicode in paths and app names it will be great to have automated testing of these cases. Best place to keep these tests is platform repo, so these tests can be ran via come CI service (Appveyor for WP8 and Windows, Travis CI for Android and iOS) For WP8 and windows platforms we already have such tests, so we need just to improve them to test new cases. For Android and iOS it will be necessary to implement tests. Implementation will be very similar to windows/wp8 implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CB-7497) Crash on open app from fresh
[ https://issues.apache.org/jira/browse/CB-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miquel updated CB-7497: --- Remaining Estimate: 2m Original Estimate: 2m Crash on open app from fresh Key: CB-7497 URL: https://issues.apache.org/jira/browse/CB-7497 Project: Apache Cordova Issue Type: Bug Components: Plugin SplashScreen Environment: ios7 iphone 4s Reporter: Miquel Original Estimate: 2m Remaining Estimate: 2m Everytime the app is fresh opened (not in the debugger) Error: *** Terminating app due to uncaught exception 'NSRangeException', reason: 'Cannot remove an observer CDVSplashScreen 0x15d6f010 for the key path frame from UIView 0x15e614b0 because it is not registered as an observer.' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CB-7500) executeScript with callback kills/blurs inAppBrowser window after callback exit
Andreas Imhof created CB-7500: - Summary: executeScript with callback kills/blurs inAppBrowser window after callback exit Key: CB-7500 URL: https://issues.apache.org/jira/browse/CB-7500 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.5.0 Environment: Android 4.4.2 Samsung Galaxy Tab S Reporter: Andreas Imhof Calling Javascript executeScript (inAppBrowser.js) WITH a callback into an inAppBrowser window kills/blurs this IAB window after the callback exits. Somethink like this also is mentioned in the author's comment in method 'injectDeferredObject' in 'inAppBrowser.java' on line 254. After inverstigating, I accidentally found a work-around/solution which helped on my Android 4.4.2 Samsung Galagy Tab S. SOLUTION: In 'inAppBrowser.java' on line 162: jsWrapper = String.format(prompt(JSON.stringify([eval(%%s)]), 'gap-iab://%s'), callbackContext.getCallbackId()); the 'prompt' statement should be assigned to a variable like: jsWrapper = String.format(var r=prompt(JSON.stringify([eval(%%s)]), 'gap-iab://%s'), callbackContext.getCallbackId()); Adding 'var r=' prevents from InAppBrowser window being killed. Don't know why. Tell me... :-) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7499) Cordova dialogs should support BIDI text
[
https://issues.apache.org/jira/browse/CB-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127122#comment-14127122
]
ASF GitHub Bot commented on CB-7499:
GitHub user mbillau opened a pull request:
https://github.com/apache/cordova-android/pull/120
Second part of CB-7499, support RTL text direction
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/mbillau/cordova-android CB-7499
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cordova-android/pull/120.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 #120
commit 88fa4eec948d769b3d0924a40f6e6832fdde29a9
Author: mbillau mike.bil...@gmail.com
Date: 2014-09-09T13:38:15Z
Second part of CB-7499, support RTL text direction
Cordova dialogs should support BIDI text
Key: CB-7499
URL: https://issues.apache.org/jira/browse/CB-7499
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Dialogs
Affects Versions: Master
Reporter: Mike Billau
Assignee: Mike Billau
Priority: Minor
Labels: bidirectional, globalization
Since API 19, Andorid has had the facilities to deal with bidirectional text,
however, current Cordova notification implementation does not correctly
handle bidirectional text in dialogs.
We can see this is the case by first setting the language to Hebrew and then
launching the following dialogs:
navigator.notification.confirm(Pure English !!!, function(){}, 7);
navigator.notification.confirm(עברית היא שפה מדוברת בIsrael !,
function(){}, 8);
Since we are in Hebrew, the base text direction will be RTL. This means that
when we see the second notification with the Hebrew text, it will be
right-justified. When we click and see the Pure English !!! notication,
because locale is RTL, we should expect to see: !!! Pure English and it
should be right-justified, however, we still see Pure English !!!, left
justified.
http://w3-03.ibm.com/globalization/page/publish/4353
Ideally you should be able to just add android:supportsRtl=true to the
manifest, however, this is doesn't seem to ne enough without setting the text
direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CB-7499) Cordova dialogs should support BIDI text
[
https://issues.apache.org/jira/browse/CB-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127130#comment-14127130
]
ASF GitHub Bot commented on CB-7499:
Github user mbillau closed the pull request at:
https://github.com/apache/cordova-android/pull/120
Cordova dialogs should support BIDI text
Key: CB-7499
URL: https://issues.apache.org/jira/browse/CB-7499
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Dialogs
Affects Versions: Master
Reporter: Mike Billau
Assignee: Mike Billau
Priority: Minor
Labels: bidirectional, globalization
Since API 19, Andorid has had the facilities to deal with bidirectional text,
however, current Cordova notification implementation does not correctly
handle bidirectional text in dialogs.
We can see this is the case by first setting the language to Hebrew and then
launching the following dialogs:
navigator.notification.confirm(Pure English !!!, function(){}, 7);
navigator.notification.confirm(עברית היא שפה מדוברת בIsrael !,
function(){}, 8);
Since we are in Hebrew, the base text direction will be RTL. This means that
when we see the second notification with the Hebrew text, it will be
right-justified. When we click and see the Pure English !!! notication,
because locale is RTL, we should expect to see: !!! Pure English and it
should be right-justified, however, we still see Pure English !!!, left
justified.
http://w3-03.ibm.com/globalization/page/publish/4353
Ideally you should be able to just add android:supportsRtl=true to the
manifest, however, this is doesn't seem to ne enough without setting the text
direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CB-7499) Cordova dialogs should support BIDI text
[
https://issues.apache.org/jira/browse/CB-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127131#comment-14127131
]
ASF GitHub Bot commented on CB-7499:
GitHub user mbillau reopened a pull request:
https://github.com/apache/cordova-android/pull/120
Second part of CB-7499, support RTL text direction
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/mbillau/cordova-android CB-7499
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cordova-android/pull/120.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 #120
commit 88fa4eec948d769b3d0924a40f6e6832fdde29a9
Author: mbillau mike.bil...@gmail.com
Date: 2014-09-09T13:38:15Z
Second part of CB-7499, support RTL text direction
Cordova dialogs should support BIDI text
Key: CB-7499
URL: https://issues.apache.org/jira/browse/CB-7499
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Dialogs
Affects Versions: Master
Reporter: Mike Billau
Assignee: Mike Billau
Priority: Minor
Labels: bidirectional, globalization
Since API 19, Andorid has had the facilities to deal with bidirectional text,
however, current Cordova notification implementation does not correctly
handle bidirectional text in dialogs.
We can see this is the case by first setting the language to Hebrew and then
launching the following dialogs:
navigator.notification.confirm(Pure English !!!, function(){}, 7);
navigator.notification.confirm(עברית היא שפה מדוברת בIsrael !,
function(){}, 8);
Since we are in Hebrew, the base text direction will be RTL. This means that
when we see the second notification with the Hebrew text, it will be
right-justified. When we click and see the Pure English !!! notication,
because locale is RTL, we should expect to see: !!! Pure English and it
should be right-justified, however, we still see Pure English !!!, left
justified.
http://w3-03.ibm.com/globalization/page/publish/4353
Ideally you should be able to just add android:supportsRtl=true to the
manifest, however, this is doesn't seem to ne enough without setting the text
direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CB-7499) Cordova dialogs should support BIDI text
[
https://issues.apache.org/jira/browse/CB-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127129#comment-14127129
]
ASF GitHub Bot commented on CB-7499:
Github user mbillau commented on the pull request:
https://github.com/apache/cordova-android/pull/120#issuecomment-54990566
@infil00p Do you think there will be any issues adding this new attribute
to AndroidManifest.xml?
Cordova dialogs should support BIDI text
Key: CB-7499
URL: https://issues.apache.org/jira/browse/CB-7499
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Dialogs
Affects Versions: Master
Reporter: Mike Billau
Assignee: Mike Billau
Priority: Minor
Labels: bidirectional, globalization
Since API 19, Andorid has had the facilities to deal with bidirectional text,
however, current Cordova notification implementation does not correctly
handle bidirectional text in dialogs.
We can see this is the case by first setting the language to Hebrew and then
launching the following dialogs:
navigator.notification.confirm(Pure English !!!, function(){}, 7);
navigator.notification.confirm(עברית היא שפה מדוברת בIsrael !,
function(){}, 8);
Since we are in Hebrew, the base text direction will be RTL. This means that
when we see the second notification with the Hebrew text, it will be
right-justified. When we click and see the Pure English !!! notication,
because locale is RTL, we should expect to see: !!! Pure English and it
should be right-justified, however, we still see Pure English !!!, left
justified.
http://w3-03.ibm.com/globalization/page/publish/4353
Ideally you should be able to just add android:supportsRtl=true to the
manifest, however, this is doesn't seem to ne enough without setting the text
direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CB-7500) executeScript with callback kills/blurs inAppBrowser window after callback exit
[ https://issues.apache.org/jira/browse/CB-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Imhof updated CB-7500: -- Description: Calling Javascript executeScript (inAppBrowser.js) WITH a callback into an inAppBrowser window kills/blurs this IAB window after the callback exits. Something like this also is mentioned in the author's comment in method 'injectDeferredObject' in 'inAppBrowser.java' on line 254. After inverstigating, I accidentally found a work-around/solution which helped on my Android 4.4.2 Samsung Galagy Tab S. SOLUTION: In 'inAppBrowser.java' on line 162: jsWrapper = String.format(prompt(JSON.stringify([eval(%%s)]), 'gap-iab://%s'), callbackContext.getCallbackId()); the 'prompt' statement should be assigned to a variable like: jsWrapper = String.format(var r=prompt(JSON.stringify([eval(%%s)]), 'gap-iab://%s'), callbackContext.getCallbackId()); Adding 'var r=' prevents from InAppBrowser window being killed. Don't know why. Tell me... :-) was: Calling Javascript executeScript (inAppBrowser.js) WITH a callback into an inAppBrowser window kills/blurs this IAB window after the callback exits. Somethink like this also is mentioned in the author's comment in method 'injectDeferredObject' in 'inAppBrowser.java' on line 254. After inverstigating, I accidentally found a work-around/solution which helped on my Android 4.4.2 Samsung Galagy Tab S. SOLUTION: In 'inAppBrowser.java' on line 162: jsWrapper = String.format(prompt(JSON.stringify([eval(%%s)]), 'gap-iab://%s'), callbackContext.getCallbackId()); the 'prompt' statement should be assigned to a variable like: jsWrapper = String.format(var r=prompt(JSON.stringify([eval(%%s)]), 'gap-iab://%s'), callbackContext.getCallbackId()); Adding 'var r=' prevents from InAppBrowser window being killed. Don't know why. Tell me... :-) executeScript with callback kills/blurs inAppBrowser window after callback exit --- Key: CB-7500 URL: https://issues.apache.org/jira/browse/CB-7500 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.5.0 Environment: Android 4.4.2 Samsung Galaxy Tab S Reporter: Andreas Imhof Labels: patch Original Estimate: 20m Remaining Estimate: 20m Calling Javascript executeScript (inAppBrowser.js) WITH a callback into an inAppBrowser window kills/blurs this IAB window after the callback exits. Something like this also is mentioned in the author's comment in method 'injectDeferredObject' in 'inAppBrowser.java' on line 254. After inverstigating, I accidentally found a work-around/solution which helped on my Android 4.4.2 Samsung Galagy Tab S. SOLUTION: In 'inAppBrowser.java' on line 162: jsWrapper = String.format(prompt(JSON.stringify([eval(%%s)]), 'gap-iab://%s'), callbackContext.getCallbackId()); the 'prompt' statement should be assigned to a variable like: jsWrapper = String.format(var r=prompt(JSON.stringify([eval(%%s)]), 'gap-iab://%s'), callbackContext.getCallbackId()); Adding 'var r=' prevents from InAppBrowser window being killed. Don't know why. Tell me... :-) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CB-7502) iOS default template is missing CFBundleShortVersionString key in Info.plist, prevents iTunes Connect submission
Shazron Abdullah created CB-7502: Summary: iOS default template is missing CFBundleShortVersionString key in Info.plist, prevents iTunes Connect submission Key: CB-7502 URL: https://issues.apache.org/jira/browse/CB-7502 Project: Apache Cordova Issue Type: Bug Components: iOS Reporter: Shazron Abdullah Assignee: Shazron Abdullah The key is inserted when creating a project using cordova create, but when creating a project using bin/create that key is missing. That key is required for iTunes Connect submissions, add to the default template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CB-7501) FILE_URI Can't view images captured in iOS in HTML
Brendan Farr-Gaynor created CB-7501: --- Summary: FILE_URI Can't view images captured in iOS in HTML Key: CB-7501 URL: https://issues.apache.org/jira/browse/CB-7501 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin Camera Affects Versions: 3.5.0, 3.6.0 Environment: Running app in PhoneGap app for iOS so that I can use the camera. Reporter: Brendan Farr-Gaynor Taking a picture with the camera and then trying to assign the FILE_URI to a image tag (img) as the src shows no image, as if the file is missing. A blank image appears. What I have tried: A fresh hello world app with this example: https://gist.githubusercontent.com/cfjedimaster/af298ed2bd0e3ce3ce54/raw/5e5b7804fb86ebfcf2e03f618a04ba384665134a/gistfile1.js Alerting the path shows paths like: file://var/mobile/Applications/FF974729-CA18-4F48-A535-BB3731E1EF9D/tmp/cdv_photo_002.jpg ... but trying to assign that as the src on an image tag does not show the image. If I try to assign an image like one in my assets/img folder or an external web address, that works, but I cannot assign one from the camera. I have tried multiple versions and multiple clean apps. After 6 hours of attempting multiple approaches I feel like this must be a bug in cordova. I can access the image for things like file transfers. Eg. I can upload it to a server, I just can't view it before I do that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=14127203#comment-14127203
]
ASF subversion and git services commented on CB-7291:
-
Commit 37599cb7c9b18da71ace86cd0fd94fdb9efe1641 in cordova-docs's branch
refs/heads/master from [~cmarcelk]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;h=37599cb ]
CB-7291 Fix unintended html tags that hosed rendering.
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)
[jira] [Created] (CB-7503) Keypress event not working with soft keyboard in Android KitKat
Lancho Pat created CB-7503: -- Summary: Keypress event not working with soft keyboard in Android KitKat Key: CB-7503 URL: https://issues.apache.org/jira/browse/CB-7503 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.5.0 Environment: Present in Android 4.4.2, 4.4.4 Not present in 4.1.2 Present with software keyboard Not present with hardware keyboard Reporter: Lancho Pat See https://code.google.com/p/android/issues/detail?id=68284 WebViews don't recieve keypress events in Android 4.4.2 and above. A workaround is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CB-7504) Keypress event not working with soft keyboard in Android KitKat
Lancho Pat created CB-7504: -- Summary: Keypress event not working with soft keyboard in Android KitKat Key: CB-7504 URL: https://issues.apache.org/jira/browse/CB-7504 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.5.0 Environment: Present in Android 4.4.2, 4.4.4 Not present in 4.1.2 Present with software keyboard Not present with hardware keyboard Reporter: Lancho Pat See https://code.google.com/p/android/issues/detail?id=68284 WebViews don't recieve keypress events in Android 4.4.2 and above. A workaround is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CB-7504) Keypress event not working with soft keyboard in Android KitKat
[ https://issues.apache.org/jira/browse/CB-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lancho Pat closed CB-7504. -- Resolution: Duplicate Keypress event not working with soft keyboard in Android KitKat --- Key: CB-7504 URL: https://issues.apache.org/jira/browse/CB-7504 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.5.0 Environment: Present in Android 4.4.2, 4.4.4 Not present in 4.1.2 Present with software keyboard Not present with hardware keyboard Reporter: Lancho Pat Labels: bug,, workaround, Original Estimate: 48h Remaining Estimate: 48h See https://code.google.com/p/android/issues/detail?id=68284 WebViews don't recieve keypress events in Android 4.4.2 and above. A workaround is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7423) mobilespec test failures on iOS
[
https://issues.apache.org/jira/browse/CB-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127457#comment-14127457
]
ASF GitHub Bot commented on CB-7423:
GitHub user eymorale opened a pull request:
https://github.com/apache/cordova-mobile-spec/pull/107
CB-7423 change failing whitelist test by adding a pattern it should matc...
...h
Previous test was assuming that the pattern file:///* was added to the
whitelist in the Whitelist constructor. However, that was changed in Android
and wasn't true for iOS. So the test would fail with no pattern added to the
whitelist.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/eymorale/cordova-mobile-spec CB-7423
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cordova-mobile-spec/pull/107.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 #107
commit 7e9bd4882082d9d5722319a6562cb4c7a20779ba
Author: Edna Morales eymor...@us.ibm.com
Date: 2014-09-09T19:40:25Z
CB-7423 change failing whitelist test by adding a pattern it should match
mobilespec test failures on iOS
---
Key: CB-7423
URL: https://issues.apache.org/jira/browse/CB-7423
Project: Apache Cordova
Issue Type: Bug
Components: Plugin File, Plugin File Transfer
Affects Versions: 3.5.0
Environment: iOS
Reporter: Edna Morales
Fix For: 3.6.0
Running the automated tests for each plugin individually (there are false
failures when run all together in mobilespec) results in the following:
File-transfer - 3 failures:
-spec 8 should be able to download a file using https: error timeout - async
callback was not invoked...
-spec 28 should be able to download a file using local paths: reference error
can't find variable lastProgressEvent in file:///...
-spec 29 should be able to upload a file using local paths: reference error
can't find variable lastProgressEvent in file:///...
File - 2 failures (only after running a second time)
-spec 57 copyTo file: Error copying file {code:12}
-spec 60 copyTo directory to backup at same root directory: Error copying
directory {code:12}
It looks like the files aren't getting deleted after the first run, which is
causing these errors the second time
Plugin manual tests:
Camera:
-Not seeing a difference with different quality values
-Call to write/copy/upload fails if one is called after the other (i.e. Call
to copy succeeds but call to upload fails if done right after the call to
copy)
Native Auto Tests:
Whitelist - 1 failure:
-Match function should accept file:///foo.html for []: Expected spy unknown
to have been called with [true] but was called with [[false]]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CB-7505) xCode Project breaks after changing App Name
Ross Gerbasi created CB-7505: Summary: xCode Project breaks after changing App Name Key: CB-7505 URL: https://issues.apache.org/jira/browse/CB-7505 Project: Apache Cordova Issue Type: Bug Components: CLI, iOS Reporter: Ross Gerbasi If you change the app name in config.xml and run 'cordova prepare ios' or 'cordova build ios' the xcode project gets messed up and builds do not work anymore. It appears that files are being renamed properly 'App.xcodeproj' and the 'App' folder inside of ios are properly changed. But if you open the xcodeproj you can see that the Name of the app has not been changed and the build settings are lost. On my machine after a rename I am left with only the ability to build for Mac 64-bit, all the phone builds are removed :/ Steps to reproduce 'cordova create TestApp' 'cd TestApp' 'cordova platform add ios' open the xcode project and look at the name (all is good) change name in config.xml 'cordova prepare ios' open the code project and sadness... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-7459) Allow automatic tests to be run for specific plugin(s)
[ https://issues.apache.org/jira/browse/CB-7459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127478#comment-14127478 ] Jason Chase commented on CB-7459: - Pull request updated to address latest feedback Allow automatic tests to be run for specific plugin(s) -- Key: CB-7459 URL: https://issues.apache.org/jira/browse/CB-7459 Project: Apache Cordova Issue Type: Improvement Components: mobile-spec Reporter: Jason Chase Assignee: Michal Mocny Priority: Minor Currently, the mobile spec test runner will discover automatic tests for all plugins, and then run all discovered tests en masse. When working on a specific issue/plugin, it would be convenient to be able to run tests for a single plugin (or small subset of plugins). The test framework already supports the concept of enabling/disabling tests for plugins, but that is not exposed in the UI for the test runner. Proposed changes: * On the Auto Tests page for plugins, provide a UI to individually select which tests should be run. This UI should allow for multi-select of plugins. * The UI for test selection should indicate the existing enabled status of each plugin * When the page is initially loaded, keep the existing behaviour, where all enabled plugin tests are automatically run * Subsequent runs (i.e. using the existing Again button) will reflect any user changes to the selected tests -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-6230) InAppBrowser closes after opening, instead of before
[
https://issues.apache.org/jira/browse/CB-6230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127746#comment-14127746
]
Jacob Weber commented on CB-6230:
-
Were you able to reproduce this? I don't want to get stuck on an old version of
Cordova.
InAppBrowser closes after opening, instead of before
Key: CB-6230
URL: https://issues.apache.org/jira/browse/CB-6230
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin InAppBrowser
Affects Versions: 3.4.0, 3.5.0
Environment: Android 4.3, Galaxy Nexus
Reporter: Jacob Weber
In Cordova 3.4, with InAppBrowser 0.3.3, create a new project using the CLI.
In www/js/index.js, make the following change:
{noformat}
onDeviceReady: function() {
app.receivedEvent('deviceready');
document.addEventListener('click', function() {
if (window.myWindow) window.myWindow.close();
window.myWindow = window.open('http://www.google.com', _blank);
});
},
{noformat}
Tap the page once, and a browser will appear. Close the browser. Then tap the
app again. This time the browser will appear for a split second, then close
right away. The close() call seems to be happening after the subsequent
open() call, instead of before it.
This was working in 3.3, with InAppBrowser 0.2.5.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127949#comment-14127949 ] ASF GitHub Bot commented on CB-6911: GitHub user shazron opened a pull request: https://github.com/apache/cordova-js/pull/80 CB-6911 - iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator Tested on iOS 8 UIWebView. Any attempt to call the bridge will result in: Deprecated attempt to access property 'userAgent' on a non-Navigator object. in the console of the Web Inspector. Object.defineProperty seems to have broad support in mobile browsers: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/__defineGetter__#Browser_compatibility Not sure about IE Mobile, that's why I sent this pull request for discussion since these files are common for all platforms. The (safe) alternative is to add this code for iOS only. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shazron/cordova-js CB-6911 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-js/pull/80.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 #80 commit 6c7a76fcd2f0aa60e0879d1417e1ac0ca44f2c6c Author: Shazron Abdullah shaz...@apache.org Date: 2014-09-10T02:09:28Z CB-6911 - iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: CordovaJS Environment: iOS 8 beta 5 (device) Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-6911) iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator
[ https://issues.apache.org/jira/browse/CB-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127966#comment-14127966 ] ASF GitHub Bot commented on CB-6911: Github user uipoet commented on the pull request: https://github.com/apache/cordova-js/pull/80#issuecomment-55064551 Thank you @shazron! Watching for acceptance of this soon, hopefully. iOS 8 - deprecated attempt to access property errors when accessing anything off window.navigator --- Key: CB-6911 URL: https://issues.apache.org/jira/browse/CB-6911 Project: Apache Cordova Issue Type: Sub-task Components: CordovaJS Environment: iOS 8 beta 5 (device) Reporter: Jeff Schilling Assignee: Shazron Abdullah Attachments: Screen Shot 2014-09-01 at 9.03.30 pm.png, Screen Shot 2014-09-04 at 9.30.58 pm.png references to window.navigator.* (platform, geolocation) etc fail with Deprecated attempt to access property 'geolocation' on a non-Navigator object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-6667) window.requestFileSystem - callbacks are not fired in a particular circumstance
[ https://issues.apache.org/jira/browse/CB-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14127998#comment-14127998 ] Zhang Zengbo commented on CB-6667: -- Hello, as https://issues.apache.org/jira/browse/CB-6761 is marked as resolved but I found it maybe not, could you please see the latest two comments and the attach file of that issue, I don't know how that is related to this issue. window.requestFileSystem - callbacks are not fired in a particular circumstance --- Key: CB-6667 URL: https://issues.apache.org/jira/browse/CB-6667 Project: Apache Cordova Issue Type: Bug Components: Plugin File Affects Versions: 3.4.0 Environment: Mac OS X 10.9.2 Android SDK (latest) - API v19 Eclipse 4.2.2 Reporter: Kelvin Dart Priority: Critical Labels: Android4.4.x, Cordova, androidmanifest.xml, window Excuse the essay, but I have a very odd issue that I have singled down to Cordova which happens in a very specific circumstance on Android. I have provided a project of the stock Cordova Android project which can be found here: http://www.filedropper.com/windowfstest - with a minor modification for the issue I am having. I have uploaded a compiled APK to install to your device here: http://www.filedropper.com/windowfstest140509-1404 Steps to replicate are: 1) Download and install that APK onto your device (I was using the Samsung Galaxy S4 with Android 4.4.2 running, no root, and stock TouchWiz ROM, I *hope* this occurs on other Android devices but have not had an opportunity to verify). 2) Start the application and observe an alert appears stating 'dr', then afterwards another alert appears, 'got FS' - if you check the code, you'll see this is normal from my app.initialize(). 3) Once those two alerts have appeared, press the Android 'home' button, to quit to the main Android home screen. 4) Go into another app or two and just use your phone normally. What we are trying to achieve here is for the Android memory management system to 'end'/kill the WindowFSTest app in the backend. 5) Go into Apps WindowFSTest (i.e. the app in question) and hopefully it will have restarted - the app has to have restarted for the bug to occur, and observe a few things here: a) Verify the app has restarted, this can be verified by the 'dr' popup occuring when Cordova loads. b) Once you are confident the app has been restarted, observe the initial 'dr' popup, but *not* the 'got FS' popup - this is the bug, the window.requestFileSystem does not fire the callbacks for some reason - and I do not know why. N.b. there are a few things to note here which is why the bug is tricky to replicate AND I imagine will be even more difficult to debug at a lower level ;-) 1) The Android system has to kill the app in the backend once you've pressed the 'home' button - there's no way of determining when this has happened, just use the phone like ordinary for half a minute or so - normally it kills it after a short period. 2) The way to restart the app is via Apps WindowFSTest (not via the task manager). 3) ***IMPORTANT*** the above two steps seem to occur only when you run it from a compiled APK, not directly from source/debug APK - so it's not as easy to debug since you cannot put line breaks in the Java file(s). Although not perfect, one way to fix this is to use: android:launchMode=singleTop In AndroidManifest.xml - since it ensures the app is 'resumed' instead of restarted. I can provide a video upon request illustrating the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CB-7506) Media Plugin doesnt play in iOS 8
Tom Krones created CB-7506: -- Summary: Media Plugin doesnt play in iOS 8 Key: CB-7506 URL: https://issues.apache.org/jira/browse/CB-7506 Project: Apache Cordova Issue Type: Bug Reporter: Tom Krones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CB-7506) Media Plugin doesnt play in iOS 8
[ https://issues.apache.org/jira/browse/CB-7506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Krones updated CB-7506: --- Component/s: iOS Affects Version/s: 3.5.0 Media Plugin doesnt play in iOS 8 - Key: CB-7506 URL: https://issues.apache.org/jira/browse/CB-7506 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 3.5.0 Reporter: Tom Krones -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CB-7507) Params Not Sent Over HTTPS
Robbie Elias created CB-7507:
Summary: Params Not Sent Over HTTPS
Key: CB-7507
URL: https://issues.apache.org/jira/browse/CB-7507
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 3.5.0
Environment: Android 4.4.4
Reporter: Robbie Elias
The title says it all, I can't access any POST variables in my PHP code when
completing the file transfer over HTTPS. However, this works fine when I use
HTTP.
Here's my code:
{code}
var options = new FileUploadOptions();
options.fileKey = file;
options.fileName = imageURI.substr(imageURI.lastIndexOf('/') + 1);
options.mimeType = text/plain;
var params = {};
params.userid = localStorage.userid;
options.params = params;
var ft = new FileTransfer();
ft.upload(imageURI, encodeURI(https://www.mywebsite.com/upload.php;), win,
fail, options);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
