[jira] [Updated] (CB-12940) Use deployment-target for platform version in Podfile
[ https://issues.apache.org/jira/browse/CB-12940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-12940: -- Fix Version/s: (was: cordova-ios@4.5.0) cordova-ios@4.5.1 > Use deployment-target for platform version in Podfile > - > > Key: CB-12940 > URL: https://issues.apache.org/jira/browse/CB-12940 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-ios >Affects Versions: cordova-ios@4.4.0 >Reporter: Todd Miller >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.1 > > > The current Podfile.js script is hardcoded to set the platform ios version to > 8.0. However, there are some pods that require 9.0 or they will fail to > install. The deployment-target preference should be honored and used when > generating the Podfile. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-12940) Use deployment-target for platform version in Podfile
[ https://issues.apache.org/jira/browse/CB-12940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-12940: -- Labels: backlog (was: backlog ios-next) > Use deployment-target for platform version in Podfile > - > > Key: CB-12940 > URL: https://issues.apache.org/jira/browse/CB-12940 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-ios >Affects Versions: cordova-ios@4.4.0 >Reporter: Todd Miller >Assignee: Shazron Abdullah > Labels: backlog > Fix For: cordova-ios@4.5.1 > > > The current Podfile.js script is hardcoded to set the platform ios version to > 8.0. However, there are some pods that require 9.0 or they will fail to > install. The deployment-target preference should be honored and used when > generating the Podfile. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13240) Update ios-deploy dependency to 1.9.2
Shazron Abdullah created CB-13240: - Summary: Update ios-deploy dependency to 1.9.2 Key: CB-13240 URL: https://issues.apache.org/jira/browse/CB-13240 Project: Apache Cordova Issue Type: Bug Reporter: Shazron Abdullah ios-deploy@1.9.2 contains 2 critical fixes: 1. ability to link ios-deploy in Xcode 9 2. DeviceSupport folder not found deploy errors -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13240) Update ios-deploy dependency to 1.9.2
[ https://issues.apache.org/jira/browse/CB-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-13240: -- Labels: backlog ios-next (was: ) > Update ios-deploy dependency to 1.9.2 > - > > Key: CB-13240 > URL: https://issues.apache.org/jira/browse/CB-13240 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > ios-deploy@1.9.2 contains 2 critical fixes: > 1. ability to link ios-deploy in Xcode 9 > 2. DeviceSupport folder not found deploy errors -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Assigned] (CB-13240) Update ios-deploy dependency to 1.9.2
[ https://issues.apache.org/jira/browse/CB-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah reassigned CB-13240: - Assignee: Shazron Abdullah > Update ios-deploy dependency to 1.9.2 > - > > Key: CB-13240 > URL: https://issues.apache.org/jira/browse/CB-13240 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > ios-deploy@1.9.2 contains 2 critical fixes: > 1. ability to link ios-deploy in Xcode 9 > 2. DeviceSupport folder not found deploy errors -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13240) Update ios-deploy dependency to 1.9.2
[ https://issues.apache.org/jira/browse/CB-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-13240: -- Component/s: cordova-ios > Update ios-deploy dependency to 1.9.2 > - > > Key: CB-13240 > URL: https://issues.apache.org/jira/browse/CB-13240 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > ios-deploy@1.9.2 contains 2 critical fixes: > 1. ability to link ios-deploy in Xcode 9 > 2. DeviceSupport folder not found deploy errors -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13240) Update ios-deploy dependency to 1.9.2
[ https://issues.apache.org/jira/browse/CB-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-13240: -- Fix Version/s: cordova-ios@4.5.0 > Update ios-deploy dependency to 1.9.2 > - > > Key: CB-13240 > URL: https://issues.apache.org/jira/browse/CB-13240 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > ios-deploy@1.9.2 contains 2 critical fixes: > 1. ability to link ios-deploy in Xcode 9 > 2. DeviceSupport folder not found deploy errors -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13240) Update ios-deploy dependency to 1.9.2
[ https://issues.apache.org/jira/browse/CB-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153361#comment-16153361 ] ASF subversion and git services commented on CB-13240: -- Commit 96625be02e3ef504a6c7098a1b05097e35fc3435 in cordova-ios's branch refs/heads/master from [~shazron] [ https://gitbox.apache.org/repos/asf?p=cordova-ios.git;h=96625be ] CB-13240 - Update ios-deploy dependency to 1.9.2 > Update ios-deploy dependency to 1.9.2 > - > > Key: CB-13240 > URL: https://issues.apache.org/jira/browse/CB-13240 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > ios-deploy@1.9.2 contains 2 critical fixes: > 1. ability to link ios-deploy in Xcode 9 > 2. DeviceSupport folder not found deploy errors -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-13240) Update ios-deploy dependency to 1.9.2
[ https://issues.apache.org/jira/browse/CB-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-13240. --- Resolution: Fixed > Update ios-deploy dependency to 1.9.2 > - > > Key: CB-13240 > URL: https://issues.apache.org/jira/browse/CB-13240 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > ios-deploy@1.9.2 contains 2 critical fixes: > 1. ability to link ios-deploy in Xcode 9 > 2. DeviceSupport folder not found deploy errors -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12242) Use yarn js instead of npm when adding plugins
[ https://issues.apache.org/jira/browse/CB-12242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153607#comment-16153607 ] Tim Schumacher commented on CB-12242: - Sorry to dig this issue up, but this is not true, `cordova-fetch` has npm hardcoded and as such prevents me from using yarn. Are there any plans to refactor cordova-fetch? > Use yarn js instead of npm when adding plugins > -- > > Key: CB-12242 > URL: https://issues.apache.org/jira/browse/CB-12242 > Project: Apache Cordova > Issue Type: Wish > Components: cordova-cli, cordova-lib >Reporter: Jacques de Villiers >Priority: Minor > > Currently it can take quite long to add certain plugins to my project (using > cordova plugin add), especially if I need to re-add the plugins. My > suggestion is to update the cordova cli to start using yarn js instead of npm > directly. > When I looked at this page, I realised yarn was just a wrapper for npm, and > much better at caching packages locally. > https://shift.infinite.red/npm-vs-yarn-cheat-sheet-8755b092e5cc#.jiz27n1hc > I would imagine this change would be relatively straightforward, and would be > a massive win for the cli. > I was thinking of creating a fork to do a PR but realised I am not totally > sure how to proceed on this. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-7179) [InAppBrowser][iOS 8] Update to support WKWebView
[ https://issues.apache.org/jira/browse/CB-7179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16125372#comment-16125372 ] Dave Alden edited comment on CB-7179 at 9/5/17 2:04 PM: I'm continuing to push improvements to [my branch|https://github.com/dpa99c/cordova-plugin-themeablebrowser/tree/wkwebview] to iron out remaining issues I've found with using WKWebView to power the IAB. The issues I'm currently aware of in my branch are: * -on changing device orientation, webview content does not resize to fill page- * -closing IAB does not full get rid of webview instance (it still remains visible in Safari Web Inspector)- * security warnings due to iframe injection - need to replace this with proper WKScriptMessageHandler implementation was (Author: dpa99c): I'm continuing to push improvements to [my branch|https://github.com/dpa99c/cordova-plugin-themeablebrowser/tree/wkwebview] to iron out remaining issues I've found with using WKWebView to power the IAB. The issues I'm currently aware of in my branch are: * -on changing device orientation, webview content does not resize to fill page- * closing IAB does not full get rid of webview instance (it still remains visible in Safari Web Inspector) * security warnings due to iframe injection - need to replace this with proper WKScriptMessageHandler implementation > [InAppBrowser][iOS 8] Update to support WKWebView > - > > Key: CB-7179 > URL: https://issues.apache.org/jira/browse/CB-7179 > Project: Apache Cordova > Issue Type: Sub-task > Components: cordova-plugin-inappbrowser > Environment: iOS 8 >Reporter: Shazron Abdullah > > support dual use with UIWebView -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13241) Potential issue with geolocation when device is set to GPS only
Phil Lennon created CB-13241:
Summary: Potential issue with geolocation when device is set to
GPS only
Key: CB-13241
URL: https://issues.apache.org/jira/browse/CB-13241
Project: Apache Cordova
Issue Type: Bug
Components: cordova-android, cordova-plugin-geolocation
Environment: Reproducible by me on: Samsung Galaxy S5 when phone
location settings are set to GPS only.
Error reporting has logged the issue on (based on most first):
Samsung Galaxy S7 (international and European version)
Samsung Galaxy S6 (SM-G920F)
Samsung Galaxy A5 2017 (SM-A520F)
Samsung Galaxy S8 (SM-G950F)
[etc]
The top 15 devices are Samsung with the exception of the Sony Xperia XA (F3111).
There are other devices on the list but they happen a handful of times so could
be false positives or users have poor reception for example.
Of note: Google Pixel and Pixel XL does not appear in the list of devices. I am
also unable to reproduce the issue on Nexus 5X.
Reporter: Phil Lennon
Assignee: Joe Bowser
Pinging [~filmaj] who asked to be assigned this.
My app uses the Geolocation getCurrentPosition() function on both IOS and
Android. I have had an estimated 1.6k Android users unable to get a location
with a timeout error code 3. There are no problems on IOS.
I first try to get location with the following settings:
this.geolocationOptionsFirst = {
enableHighAccuracy: true,
maximumAge: 30,
timeout: 1
}
if that fails I then try again with the following settings:
this.geolocationOptionsSecond = {
enableHighAccuracy: false,
maximumAge: 30,
timeout: 6000
}
The app is failing with a timeout after 16 seconds in total. My testing has
made me believe it's something to do with setting phone location settings to
GPS only. Please see environment for affected devices.
Happy to provide more information if needed. I am available on the
cordova-android Slack channel as frontendphil.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13242) SAP UI5 sap.m.Input maxLength issue
martin Cooper created CB-13242:
--
Summary: SAP UI5 sap.m.Input maxLength issue
Key: CB-13242
URL: https://issues.apache.org/jira/browse/CB-13242
Project: Apache Cordova
Issue Type: Bug
Components: cordova-android
Affects Versions: 6.3.1
Environment: Visual Studio Enterprise 2017
Visual Studio Tools for Apache Cordova 15.113.6201.1
Toolset Name Cordova 6.3.1
Cordova-android 5.2.1
OpenUI5 Distribution: "version": "1.46.7" buildTimestamp: "201705020902"
Reporter: martin Cooper
Assignee: Joe Bowser
Priority: Minor
I have created a hello world UI5 app using a sap.m.input as below:
var myinput1 = new sap.m.Input("myinput_1", {maxLength: 10});
My hello world app works fine on a desktop, but when I use Cordova to compile
it for android, maxlength does not work properly - you can type as many
characters as you like so long as you don’t enter a space. Once you have
entered more than maxLength characters, if you enter a space, the string is
truncated to maxLength.
The desktop version of the app is available here:
http://jsfiddle.net/dn5c3z6j/
As a workaround I have added a liveChange event to all my sap.m.Input controls
as follows:
var myinput1 = new sap.m.Input("myinput_1", {liveChange: function (event) {
setmaxLength(10, event) }, maxLength: 10});
function setmaxLength(len, event) {
if (event.mParameters.value.length > len) {
event.oSource.setValue();//for some reason the value needs to be
cleared before it can be changed
event.oSource.setValue(event.getParameters().value);
}
}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13243) Don't reset default audio session category when release
Yunseok Han created CB-13243: Summary: Don't reset default audio session category when release Key: CB-13243 URL: https://issues.apache.org/jira/browse/CB-13243 Project: Apache Cordova Issue Type: Bug Components: cordova-plugin-media Reporter: Yunseok Han When recording is released, don't set category. all audio output in app is not working. So have to set basic category of avsession to AVAudioSessionCategorySoloAmbient -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13243) Don't reset default audio session category when release
[ https://issues.apache.org/jira/browse/CB-13243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153785#comment-16153785 ] ASF GitHub Bot commented on CB-13243: - GitHub user hannut91 opened a pull request: https://github.com/apache/cordova-plugin-media/pull/147 CB-13243: (iOS) Reset default audio session category when release ### Platforms affected iOS ### What does this PR do? Fix plugin ### What testing has been done on this change? After recording and releasing, can play other audio source output. ### Checklist - [o] [Reported an issue](http://cordova.apache.org/contribute/issues.html) in the JIRA database - [ ] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB- is the JIRA ID & "android" is the platform affected. - [ ] Added automated test coverage as appropriate for this change. You can merge this pull request into a Git repository by running: $ git pull https://github.com/hannut91/cordova-plugin-media master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-media/pull/147.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 #147 commit 87e33cff8ac8b84a2795d267506fb972af840817 Author: yunseok Date: 2017-09-05T14:35:25Z reset default audio session category when release > Don't reset default audio session category when release > --- > > Key: CB-13243 > URL: https://issues.apache.org/jira/browse/CB-13243 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-media >Reporter: Yunseok Han > Labels: ios > > When recording is released, don't set category. > all audio output in app is not working. > So have to set basic category of avsession to > AVAudioSessionCategorySoloAmbient -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13244) Add LaunchImageFileCustom in .plist for work with multiples splashes in iOS projects
Adelmo Luiz de Freitas Junior created CB-13244: -- Summary: Add LaunchImageFileCustom in .plist for work with multiples splashes in iOS projects Key: CB-13244 URL: https://issues.apache.org/jira/browse/CB-13244 Project: Apache Cordova Issue Type: Improvement Components: cordova-plugin-splashscreen Affects Versions: cordova-ios@4.4.0 Reporter: Adelmo Luiz de Freitas Junior Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13245) Filereader.readAsText fails on Android with long text files when
Daniel Behnen created CB-13245: -- Summary: Filereader.readAsText fails on Android with long text files when Key: CB-13245 URL: https://issues.apache.org/jira/browse/CB-13245 Project: Apache Cordova Issue Type: Bug Components: cordova-plugin-file Affects Versions: Master Environment: Android 7.1.1 Reporter: Daniel Behnen When reader.readAsText is called with an URI pointing to a local asset with a size greater than READ_CHUNK_SIZE = 256 * 1024, loading produces corrupt data. The behaviour is caused by a negative length returned by CordovaResourceApi.openForRead() when the URI is a URI_TYPE_ASSET. Given the negative length, Filesystem.readFileAtURL() returns the whole file instead of the desired part and FileReader.readSuccessCallback() does not check the returned buffer size. Hence, the following chunks are attated to the buffer regardless of whether the file was already completely read. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13245) Filereader.readAsText fails on Android with long text files when
[ https://issues.apache.org/jira/browse/CB-13245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154073#comment-16154073 ] ASF GitHub Bot commented on CB-13245: - GitHub user Beatinu opened a pull request: https://github.com/apache/cordova-plugin-file/pull/217 CB-13245: (android) Fix bug caused by negative length reported for an asset ### Platforms affected Android ### What does this PR do? Check the length of CordovaResourceApi.OpenForReadResult in readFileAtURL() to fix loading Android assets with a length greater than FileReader.READ_CHUNK_SIZE. When the length returned is < 0, use InputStream.available() to get the length of compressed assets. ### What testing has been done on this change? Fixes a bug in one of my apps when loading a large .json file into a string. ### Checklist - [X] [Reported an issue](http://cordova.apache.org/contribute/issues.html) in the JIRA database - [X] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB- is the JIRA ID & "android" is the platform affected. - [ ] Added automated test coverage as appropriate for this change. You can merge this pull request into a Git repository by running: $ git pull https://github.com/Beatinu/cordova-plugin-file master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-file/pull/217.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 #217 commit 63fe1b3a91d029f9105be4e55f6fef7ac6392934 Author: Daniel Behnen Date: 2017-09-05T17:21:04Z Use input stream length when input length is negative to fix loading compressed assets > Filereader.readAsText fails on Android with long text files when > > > Key: CB-13245 > URL: https://issues.apache.org/jira/browse/CB-13245 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-file >Affects Versions: Master > Environment: Android 7.1.1 >Reporter: Daniel Behnen > > When reader.readAsText is called with an URI pointing to a local asset with a > size greater than READ_CHUNK_SIZE = 256 * 1024, loading produces corrupt > data. > The behaviour is caused by a negative length returned by > CordovaResourceApi.openForRead() when the URI is a URI_TYPE_ASSET. Given the > negative length, Filesystem.readFileAtURL() returns the whole file instead of > the desired part and FileReader.readSuccessCallback() does not check the > returned buffer size. Hence, the following chunks are attated to the buffer > regardless of whether the file was already completely read. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Assigned] (CB-13241) Potential issue with geolocation when device is set to GPS only
[
https://issues.apache.org/jira/browse/CB-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bowser reassigned CB-13241:
---
Assignee: Filip Maj (was: Joe Bowser)
There's literally nothing that we can do about this, since we defer all
geolocation functionality to the browser once we get the permission for it to
do Geolocation. :(
> Potential issue with geolocation when device is set to GPS only
> ---
>
> Key: CB-13241
> URL: https://issues.apache.org/jira/browse/CB-13241
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-android, cordova-plugin-geolocation
> Environment: Reproducible by me on: Samsung Galaxy S5 when phone
> location settings are set to GPS only.
> Error reporting has logged the issue on (based on most first):
> Samsung Galaxy S7 (international and European version)
> Samsung Galaxy S6 (SM-G920F)
> Samsung Galaxy A5 2017 (SM-A520F)
> Samsung Galaxy S8 (SM-G950F)
> [etc]
> The top 15 devices are Samsung with the exception of the Sony Xperia XA
> (F3111).
> There are other devices on the list but they happen a handful of times so
> could be false positives or users have poor reception for example.
> Of note: Google Pixel and Pixel XL does not appear in the list of devices. I
> am also unable to reproduce the issue on Nexus 5X.
>Reporter: Phil Lennon
>Assignee: Filip Maj
>
> Pinging [~filmaj] who asked to be assigned this.
> My app uses the Geolocation getCurrentPosition() function on both IOS and
> Android. I have had an estimated 1.6k Android users unable to get a location
> with a timeout error code 3. There are no problems on IOS.
> I first try to get location with the following settings:
> this.geolocationOptionsFirst = {
> enableHighAccuracy: true,
> maximumAge: 30,
> timeout: 1
> }
> if that fails I then try again with the following settings:
> this.geolocationOptionsSecond = {
> enableHighAccuracy: false,
> maximumAge: 30,
> timeout: 6000
> }
> The app is failing with a timeout after 16 seconds in total. My testing has
> made me believe it's something to do with setting phone location settings to
> GPS only. Please see environment for affected devices.
> Happy to provide more information if needed. I am available on the
> cordova-android Slack channel as frontendphil.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154092#comment-16154092 ] ASF GitHub Bot commented on CB-13231: - Github user stevengill commented on a diff in the pull request: https://github.com/apache/cordova-docs/pull/724#discussion_r137072952 --- Diff: www/_posts/2017-09-01-cordova-common-2.1.0.md --- @@ -0,0 +1,40 @@ +--- +layout: post +author: +name: Audrey So +url: https://twitter.com/aud_rey_so +title: "Cordova-Common@2.1.0 Released!" +date: 2017-09-01 +categories: news +tags: release tools cordova-common +--- + +We just released some changes to `cordova-common`! + +* [cordova@2.1.0](https://www.npmjs.com/package/cordova-common) + +Release Highlights: +* Support added for `` in `config.xml` +* `allows-arbitrary-loads-for-media` attribute parsing added for `getAccesses` +* Added variable replacing the `framework` tag +* `JSON` uses 2 spaces for indentation + +To update your cordova CLI: --- End diff -- Remove the to update part. It isn't really useful to consumers until after it has been included in next lib + platform releases > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task >Reporter: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154090#comment-16154090 ] ASF GitHub Bot commented on CB-13231: - Github user stevengill commented on a diff in the pull request: https://github.com/apache/cordova-docs/pull/724#discussion_r137072825 --- Diff: www/_posts/2017-09-01-cordova-common-2.1.0.md --- @@ -0,0 +1,40 @@ +--- +layout: post +author: +name: Audrey So +url: https://twitter.com/aud_rey_so +title: "Cordova-Common@2.1.0 Released!" +date: 2017-09-01 +categories: news +tags: release tools cordova-common +--- + +We just released some changes to `cordova-common`! + +* [cordova@2.1.0](https://www.npmjs.com/package/cordova-common) --- End diff -- I would update this to ```[cordova-common@2.1.0](https://www.npmjs.com/package/cordova-common)``` > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task >Reporter: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154091#comment-16154091 ] ASF GitHub Bot commented on CB-13231: - Github user stevengill commented on a diff in the pull request: https://github.com/apache/cordova-docs/pull/724#discussion_r137073157 --- Diff: www/_posts/2017-09-01-cordova-common-2.1.0.md --- @@ -0,0 +1,40 @@ +--- +layout: post +author: +name: Audrey So +url: https://twitter.com/aud_rey_so +title: "Cordova-Common@2.1.0 Released!" +date: 2017-09-01 +categories: news +tags: release tools cordova-common +--- + +We just released some changes to `cordova-common`! + +* [cordova@2.1.0](https://www.npmjs.com/package/cordova-common) + +Release Highlights: +* Support added for `` in `config.xml` +* `allows-arbitrary-loads-for-media` attribute parsing added for `getAccesses` +* Added variable replacing the `framework` tag +* `JSON` uses 2 spaces for indentation + +To update your cordova CLI: --- End diff -- Instead of the update, mention that `watch for this release to start rolling into upcoming platform and cordova-cli releases` > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task >Reporter: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154131#comment-16154131 ] ASF GitHub Bot commented on CB-13231: - Github user asfgit closed the pull request at: https://github.com/apache/cordova-docs/pull/724 > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task >Reporter: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154130#comment-16154130 ] ASF subversion and git services commented on CB-13231: -- Commit 5bb7489523e55e5bb18ca68ef6dc07c1a32a32f5 in cordova-docs's branch refs/heads/master from [~auso] [ https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;h=5bb7489 ] CB-13231 : added cordova-common@2.1.0 release blog post > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task >Reporter: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-12668) support arbitrary creation of resources in the Asset Catalog
[
https://issues.apache.org/jira/browse/CB-12668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154428#comment-16154428
]
Darryl Pogue commented on CB-12668:
---
{{}} is supported in config.xml now, which should allow copying
the resource files into the right spots. We might need to add some special
handling if the target path contains xcassets to update the asset catalogue.
> support arbitrary creation of resources in the Asset Catalog
>
>
> Key: CB-12668
> URL: https://issues.apache.org/jira/browse/CB-12668
> Project: Apache Cordova
> Issue Type: New Feature
> Components: cordova-ios
>Affects Versions: 3.6.4
>Reporter: Josh Sharpe
>Priority: Critical
> Labels: backlog, cordova-ios
> Fix For: cordova-ios@4.5.1
>
>
> A handful of plugins* recommend the use of an image/asset out of the Asset
> Catalog. It would be great if we could create those just by setting tags in
> config.xml, similar to and that then generate the resource in
> Xcode.
> My specific use case is to add a "back" image to be used by
> 'cordova-plugin-themeablebrowser'. I can do this manually by:
> - opening xCode
> - Click on Project -> Resources -> Image.xcassets
> - Click '+' in the bottom task bar -> New Image Set
> - Rename the new Set 'back'
> - Manually drag and drop 3 images into xcode
> To be clear - I'm not asking that cordova produce different sized images as I
> believe that's out of scope. I just need it to build the new resource in
> xcode referencing certain files on disk with tags like:
> {code}
>
>
>
>
>
> {code}
> * Example plugins:
> https://github.com/arnesson/cordova-plugin-firebase
> https://github.codifferent m/phonegap/phonegap-plugin-push
> https://github.com/initialxy/cordova-plugin-themeablebrowser
> **Bonus!**
> It'd be extra great, since I'm sure some folks want this, if cordova could
> add sound files to be used by firebase/push plugins that can leverage those
> if they exist, but I'm not sure how those get set up in xcode such that
> phonegap-plugin-push can use them.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Closed] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Audrey So closed CB-13231. -- Resolution: Done > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task > Components: cordova-common >Affects Versions: 2.1.0 >Reporter: Audrey So >Assignee: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Audrey So updated CB-13231: --- Affects Version/s: 2.1.0 > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task > Components: cordova-common >Affects Versions: 2.1.0 >Reporter: Audrey So >Assignee: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Audrey So updated CB-13231: --- Component/s: cordova-common > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task > Components: cordova-common >Affects Versions: 2.1.0 >Reporter: Audrey So >Assignee: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Assigned] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Audrey So reassigned CB-13231: -- Assignee: Audrey So > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task > Components: cordova-common >Affects Versions: 2.1.0 >Reporter: Audrey So >Assignee: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Closed] (CB-6736) Camera does not come up
[
https://issues.apache.org/jira/browse/CB-6736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jcesarmobile closed CB-6736.
Resolution: Cannot Reproduce
Closing as can't reproduce
Some of the problems mentioned are caused by a missing gap: on the CSP, using
an old versions of plugins or plugins not correctly installed.
> Camera does not come up
>
>
> Key: CB-6736
> URL: https://issues.apache.org/jira/browse/CB-6736
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-plugin-camera
>Affects Versions: 3.4.0
> Environment: IOS 7.11 on Ipod 5
>Reporter: Bernd
> Labels: iOS
>
> Sometimes the camera does not come up. The problem seems to arises, when the
> app is startet after reboot/shutdown. Sometimes 5 out of 10 Pods make trouble
> sometimes none.
> Turning off/on (No shutdown) the ipod fixes the problem and the camera pops
> up.
> {code:none|title=My Javscript Code:}
> getPicture = function (callback,error,myoptions) {
> var options = {
> destinationType: Camera.DestinationType.FILE_URI,
> sourceType: Camera.PictureSourceType.CAMERA,
> encodingType: 0,
> popoverOptions: {
> x: 0,
> y : 32,
> width : 320,
> height : 480,
> arrowDir : Camera.PopoverArrowDirection.ARROW_ANY
> },
> };
> options=$.extend(options , myoptions);
> if (navigator.camera) {
> navigator.camera.getPicture(function (imgData) {
> callback(imgData);
> }, error,options);
> }
> }
> {code}
> {code:none|title=Device log:}
> May 22 15:08:06 kernel[0] : 24.129133 wlan.A[36]
> AppleBCMWLANCore::setProperties(): Active during sleep supported (true)
> May 22 15:08:06 backboardd[28] : |AXIPC|warning| Could not find
> server for service: com.apple.accessibility.gax.springboard
> May 22 15:08:06 backboardd[28] : |AXIPC|warning| client could not
> connect to new service: AXIPCClient:<0x1764dcd0>
> Service:com.apple.accessibility.gax.springboard ID:(null) connected:0 Error
> Domain=AXIPC Code=0 "The operation couldn’t be completed. Could not find
> server for service: com.apple.accessibility.gax.springboard"
> UserInfo=0x17531040 {NSLocalizedFailureReason=Could not find server for
> service: com.apple.accessibility.gax.springboard}
> May 22 15:08:06 aosnotifyd[43] : aosnotifyd has been launched
> May 22 15:08:06 SpringBoard[33] : [Warning] Services all
> disappeared, removing all dependent devices
> May 22 15:08:06 SpringBoard[33] : could not find icon for
> representation -> com.apple.compass
> May 22 15:08:07 SpringBoard[33] : throwing out icon because its
> isn't visible in the model : node= "com.apple.nike"> com.apple.nike
> May 22 15:08:07 SpringBoard[33] : could not find icon for
> representation -> com.apple.mobilephone
> May 22 15:08:07 com.apple.launchd[1] :
> (com.apple.perftools.spinforeverd) Job failed to exec(3). Setting up event to
> tell us when to try again: 2: No such file or directory
> May 22 15:08:07 com.apple.launchd[1] :
> (com.apple.perftools.spinforeverd) Job failed to exec(3) for weird reason: 2
> May 22 15:08:07 SpringBoard[33] : Using your own bundle identifier
> as an NSUserDefaults suite name does not make sense and will not work. Break
> on _NSUserDefaults_Log_Nonsensical_Suites to find this
> May 22 15:08:07 locationd[53] : Launch Services: Registering
> unknown app identifier com.apple.locationd failed
> May 22 15:08:07 locationd[53] : Launch Services: Unable to find app
> identifier com.apple.locationd
> May 22 15:08:07 aosnotifyd[43] : Waiting upto 60 seconds for
> SpringBoard to start...
> May 22 15:08:07 com.apple.launchd[1] : (com.apple.mtrecorder) Job
> failed to exec(3). Setting up event to tell us when to try again: 2: No such
> file or directory
> May 22 15:08:07 com.apple.launchd[1] : (com.apple.mtrecorder) Job
> failed to exec(3) for weird reason: 2
> May 22 15:08:07 syncdefaultsd[95] : (Note ) SYDAlwaysOnAccount: no
> account (null)
> May 22 15:08:07 syncdefaultsd[95] : (Note ) SYDAccount: no account
> May 22 15:08:07 syncdefaultsd[95] : (Note ) SYDPIMAccount: no
> account (null)
> May 22 15:08:07 com.apple.MobileSoftwareUpdate.CleanupPreparePathService[92]
> : 00285000 : partition:1 requiredSize=4503599627370496
> May 22 15:08:07 com.apple.MobileSoftwareUpdate.CleanupPreparePathService[92]
> : 00285000 : maximizing data partition to 14315675647 bytes
> May 22 15:08:07 com.apple.MobileSoftwareUpdate.CleanupPreparePathService[92]
> : 00285000 : entering adjust_partition_preflight
> May 22 15:08:07 backboardd[28] : |AXIPC|warning| Could not find
> server for service: com.apple.accessibility.gax.springboard
> May 22 15:08:07 fud[40] : No need to create item
> May 22 15:08:07 backboa
[jira] [Commented] (CB-12232) [cordova-android] Skipping HTTPS certificate validation should be hidden behind a flag, and not a default in debug builds
[
https://issues.apache.org/jira/browse/CB-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154493#comment-16154493
]
jcesarmobile commented on CB-12232:
---
Increasing priority to Critical
I think we shouldn't ignore ssl certs by default, there should be a flag to
disable them, but default should be to not work and show the error.
We should change the behavior for next major release
I have seen a lot of people not understanding why their apps don't work once
they upload them to Google Play
> [cordova-android] Skipping HTTPS certificate validation should be hidden
> behind a flag, and not a default in debug builds
> -
>
> Key: CB-12232
> URL: https://issues.apache.org/jira/browse/CB-12232
> Project: Apache Cordova
> Issue Type: Improvement
> Components: cordova-android
>Affects Versions: 6.2.0
>Reporter: jakub-g
>Priority: Critical
> Labels: android
>
> Right now, when you create a debuggable Cordova build (default behavior for
> commands like `cordova run android` etc.), it by default ignores all HTTPS
> certificate errors, as you can see in the code below:
> https://github.com/apache/cordova-android/blob/23fd0982b0faa6b7e169c2946eab07930f1f4d16/framework/src/org/apache/cordova/engine/SystemWebViewClient.java#L232-L239
> HTTPS certs are only validated when you create a release build, explicitly
> passing a flag, e.g.
> {{cordova run android --release}}
> This behavior is IMO harmful, and let me tell you why (see below for two
> real-life stories)
> *TL;DR I believe it would be better to not bind the lax HTTPS behavior to
> {{\-\-debug}} vs {{\-\-release}} build type, but hide it behind a special
> flag (to follow Chrome's naming convention, that would be
> {{\-\-ignore-certificate-errors}}, but we can name it whatever we like). This
> would expose developers to HTTPS errors much earlier in the dev process,
> which IMO is beneficial; it will also make it easier to understand and debug
> the problems, and avoid last-minute surprises.*
> _Question: do we have a portion of code already that makes runtime behavior
> depend on build-time flag? i.e. would it be easy to add a new flag in a
> similar way, without herculean effort?_
> So, the promised real-life stories:
> 1) Consider, that you have an HTTPS website and your HTTPS certificate is
> somehow invalid (but you don't know about that). You develop your stuff _for
> weeks and weeks_ in debug builds and everything is great. You prepare for
> grand APK upload to Play Store, do a {{\-\-release}} build, and... stuff
> doesn't work! You want to debug it, but you can't - because {{\-\-release}}
> build is non-debuggable! This looks super mysterious and you're totally
> baffled.
> Doing black-box debugging on --release build ain't easy, but you give it a
> try.
> You're thinking about all possible things that could go wrong (code
> minification? some issue with signing keys? Cordova/Chrome/Android are
> broken?), finally after a while you reach to google and you figure out the
> issue is due to cordova only checking HTTPS certs in {{\-\-release}} mode.
> People tell about self-signed certs, but your cert looks legit, after all, it
> works on all desktop client. But at least you know where to look.
> Luckily for you, the staging platform has a publicly accessible domain name.
> You test your cert with SSLLabs and it tells you that your server doesn't
> send all intermediary certs. It's still not sure if this is the issue, but
> you ask the ops team to update the server.
> They get a better cert and update server config to send the intermediary
> cert. You're saved! This was the missing piece to make the app work.
> 2) Suppose you never had the issue 1), you built an app, it works in
> production, all is well. One day, you change the HTTPS cert in production
> (because an old one expired etc.), you do quick tests, all is well (or, even
> worse: when in big corporation, ops guys change the HTTPS cert without
> telling you). You forget about it, and continue developing your app. You're a
> dev and you're constantly in the Chrome DevTools, so naturally you always
> build debuggable builds. You keep adding features for weeks, all works great
> in your debuggable builds. Your QAs do tests and most often stuff works
> great, but sometimes they're getting weird connection issues. First they
> think it's some weird connectivity issue (poor WiFi etc.), but the issues
> happen more often. Turns out the issue happens _only with --release builds_
> and _only on production server_. There's a fire in production, but no one
> noticed for quite a while since the QA test features mostly on staging
> servers, and devs work with st
[jira] [Updated] (CB-12232) [cordova-android] Skipping HTTPS certificate validation should be hidden behind a flag, and not a default in debug builds
[
https://issues.apache.org/jira/browse/CB-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jcesarmobile updated CB-12232:
--
Priority: Critical (was: Major)
> [cordova-android] Skipping HTTPS certificate validation should be hidden
> behind a flag, and not a default in debug builds
> -
>
> Key: CB-12232
> URL: https://issues.apache.org/jira/browse/CB-12232
> Project: Apache Cordova
> Issue Type: Improvement
> Components: cordova-android
>Affects Versions: 6.2.0
>Reporter: jakub-g
>Priority: Critical
> Labels: android
>
> Right now, when you create a debuggable Cordova build (default behavior for
> commands like `cordova run android` etc.), it by default ignores all HTTPS
> certificate errors, as you can see in the code below:
> https://github.com/apache/cordova-android/blob/23fd0982b0faa6b7e169c2946eab07930f1f4d16/framework/src/org/apache/cordova/engine/SystemWebViewClient.java#L232-L239
> HTTPS certs are only validated when you create a release build, explicitly
> passing a flag, e.g.
> {{cordova run android --release}}
> This behavior is IMO harmful, and let me tell you why (see below for two
> real-life stories)
> *TL;DR I believe it would be better to not bind the lax HTTPS behavior to
> {{\-\-debug}} vs {{\-\-release}} build type, but hide it behind a special
> flag (to follow Chrome's naming convention, that would be
> {{\-\-ignore-certificate-errors}}, but we can name it whatever we like). This
> would expose developers to HTTPS errors much earlier in the dev process,
> which IMO is beneficial; it will also make it easier to understand and debug
> the problems, and avoid last-minute surprises.*
> _Question: do we have a portion of code already that makes runtime behavior
> depend on build-time flag? i.e. would it be easy to add a new flag in a
> similar way, without herculean effort?_
> So, the promised real-life stories:
> 1) Consider, that you have an HTTPS website and your HTTPS certificate is
> somehow invalid (but you don't know about that). You develop your stuff _for
> weeks and weeks_ in debug builds and everything is great. You prepare for
> grand APK upload to Play Store, do a {{\-\-release}} build, and... stuff
> doesn't work! You want to debug it, but you can't - because {{\-\-release}}
> build is non-debuggable! This looks super mysterious and you're totally
> baffled.
> Doing black-box debugging on --release build ain't easy, but you give it a
> try.
> You're thinking about all possible things that could go wrong (code
> minification? some issue with signing keys? Cordova/Chrome/Android are
> broken?), finally after a while you reach to google and you figure out the
> issue is due to cordova only checking HTTPS certs in {{\-\-release}} mode.
> People tell about self-signed certs, but your cert looks legit, after all, it
> works on all desktop client. But at least you know where to look.
> Luckily for you, the staging platform has a publicly accessible domain name.
> You test your cert with SSLLabs and it tells you that your server doesn't
> send all intermediary certs. It's still not sure if this is the issue, but
> you ask the ops team to update the server.
> They get a better cert and update server config to send the intermediary
> cert. You're saved! This was the missing piece to make the app work.
> 2) Suppose you never had the issue 1), you built an app, it works in
> production, all is well. One day, you change the HTTPS cert in production
> (because an old one expired etc.), you do quick tests, all is well (or, even
> worse: when in big corporation, ops guys change the HTTPS cert without
> telling you). You forget about it, and continue developing your app. You're a
> dev and you're constantly in the Chrome DevTools, so naturally you always
> build debuggable builds. You keep adding features for weeks, all works great
> in your debuggable builds. Your QAs do tests and most often stuff works
> great, but sometimes they're getting weird connection issues. First they
> think it's some weird connectivity issue (poor WiFi etc.), but the issues
> happen more often. Turns out the issue happens _only with --release builds_
> and _only on production server_. There's a fire in production, but no one
> noticed for quite a while since the QA test features mostly on staging
> servers, and devs work with staging servers too, and use debuggable builds
> most of the time - and the --release sanity targeting production happens only
> every N weeks before loading to production.
> But finally someone connects the dots that only --release builds targeting
> production server do not work. You want to investigate the issue, and
> obviously, in debug mode it doesn't hap
[jira] [Assigned] (CB-13230) Remove service worker from cordova-browser
[ https://issues.apache.org/jira/browse/CB-13230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Gill reassigned CB-13230: --- Assignee: Jesse MacFadyen (was: Herm Wong) > Remove service worker from cordova-browser > -- > > Key: CB-13230 > URL: https://issues.apache.org/jira/browse/CB-13230 > Project: Apache Cordova > Issue Type: Bug >Affects Versions: 5.0.0 >Reporter: Steve Gill >Assignee: Jesse MacFadyen > Labels: browser-next > Fix For: 5.1.0 > > > It doesn't make sense to include service workers by default in > cordova-browser. We are better off documenting how to add service workers so > our users can do that. I think we need to delete > https://github.com/apache/cordova-browser/blob/master/bin/template/www/cordova-sw.js > and remove any references to cordova-sw.js > https://github.com/apache/cordova-browser/search?utf8=%E2%9C%93&q=cordova-sw.js&type= -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-3232) "cordova platform add blackberry" fails on 2.7.1-rc.1
[
https://issues.apache.org/jira/browse/CB-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154567#comment-16154567
]
ASF GitHub Bot commented on CB-3232:
GitHub user audreyso opened a pull request:
https://github.com/apache/cordova-docs/pull/725
minor updates to README.md
### Platforms affected
### What does this PR do?
Minor updates to README.md.
### What testing has been done on this change?
### Checklist
- [ ] [Reported an issue](http://cordova.apache.org/contribute/issues.html)
in the JIRA database
- [ ] Commit message follows the format: "CB-3232: (android) Fix bug with
resolving file paths", where CB- is the JIRA ID & "android" is the platform
affected.
- [ ] Added automated test coverage as appropriate for this change.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/audreyso/cordova-docs update_release_docs
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cordova-docs/pull/725.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 #725
commit 0d2233831f76c9aabb513804cef6db63f14afa8d
Author: Audrey So
Date: 2017-09-05T23:23:42Z
update README.md
> "cordova platform add blackberry" fails on 2.7.1-rc.1
> -
>
> Key: CB-3232
> URL: https://issues.apache.org/jira/browse/CB-3232
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-blackberry (DEPRECATED), cordova-cli
>Affects Versions: 2.7.0
>Reporter: Michael Brooks
>Assignee: Michael Brooks
> Fix For: 2.7.0
>
>
> The following error is thrown when running {{$ cordova platform add
> blackberry}}:
> {code}
> [Error: An error occured during creation of blackberry sub-project. Creating
> BlackBerry project...
> Updating config.xml ...
> sed:
> /Users/mwbrooks/Dropbox/Development/sandbox/myapp/platforms/blackberry/www/config.xml:
> No such file or directory
> Cleaning up ...
> Remember to update the project.properties file inside your application
> directory!
> ]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Reopened] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Audrey So reopened CB-13231: > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task > Components: cordova-common >Affects Versions: 2.1.0 >Reporter: Audrey So >Assignee: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Closed] (CB-13231) Cordova-Common@2.1.0 Release August 30, 2017
[ https://issues.apache.org/jira/browse/CB-13231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Audrey So closed CB-13231. -- Resolution: Fixed > Cordova-Common@2.1.0 Release August 30, 2017 > > > Key: CB-13231 > URL: https://issues.apache.org/jira/browse/CB-13231 > Project: Apache Cordova > Issue Type: Task > Components: cordova-common >Affects Versions: 2.1.0 >Reporter: Audrey So >Assignee: Audrey So > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-9794) cordova run ios --target does not use versioned simulators
[ https://issues.apache.org/jira/browse/CB-9794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-9794. -- Resolution: Not A Problem Should be fixed > cordova run ios --target does not use versioned simulators > -- > > Key: CB-9794 > URL: https://issues.apache.org/jira/browse/CB-9794 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Jesse MacFadyen >Assignee: Jesse MacFadyen >Priority: Minor > Labels: backlog, cordova-ios-4.1.1, triaged > Fix For: cordova-ios@4.5.1 > > > This stack-overflow points out an issue with the 'validTargets' list of > simulators, and the actual list returned by ios-sim > http://stackoverflow.com/questions/22310526/cordova-start-specific-ios-emulator-image/29705666#29705666 > We need to use the ios-sim device list as validTargets so users can > accurately target 'iPhone-4s, 7.1' ... -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-13215) Support "cordova emulate ios" with --target that includes a runtime version
[ https://issues.apache.org/jira/browse/CB-13215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-13215. --- Resolution: Not A Problem This is fixed in 4.5.0 > Support "cordova emulate ios" with --target that includes a runtime version > --- > > Key: CB-13215 > URL: https://issues.apache.org/jira/browse/CB-13215 > Project: Apache Cordova > Issue Type: New Feature > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog > > See CB-12830 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13212) Update cordova-ios with new cordova-common that parses new attribute for access tag
[ https://issues.apache.org/jira/browse/CB-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-13212: -- Fix Version/s: cordova-ios@4.5.0 > Update cordova-ios with new cordova-common that parses new attribute for > access tag > --- > > Key: CB-13212 > URL: https://issues.apache.org/jira/browse/CB-13212 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > See CB-13211 > Tests already written, but disabled in prepare.spec.js: > 1) prepare updateProject method - should handle wildcard, with > NSAllowsArbitraryLoadsForMedia set (fixed allows-arbitrary-loads-for-media) > Temporarily disabled with xit > 2) prepare updateProject method - should handle wildcard, with > NSAllowsArbitraryLoadsForMedia not set (fixed > allows-arbitrary-loads-for-media) > Temporarily disabled with xit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13212) Update cordova-ios with new cordova-common that parses new attribute for access tag
[ https://issues.apache.org/jira/browse/CB-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-13212: -- Labels: backlog ios-next (was: backlog) > Update cordova-ios with new cordova-common that parses new attribute for > access tag > --- > > Key: CB-13212 > URL: https://issues.apache.org/jira/browse/CB-13212 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > See CB-13211 > Tests already written, but disabled in prepare.spec.js: > 1) prepare updateProject method - should handle wildcard, with > NSAllowsArbitraryLoadsForMedia set (fixed allows-arbitrary-loads-for-media) > Temporarily disabled with xit > 2) prepare updateProject method - should handle wildcard, with > NSAllowsArbitraryLoadsForMedia not set (fixed > allows-arbitrary-loads-for-media) > Temporarily disabled with xit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13212) Update cordova-ios with new cordova-common that parses new attribute for access tag
[ https://issues.apache.org/jira/browse/CB-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154698#comment-16154698 ] ASF subversion and git services commented on CB-13212: -- Commit 53c8daae191a3587c13ddd770cc8cfcf3da82874 in cordova-ios's branch refs/heads/master from [~shazron] [ https://gitbox.apache.org/repos/asf?p=cordova-ios.git;h=53c8daa ] CB-13212 - Update cordova-ios with new cordova-common that parses new attribute for access tag > Update cordova-ios with new cordova-common that parses new attribute for > access tag > --- > > Key: CB-13212 > URL: https://issues.apache.org/jira/browse/CB-13212 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > See CB-13211 > Tests already written, but disabled in prepare.spec.js: > 1) prepare updateProject method - should handle wildcard, with > NSAllowsArbitraryLoadsForMedia set (fixed allows-arbitrary-loads-for-media) > Temporarily disabled with xit > 2) prepare updateProject method - should handle wildcard, with > NSAllowsArbitraryLoadsForMedia not set (fixed > allows-arbitrary-loads-for-media) > Temporarily disabled with xit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-13212) Update cordova-ios with new cordova-common that parses new attribute for access tag
[ https://issues.apache.org/jira/browse/CB-13212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-13212. --- Resolution: Fixed > Update cordova-ios with new cordova-common that parses new attribute for > access tag > --- > > Key: CB-13212 > URL: https://issues.apache.org/jira/browse/CB-13212 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > See CB-13211 > Tests already written, but disabled in prepare.spec.js: > 1) prepare updateProject method - should handle wildcard, with > NSAllowsArbitraryLoadsForMedia set (fixed allows-arbitrary-loads-for-media) > Temporarily disabled with xit > 2) prepare updateProject method - should handle wildcard, with > NSAllowsArbitraryLoadsForMedia not set (fixed > allows-arbitrary-loads-for-media) > Temporarily disabled with xit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Assigned] (CB-13213) Change access tag attribute 'allows-arbitrary-loads-in-media' to 'allows-arbitrary-loads-for-media'
[ https://issues.apache.org/jira/browse/CB-13213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah reassigned CB-13213: - Assignee: Shazron Abdullah > Change access tag attribute 'allows-arbitrary-loads-in-media' to > 'allows-arbitrary-loads-for-media' > --- > > Key: CB-13213 > URL: https://issues.apache.org/jira/browse/CB-13213 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-docs >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog > > See CB-13212 > https://cordova.apache.org/docs/en/latest/guide/appdev/whitelist/index.html#ios-whitelisting -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-13213) Change access tag attribute 'allows-arbitrary-loads-in-media' to 'allows-arbitrary-loads-for-media'
[ https://issues.apache.org/jira/browse/CB-13213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154704#comment-16154704 ] Shazron Abdullah edited comment on CB-13213 at 9/6/17 2:09 AM: --- Deprecate the old attribute. Remove when cordova-ios is moved to a new major version. was (Author: shazron): Deprecate the old tag. Remove when cordova-ios is moved to a new major version. > Change access tag attribute 'allows-arbitrary-loads-in-media' to > 'allows-arbitrary-loads-for-media' > --- > > Key: CB-13213 > URL: https://issues.apache.org/jira/browse/CB-13213 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-docs >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog > > See CB-13212 > https://cordova.apache.org/docs/en/latest/guide/appdev/whitelist/index.html#ios-whitelisting -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13213) Change access tag attribute 'allows-arbitrary-loads-in-media' to 'allows-arbitrary-loads-for-media'
[ https://issues.apache.org/jira/browse/CB-13213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154704#comment-16154704 ] Shazron Abdullah commented on CB-13213: --- Deprecate the old tag. Remove when cordova-ios is moved to a new major version. > Change access tag attribute 'allows-arbitrary-loads-in-media' to > 'allows-arbitrary-loads-for-media' > --- > > Key: CB-13213 > URL: https://issues.apache.org/jira/browse/CB-13213 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-docs >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog > > See CB-13212 > https://cordova.apache.org/docs/en/latest/guide/appdev/whitelist/index.html#ios-whitelisting -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13246) Remove deprecated 'allows-arbitrary-loads-in-media' attribute for access tag
Shazron Abdullah created CB-13246: - Summary: Remove deprecated 'allows-arbitrary-loads-in-media' attribute for access tag Key: CB-13246 URL: https://issues.apache.org/jira/browse/CB-13246 Project: Apache Cordova Issue Type: Bug Components: cordova-docs, cordova-ios Reporter: Shazron Abdullah Assignee: Shazron Abdullah When cordova-ios is moved to a major version (next is v5.0.0) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13246) Remove deprecated 'allows-arbitrary-loads-in-media' attribute for access tag
[ https://issues.apache.org/jira/browse/CB-13246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-13246: -- Fix Version/s: cordova-ios@5.0.0 > Remove deprecated 'allows-arbitrary-loads-in-media' attribute for access tag > > > Key: CB-13246 > URL: https://issues.apache.org/jira/browse/CB-13246 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-docs, cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog > Fix For: cordova-ios@5.0.0 > > > When cordova-ios is moved to a major version (next is v5.0.0) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Assigned] (CB-13246) Remove deprecated 'allows-arbitrary-loads-in-media' attribute for access tag
[ https://issues.apache.org/jira/browse/CB-13246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah reassigned CB-13246: - Assignee: (was: Shazron Abdullah) > Remove deprecated 'allows-arbitrary-loads-in-media' attribute for access tag > > > Key: CB-13246 > URL: https://issues.apache.org/jira/browse/CB-13246 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-docs, cordova-ios >Reporter: Shazron Abdullah > Labels: backlog > Fix For: cordova-ios@5.0.0 > > > When cordova-ios is moved to a major version (next is v5.0.0) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13213) Change access tag attribute 'allows-arbitrary-loads-in-media' to 'allows-arbitrary-loads-for-media'
[ https://issues.apache.org/jira/browse/CB-13213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154724#comment-16154724 ] ASF subversion and git services commented on CB-13213: -- Commit 8f3bdf95fded392c258c4fff3ac369baefa10505 in cordova-docs's branch refs/heads/master from [~shazron] [ https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;h=8f3bdf9 ] CB-13213 - Change access tag attribute 'allows-arbitrary-loads-in-media' to 'allows-arbitrary-loads-for-media' > Change access tag attribute 'allows-arbitrary-loads-in-media' to > 'allows-arbitrary-loads-for-media' > --- > > Key: CB-13213 > URL: https://issues.apache.org/jira/browse/CB-13213 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-docs >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog > > See CB-13212 > https://cordova.apache.org/docs/en/latest/guide/appdev/whitelist/index.html#ios-whitelisting -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Resolved] (CB-13213) Change access tag attribute 'allows-arbitrary-loads-in-media' to 'allows-arbitrary-loads-for-media'
[ https://issues.apache.org/jira/browse/CB-13213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-13213. --- Resolution: Fixed > Change access tag attribute 'allows-arbitrary-loads-in-media' to > 'allows-arbitrary-loads-for-media' > --- > > Key: CB-13213 > URL: https://issues.apache.org/jira/browse/CB-13213 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-docs >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog > > See CB-13212 > https://cordova.apache.org/docs/en/latest/guide/appdev/whitelist/index.html#ios-whitelisting -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13247) Cordova-iOS Platform Release Sept 6, 2017
Shazron Abdullah created CB-13247: - Summary: Cordova-iOS Platform Release Sept 6, 2017 Key: CB-13247 URL: https://issues.apache.org/jira/browse/CB-13247 Project: Apache Cordova Issue Type: Task Components: cordova-ios Reporter: Shazron Abdullah Assignee: Shazron Abdullah Following steps at https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13247) Cordova-iOS Platform Release Sept 6, 2017
[ https://issues.apache.org/jira/browse/CB-13247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-13247: -- Labels: backlog ios-next (was: ) > Cordova-iOS Platform Release Sept 6, 2017 > - > > Key: CB-13247 > URL: https://issues.apache.org/jira/browse/CB-13247 > Project: Apache Cordova > Issue Type: Task > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13247) Cordova-iOS Platform Release Sept 6, 2017
[ https://issues.apache.org/jira/browse/CB-13247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-13247: -- Fix Version/s: cordova-ios@4.5.0 > Cordova-iOS Platform Release Sept 6, 2017 > - > > Key: CB-13247 > URL: https://issues.apache.org/jira/browse/CB-13247 > Project: Apache Cordova > Issue Type: Task > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13247) Cordova-iOS Platform Release Sept 6, 2017
[ https://issues.apache.org/jira/browse/CB-13247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154756#comment-16154756 ] ASF subversion and git services commented on CB-13247: -- Commit 68fa7b6b6bf438007ad2476d05fdb8ee30838bb2 in cordova-ios's branch refs/heads/master from [~shazron] [ https://gitbox.apache.org/repos/asf?p=cordova-ios.git;h=68fa7b6 ] CB-13247 updated checked-in node_modules > Cordova-iOS Platform Release Sept 6, 2017 > - > > Key: CB-13247 > URL: https://issues.apache.org/jira/browse/CB-13247 > Project: Apache Cordova > Issue Type: Task > Components: cordova-ios >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Labels: backlog, ios-next > Fix For: cordova-ios@4.5.0 > > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-12232) [cordova-android] Skipping HTTPS certificate validation should be hidden behind a flag, and not a default in debug builds
[
https://issues.apache.org/jira/browse/CB-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154891#comment-16154891
]
Jan Piotrowski (Sujan) edited comment on CB-12232 at 9/6/17 6:49 AM:
-
Just so it was mentioned: There would also be the option to add an
{code}--show-certificate-errors{code} flag for {code}--debug{code}/default
builds so at least there is an option to debug these errors.
But I don't think it makes sense, because 99% of affected users wouldn't know
about it and be in the same situation as before.
was (Author: sujan12):
Just so it was mentioned: There would also be the option to add an
`--show-certificate-errors` flag for `--debug`/default builds so at least there
is an option to debug these errors.
But I don't think it makes sense, because 99% of affected users wouldn't know
about it and be in the same situation as before.
> [cordova-android] Skipping HTTPS certificate validation should be hidden
> behind a flag, and not a default in debug builds
> -
>
> Key: CB-12232
> URL: https://issues.apache.org/jira/browse/CB-12232
> Project: Apache Cordova
> Issue Type: Improvement
> Components: cordova-android
>Affects Versions: 6.2.0
>Reporter: jakub-g
>Priority: Critical
> Labels: android
>
> Right now, when you create a debuggable Cordova build (default behavior for
> commands like `cordova run android` etc.), it by default ignores all HTTPS
> certificate errors, as you can see in the code below:
> https://github.com/apache/cordova-android/blob/23fd0982b0faa6b7e169c2946eab07930f1f4d16/framework/src/org/apache/cordova/engine/SystemWebViewClient.java#L232-L239
> HTTPS certs are only validated when you create a release build, explicitly
> passing a flag, e.g.
> {{cordova run android --release}}
> This behavior is IMO harmful, and let me tell you why (see below for two
> real-life stories)
> *TL;DR I believe it would be better to not bind the lax HTTPS behavior to
> {{\-\-debug}} vs {{\-\-release}} build type, but hide it behind a special
> flag (to follow Chrome's naming convention, that would be
> {{\-\-ignore-certificate-errors}}, but we can name it whatever we like). This
> would expose developers to HTTPS errors much earlier in the dev process,
> which IMO is beneficial; it will also make it easier to understand and debug
> the problems, and avoid last-minute surprises.*
> _Question: do we have a portion of code already that makes runtime behavior
> depend on build-time flag? i.e. would it be easy to add a new flag in a
> similar way, without herculean effort?_
> So, the promised real-life stories:
> 1) Consider, that you have an HTTPS website and your HTTPS certificate is
> somehow invalid (but you don't know about that). You develop your stuff _for
> weeks and weeks_ in debug builds and everything is great. You prepare for
> grand APK upload to Play Store, do a {{\-\-release}} build, and... stuff
> doesn't work! You want to debug it, but you can't - because {{\-\-release}}
> build is non-debuggable! This looks super mysterious and you're totally
> baffled.
> Doing black-box debugging on --release build ain't easy, but you give it a
> try.
> You're thinking about all possible things that could go wrong (code
> minification? some issue with signing keys? Cordova/Chrome/Android are
> broken?), finally after a while you reach to google and you figure out the
> issue is due to cordova only checking HTTPS certs in {{\-\-release}} mode.
> People tell about self-signed certs, but your cert looks legit, after all, it
> works on all desktop client. But at least you know where to look.
> Luckily for you, the staging platform has a publicly accessible domain name.
> You test your cert with SSLLabs and it tells you that your server doesn't
> send all intermediary certs. It's still not sure if this is the issue, but
> you ask the ops team to update the server.
> They get a better cert and update server config to send the intermediary
> cert. You're saved! This was the missing piece to make the app work.
> 2) Suppose you never had the issue 1), you built an app, it works in
> production, all is well. One day, you change the HTTPS cert in production
> (because an old one expired etc.), you do quick tests, all is well (or, even
> worse: when in big corporation, ops guys change the HTTPS cert without
> telling you). You forget about it, and continue developing your app. You're a
> dev and you're constantly in the Chrome DevTools, so naturally you always
> build debuggable builds. You keep adding features for weeks, all works great
> in your debuggable builds. Your QAs do tests and most often stuff works
> great, but so
[jira] [Commented] (CB-12232) [cordova-android] Skipping HTTPS certificate validation should be hidden behind a flag, and not a default in debug builds
[
https://issues.apache.org/jira/browse/CB-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154891#comment-16154891
]
Jan Piotrowski (Sujan) commented on CB-12232:
-
Just so it was mentioned: There would also be the option to add an
`--show-certificate-errors` flag for `--debug`/default builds so at least there
is an option to debug these errors.
But I don't think it makes sense, because 99% of affected users wouldn't know
about it and be in the same situation as before.
> [cordova-android] Skipping HTTPS certificate validation should be hidden
> behind a flag, and not a default in debug builds
> -
>
> Key: CB-12232
> URL: https://issues.apache.org/jira/browse/CB-12232
> Project: Apache Cordova
> Issue Type: Improvement
> Components: cordova-android
>Affects Versions: 6.2.0
>Reporter: jakub-g
>Priority: Critical
> Labels: android
>
> Right now, when you create a debuggable Cordova build (default behavior for
> commands like `cordova run android` etc.), it by default ignores all HTTPS
> certificate errors, as you can see in the code below:
> https://github.com/apache/cordova-android/blob/23fd0982b0faa6b7e169c2946eab07930f1f4d16/framework/src/org/apache/cordova/engine/SystemWebViewClient.java#L232-L239
> HTTPS certs are only validated when you create a release build, explicitly
> passing a flag, e.g.
> {{cordova run android --release}}
> This behavior is IMO harmful, and let me tell you why (see below for two
> real-life stories)
> *TL;DR I believe it would be better to not bind the lax HTTPS behavior to
> {{\-\-debug}} vs {{\-\-release}} build type, but hide it behind a special
> flag (to follow Chrome's naming convention, that would be
> {{\-\-ignore-certificate-errors}}, but we can name it whatever we like). This
> would expose developers to HTTPS errors much earlier in the dev process,
> which IMO is beneficial; it will also make it easier to understand and debug
> the problems, and avoid last-minute surprises.*
> _Question: do we have a portion of code already that makes runtime behavior
> depend on build-time flag? i.e. would it be easy to add a new flag in a
> similar way, without herculean effort?_
> So, the promised real-life stories:
> 1) Consider, that you have an HTTPS website and your HTTPS certificate is
> somehow invalid (but you don't know about that). You develop your stuff _for
> weeks and weeks_ in debug builds and everything is great. You prepare for
> grand APK upload to Play Store, do a {{\-\-release}} build, and... stuff
> doesn't work! You want to debug it, but you can't - because {{\-\-release}}
> build is non-debuggable! This looks super mysterious and you're totally
> baffled.
> Doing black-box debugging on --release build ain't easy, but you give it a
> try.
> You're thinking about all possible things that could go wrong (code
> minification? some issue with signing keys? Cordova/Chrome/Android are
> broken?), finally after a while you reach to google and you figure out the
> issue is due to cordova only checking HTTPS certs in {{\-\-release}} mode.
> People tell about self-signed certs, but your cert looks legit, after all, it
> works on all desktop client. But at least you know where to look.
> Luckily for you, the staging platform has a publicly accessible domain name.
> You test your cert with SSLLabs and it tells you that your server doesn't
> send all intermediary certs. It's still not sure if this is the issue, but
> you ask the ops team to update the server.
> They get a better cert and update server config to send the intermediary
> cert. You're saved! This was the missing piece to make the app work.
> 2) Suppose you never had the issue 1), you built an app, it works in
> production, all is well. One day, you change the HTTPS cert in production
> (because an old one expired etc.), you do quick tests, all is well (or, even
> worse: when in big corporation, ops guys change the HTTPS cert without
> telling you). You forget about it, and continue developing your app. You're a
> dev and you're constantly in the Chrome DevTools, so naturally you always
> build debuggable builds. You keep adding features for weeks, all works great
> in your debuggable builds. Your QAs do tests and most often stuff works
> great, but sometimes they're getting weird connection issues. First they
> think it's some weird connectivity issue (poor WiFi etc.), but the issues
> happen more often. Turns out the issue happens _only with --release builds_
> and _only on production server_. There's a fire in production, but no one
> noticed for quite a while since the QA test features mostly on staging
> servers, and devs work with staging se
[jira] [Commented] (CB-13238) Splashscreen documentation dangerous
[
https://issues.apache.org/jira/browse/CB-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154905#comment-16154905
]
Volker Braun commented on CB-13238:
---
Yes, as the documentation suggested I created ldpi... xhdpi versions. Now I
know that providing an xxxhdpi version as well would have averted the crash,
but that is quite a trap for the unwary and should be addressed in the docs
(which is why I opened the issue here). Really, just like you want the new
universal splash screen on iOS (which the docs correctly point out) you also
want a single splash image on Android instead of bundling multiple resized
versions in the app.
> Splashscreen documentation dangerous
>
>
> Key: CB-13238
> URL: https://issues.apache.org/jira/browse/CB-13238
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-plugin-splashscreen
> Environment: xxxhdpi devices
>Reporter: Volker Braun
>
> This seems to be a documentation issue, but for the record here is the back
> story first:
> I reused the iOS 2730x2730 universal splash screen for the Android version,
> and copied the config.xml settings
> {code}
> density="port-hdpi"/>
> density="port-ldpi"/>
> density="port-mdpi"/>
> density="port-xhdpi"/>
> {code}
> as they are on
> https://cordova.apache.org/docs/en/latest/reference/cordova-plugin-splashscreen/
> Then my app is crashing with
> {code}
> Fatal Exception: java.lang.RuntimeException: Canvas: trying to draw too
> large(119421184bytes) bitmap.
> {code}
> on startup on xxxhdpi devices (e.g. Samsung S8). Note the 119421184 bytes are
> 2730^2 pixel * 4 bytes color depth times an extra 2^2; The last factor is the
> rescaling from xhdpi -> xxxhdpi.
> I believe the documentation should be saying
> {code}
>
> {code}
> since the splash screen is scaled to fill the screen anyways, we certainly
> don't want to blow it up first because we have a high dpi device.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
