[jira] [Resolved] (CB-10412) [iOS — 3.x.x] AutoHideSplashScreen "false" isn't taken in account

[Sergey Shakhnazarov (JIRA)]

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

Sergey Shakhnazarov resolved CB-10412.
--
Resolution: Fixed

Fixed in 3.1.1-dev

> [iOS — 3.x.x] AutoHideSplashScreen "false" isn't taken in account
> -
>
> Key: CB-10412
> URL: https://issues.apache.org/jira/browse/CB-10412
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin SplashScreen
>Affects Versions: 3.0.0, 3.1.0
>Reporter: jdat82
>  Labels: ios, no-repro, triaged, wfc
>
> if your set AutoHideSplashScreen to false in order to hide it yourself later 
> via #hide() method, the splashscreen on iOS never disappear.
> 
> AutoHideSplashScreen works fine if set to true. 
> Tried with $cordovaSplashscreen from ngCordova and navigator.splashscreen  
> directly. 



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

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

[jira] [Updated] (CB-10463) Windows Appxmanifest caching should use the same mechanism as ConfigChanged uses

[Vladimir Kotikov (JIRA)]

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

Vladimir Kotikov updated CB-10463:
--
Description: 
CB-10394 revealed a problem with Appxmanifest class and its file caching. The 
problem is that at some moment the same file might be cached twice by different 
facilities and hence changes, made in one of these places might be ignored.

There is a temporary solution - [cordova-windows PR 
#143|https://github.com/apache/cordova-windows/pull/143], which fixes the 
regression, but we need for more general solution.

A more general way to resolve this is to reuse the same caching mechanism for 
Appxmanifests as used by {{ConfigChanges}} module. This should resolve the 
stale cache issue automatically because the one cache will be used for all.

This also will require to make some changes in {{cordova-common}}

  was:
CB-10394 revealed a problem with Appxmanifest class and its' file caching. The 
problem is that at some moment the same file might be cached twice by different 
facilities and hence changes, made in one of these places might be ignored.

There is a temporary solution - [cordova-windows PR 
#143|https://github.com/apache/cordova-windows/pull/143], which fixes the 
regression, but we need for more general solution.

A more general way to resolve this is to reuse the same caching mechanism for 
Appxmanifests as used by {{ConfigChanges}} module. This should resolve the 
stale cache issue automatically because the one cache will be used for all.

This also will require to make some changes in {{cordova-common}}


> Windows Appxmanifest caching should use the same mechanism as ConfigChanged 
> uses
> 
>
> Key: CB-10463
> URL: https://issues.apache.org/jira/browse/CB-10463
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Windows
>Affects Versions: 4.3.0
>Reporter: Vladimir Kotikov
> Fix For: 4.4.0
>
>
> CB-10394 revealed a problem with Appxmanifest class and its file caching. The 
> problem is that at some moment the same file might be cached twice by 
> different facilities and hence changes, made in one of these places might be 
> ignored.
> There is a temporary solution - [cordova-windows PR 
> #143|https://github.com/apache/cordova-windows/pull/143], which fixes the 
> regression, but we need for more general solution.
> A more general way to resolve this is to reuse the same caching mechanism for 
> Appxmanifests as used by {{ConfigChanges}} module. This should resolve the 
> stale cache issue automatically because the one cache will be used for all.
> This also will require to make some changes in {{cordova-common}}



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

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

[jira] [Commented] (CB-10407) InAppBrowser not firing loadstart event on android

[jcesarmobile (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121027#comment-15121027
 ] 

jcesarmobile commented on CB-10407:
---

It grabs the latest tag.
It will be released when everything is ready, can't tell you a date. There were 
other issues on other platforms and are being fixed too. And we are adding 
tests so this doesn't happen again.
If you are interested in releases you can subscribe to de developer mailing 
list.

Or you can install from github
cordova plugin add https://github.com/apache/cordova-plugin-inappbrowser

> InAppBrowser not firing loadstart event on android
> --
>
> Key: CB-10407
> URL: https://issues.apache.org/jira/browse/CB-10407
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin InAppBrowser
>Affects Versions: 5.4.0
> Environment: Android API 21
>Reporter: andyz
>  Labels: Android, Triaged
>
> loadstart event is not firing. there are no issues with loadstop and exit.
> Simple snippet:
> var ref = cordova.InAppBrowser.open('http://www.google.com', '_blank');
> ref.addEventListener('loadstart', function (event) { alert('started'); });
> ref.addEventListener('loadstop', function (event) { alert('stopped'); });
> only the 'stopped' alert is fired.



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

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

[jira] [Closed] (CB-10303) Windows platform ignores some build options

[Vladimir Kotikov (JIRA)]

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

Vladimir Kotikov closed CB-10303.
-

> Windows platform ignores some build options
> ---
>
> Key: CB-10303
> URL: https://issues.apache.org/jira/browse/CB-10303
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Windows
>Affects Versions: 4.3.0
>Reporter: Vladimir Kotikov
>Assignee: Vladimir Kotikov
>Priority: Critical
> Fix For: 4.3.0
>
>
> When we run packaging, we put values in the build.json file like this:
> {code:title=build.json}
> {
>   "windows": {
> "release": {
>   "packageCertificateKeyFile": "res\\native\\windows\\CordovaApp.pfx",
>   "publisherId": "CN=995C8641-FD13-454D-B93F-C1E4381956B9"
> }
>   }
> }
> {code}
> After the packaging, the appxmanifest file has this in it: {{ Publisher="CN=$username$" Version="1.1.0.0" />}}
> The {{$username$}} should have been replaced by 
> CN=995C8641-FD13-454D-B93F-C1E4381956B9.
> Another problem, related to arguments parsing is that build.js ignores 
> {{options.archs}} and take it if I set {{options.argv='--archs=x64'}}



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

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

[jira] [Commented] (CB-10456) InAppBrowser is not closed if I close it programmatically on Android

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1512#comment-1512
 ] 

ASF GitHub Bot commented on CB-10456:
-

GitHub user sgrebnov opened a pull request:

https://github.com/apache/cordova-plugin-inappbrowser/pull/143

CB-10456 InAppBrowser is not closed if I close it programmatically on 
Android

https://issues.apache.org/jira/browse/CB-10456

This happens due to race condition: open/initialization logic is queued 
into ui thread, but dialog close method test for null is not, so if I do open 
and then close then close method test is executed before open method is 
completed.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-plugin-inappbrowser 
CB-10456

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-inappbrowser/pull/143.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 #143


commit 4a2878aa5ef91f250823360f50ba9c963b52f601
Author: sgrebnov 
Date:   2016-01-28T09:35:53Z

CB-10456 InAppBrowser is not closed if I close it programmatically on 
Android




> InAppBrowser is not closed if I close it programmatically on Android
> 
>
> Key: CB-10456
> URL: https://issues.apache.org/jira/browse/CB-10456
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin InAppBrowser
>Reporter: Sergey Grebnov
>Assignee: Sergey Grebnov
>  Labels: Andriod, triaged
>
> I use the following unit test. I see that close method is called but browser 
> still on top and does not respond to close and back button.
> PS. If I do location.reload() or execute the same code from Chrome remote 
> inspector then everything works as expected.
> {code}
> it("inappbrowser.spec.3 should retun InAppBrowser instance with 
> required methods", function () {
> iabInstance = cordova.InAppBrowser.open(url, '_blank');
> expect(iabInstance).toBeDefined();
> 
> expect(iabInstance.addEventListener).toEqual(jasmine.any(Function));
> 
> expect(iabInstance.removeEventListener).toEqual(jasmine.any(Function));
> expect(iabInstance.close).toEqual(jasmine.any(Function));
> expect(iabInstance.show).toEqual(jasmine.any(Function));
> expect(iabInstance.executeScript).toEqual(jasmine.any(Function));
> expect(iabInstance.insertCSS).toEqual(jasmine.any(Function));
> iabInstance.close();
> iabInstance = null;
> });
> {code}
> May be related to CB-6702



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

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

[jira] [Commented] (CB-10443) Android release build with --keystore option fails with undescriptive error message

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121056#comment-15121056
 ] 

ASF subversion and git services commented on CB-10443:
--

Commit 7669378c6eca5ed4eef9e339caacc3c7efdcc43f in cordova-android's branch 
refs/heads/master from Dimitar Kerezov
[ https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=7669378 ]

CB-10443 Pass original options instead of remaining

Nopt parses all options regardless of what is passed as "knownOpts". This 
leaves the remain property an emtpy array.
This ultimately leads to a bug in the parseOpts function where the options 
undergo a second parsing from nopt.
The end result is - this options are not respected at all..
This closes #248


> Android release build with --keystore option fails with undescriptive error 
> message
> ---
>
> Key: CB-10443
> URL: https://issues.apache.org/jira/browse/CB-10443
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 5.2.0
>Reporter: Vladimir Kotikov
>Assignee: Vladimir Kotikov
>  Labels: android, reproduced, triaged
> Fix For: 5.3.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The issue and repro steps are described in 
> https://github.com/apache/cordova-android/pull/248



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

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

[jira] [Commented] (CB-10394) config-file changes are not written to package.windows.appxmanifest

[Marco Biasini (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121068#comment-15121068
 ] 

Marco Biasini commented on CB-10394:


Thanks for fixing this so quickly! Is there a release schedule for 4.4? My 
google-foo failed me.

> config-file changes are not written to package.windows.appxmanifest
> ---
>
> Key: CB-10394
> URL: https://issues.apache.org/jira/browse/CB-10394
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Windows
>Affects Versions: 4.3.0
>Reporter: Marco Biasini
>Assignee: Vladimir Kotikov
>  Labels: regression, triaged
>
> I've noticed that config-file changes defined in a plugin are not correctly 
> written to package.windows.appxmanifest file. After a plugin import, the file 
> does not contain these changes. The changes are correctly applied to the 
> other appxmanifest files (phone, windows10, windows80). 
> I've bested both with windows platform 4.3.0 as well as master and the 
> problem exists in both branches.
> The problem is related to the appxmanifest caching mechanism. The 
> package.windows.appxmanifest file is loaded early on to determine the package 
> name (through jsprojManager.getPackageName()). The appxmanifest content is 
> then cached in memory. Then, the config-file changes defined in the 
> plugin.xml file are applied to the manifests and written to disk. They do not 
> use the cached manifests from the earlier step,but rather load the files 
> through a different code path. After that all previously cached appxmanifest 
> instances are then written to disk, which effectively overwrites the content 
> of package.windows.appxmanifest. Since this is the only manifest that gets 
> loaded early on, this does not affect the other appxmanifest files.



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

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

[jira] [Created] (CB-10463) Windows Appxmanifest caching should use the same mechanism as ConfigChanged uses

[Vladimir Kotikov (JIRA)]

Vladimir Kotikov created CB-10463:
-

 Summary: Windows Appxmanifest caching should use the same 
mechanism as ConfigChanged uses
 Key: CB-10463
 URL: https://issues.apache.org/jira/browse/CB-10463
 Project: Apache Cordova
  Issue Type: Improvement
  Components: Windows
Affects Versions: 4.3.0
Reporter: Vladimir Kotikov
 Fix For: 4.4.0


CB-10394 revealed a problem with Appxmanifest class and its' file caching. The 
problem is that at some moment the same file might be cached twice by different 
facilities and hence changes, made in one of these places might be ignored.

There is a temporary solution - [cordova-windows PR 
#143|https://github.com/apache/cordova-windows/pull/143], which fixes the 
regression, but we need for more general solution.

A more general way to resolve this is to reuse the same caching mechanism for 
Appxmanifests as used by {{ConfigChanges}} module. This should resolve the 
stale cache issue automatically because the one cache will be used for all.

This also will require to make some changes in {{cordova-common}}



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

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

[jira] [Closed] (CB-10394) config-file changes are not written to package.windows.appxmanifest

[Vladimir Kotikov (JIRA)]

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

Vladimir Kotikov closed CB-10394.
-
Resolution: Fixed

> config-file changes are not written to package.windows.appxmanifest
> ---
>
> Key: CB-10394
> URL: https://issues.apache.org/jira/browse/CB-10394
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Windows
>Affects Versions: 4.3.0
>Reporter: Marco Biasini
>Assignee: Vladimir Kotikov
>  Labels: regression, triaged
>
> I've noticed that config-file changes defined in a plugin are not correctly 
> written to package.windows.appxmanifest file. After a plugin import, the file 
> does not contain these changes. The changes are correctly applied to the 
> other appxmanifest files (phone, windows10, windows80). 
> I've bested both with windows platform 4.3.0 as well as master and the 
> problem exists in both branches.
> The problem is related to the appxmanifest caching mechanism. The 
> package.windows.appxmanifest file is loaded early on to determine the package 
> name (through jsprojManager.getPackageName()). The appxmanifest content is 
> then cached in memory. Then, the config-file changes defined in the 
> plugin.xml file are applied to the manifests and written to disk. They do not 
> use the cached manifests from the earlier step,but rather load the files 
> through a different code path. After that all previously cached appxmanifest 
> instances are then written to disk, which effectively overwrites the content 
> of package.windows.appxmanifest. Since this is the only manifest that gets 
> loaded early on, this does not affect the other appxmanifest files.



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

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

[jira] [Commented] (CB-2415) On iOS the ajax error/fail callback is not called after server returns error code 401/unauthorized

[jcesarmobile (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-2415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121017#comment-15121017
 ] 

jcesarmobile commented on CB-2415:
--

Is this still an issue on iOS 8/iOS 9? Does it affects WKWebView?

I don't think we should change the whole webview behaviour to fix an UIWebView 
issue, apple should fix it on the UIWebView, not us.

People with this issue should consider using a plugin for the connections like 
this one https://github.com/wymsee/cordova-HTTP



> On iOS the ajax error/fail callback is not called after server returns error 
> code 401/unauthorized
> --
>
> Key: CB-2415
> URL: https://issues.apache.org/jira/browse/CB-2415
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 2.2.0
> Environment: OSX 10.8.2, Xcode 4.5.1, iOS Simulator 5.0, 5.1, 6.0, 
> cordova 2.2
>Reporter: Zach White
>  Labels: 401, BasicAuth, core
>
> I am seeing the same issue as reported in 
> [CB-2284|https://issues.apache.org/jira/browse/CB-2284] also in iOS. Ajax 
> calls with Authorization header set are not returning but are timing out when 
> the authorization credentials are invalid.



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

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

[jira] [Commented] (CB-10138) plugin's metadata value not updating on Android

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121119#comment-15121119
 ] 

ASF GitHub Bot commented on CB-10138:
-

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-android/pull/254


> plugin's metadata value not updating on Android
> ---
>
> Key: CB-10138
> URL: https://issues.apache.org/jira/browse/CB-10138
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 5.1.0
> Environment: Operating System: OS X 10.11.1, Platform: Android, 
> Installed platforms: android 5.0.0, iOS 3.9.2, cordova-plugin-inappbrowser 
> 1.1.0, Cordova version: 5.4.1, Oauth version: ngCordova v0.1.20-alpha
>Reporter: Maikel
>Assignee: Vladimir Kotikov
>  Labels: android, ionic, triaged
>
> I am using ngcordova and ionic to develop my app.
> I have updated cordova to version 5.4.1 and now the authentication via oath 
> (in a inappbrowser window) in my app is not working anymore because the oauth 
> function is telling me that the inappbrowser plugin is not installed.
> On stack overflow I found also this about it (cordova plugin's metadata value 
> not updating), 
> http://stackoverflow.com/questions/33822123/cordova-plugins-metadata-value-not-updating
> "And by debuging in deep i came to know that var cordovaMetadata = 
> cordova.require("cordova/plugin_list").metadata; this code give empty array 
> and that is reason plugin isn't working."



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

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

[jira] [Commented] (CB-10138) plugin's metadata value not updating on Android

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121118#comment-15121118
 ] 

ASF subversion and git services commented on CB-10138:
--

Commit e08d0671ab7a7fc9dbaffd937f6bb5e7a3640c28 in cordova-android's branch 
refs/heads/master from [~vladimir.kotikov]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=e08d067 ]

CB-10138 Adds missing plugin metadata to plugin_list module. This closes #254


> plugin's metadata value not updating on Android
> ---
>
> Key: CB-10138
> URL: https://issues.apache.org/jira/browse/CB-10138
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 5.1.0
> Environment: Operating System: OS X 10.11.1, Platform: Android, 
> Installed platforms: android 5.0.0, iOS 3.9.2, cordova-plugin-inappbrowser 
> 1.1.0, Cordova version: 5.4.1, Oauth version: ngCordova v0.1.20-alpha
>Reporter: Maikel
>Assignee: Vladimir Kotikov
>  Labels: android, ionic, triaged
>
> I am using ngcordova and ionic to develop my app.
> I have updated cordova to version 5.4.1 and now the authentication via oath 
> (in a inappbrowser window) in my app is not working anymore because the oauth 
> function is telling me that the inappbrowser plugin is not installed.
> On stack overflow I found also this about it (cordova plugin's metadata value 
> not updating), 
> http://stackoverflow.com/questions/33822123/cordova-plugins-metadata-value-not-updating
> "And by debuging in deep i came to know that var cordovaMetadata = 
> cordova.require("cordova/plugin_list").metadata; this code give empty array 
> and that is reason plugin isn't working."



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

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

[jira] [Updated] (CB-10463) Windows Appxmanifest caching should use the same mechanism as ConfigChanged uses

[Vladimir Kotikov (JIRA)]

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

Vladimir Kotikov updated CB-10463:
--
Description: 
CB-10394 revealed a problem with Appxmanifest class and its file caching. The 
problem is that at some moment the same file might be cached twice by different 
facilities and hence changes, made in one of these places might be ignored.

There is a temporary solution - [cordova-windows PR 
#143|https://github.com/apache/cordova-windows/pull/143], which fixes the 
regression, but we need for more general solution.

A more general way to resolve this is to reuse the same caching mechanism for 
Appxmanifests as used by {{ConfigChanges}} module. This should resolve the 
stale cache issue automatically because the one cache will be used for all.

  was:
CB-10394 revealed a problem with Appxmanifest class and its file caching. The 
problem is that at some moment the same file might be cached twice by different 
facilities and hence changes, made in one of these places might be ignored.

There is a temporary solution - [cordova-windows PR 
#143|https://github.com/apache/cordova-windows/pull/143], which fixes the 
regression, but we need for more general solution.

A more general way to resolve this is to reuse the same caching mechanism for 
Appxmanifests as used by {{ConfigChanges}} module. This should resolve the 
stale cache issue automatically because the one cache will be used for all.

This also will require to make some changes in {{cordova-common}}


> Windows Appxmanifest caching should use the same mechanism as ConfigChanged 
> uses
> 
>
> Key: CB-10463
> URL: https://issues.apache.org/jira/browse/CB-10463
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Windows
>Affects Versions: 4.3.0
>Reporter: Vladimir Kotikov
> Fix For: 4.4.0
>
>
> CB-10394 revealed a problem with Appxmanifest class and its file caching. The 
> problem is that at some moment the same file might be cached twice by 
> different facilities and hence changes, made in one of these places might be 
> ignored.
> There is a temporary solution - [cordova-windows PR 
> #143|https://github.com/apache/cordova-windows/pull/143], which fixes the 
> regression, but we need for more general solution.
> A more general way to resolve this is to reuse the same caching mechanism for 
> Appxmanifests as used by {{ConfigChanges}} module. This should resolve the 
> stale cache issue automatically because the one cache will be used for all.



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

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

[jira] [Commented] (CB-10394) config-file changes are not written to package.windows.appxmanifest

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120982#comment-15120982
 ] 

ASF GitHub Bot commented on CB-10394:
-

Github user vladimir-kotikov commented on the pull request:

https://github.com/apache/cordova-windows/pull/143#issuecomment-176045173
  
I've created [CB-10463](https://issues.apache.org/jira/browse/CB-10463) for 
appxmanifest improvements


> config-file changes are not written to package.windows.appxmanifest
> ---
>
> Key: CB-10394
> URL: https://issues.apache.org/jira/browse/CB-10394
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Windows
>Affects Versions: 4.3.0
>Reporter: Marco Biasini
>Assignee: Vladimir Kotikov
>  Labels: regression, triaged
>
> I've noticed that config-file changes defined in a plugin are not correctly 
> written to package.windows.appxmanifest file. After a plugin import, the file 
> does not contain these changes. The changes are correctly applied to the 
> other appxmanifest files (phone, windows10, windows80). 
> I've bested both with windows platform 4.3.0 as well as master and the 
> problem exists in both branches.
> The problem is related to the appxmanifest caching mechanism. The 
> package.windows.appxmanifest file is loaded early on to determine the package 
> name (through jsprojManager.getPackageName()). The appxmanifest content is 
> then cached in memory. Then, the config-file changes defined in the 
> plugin.xml file are applied to the manifests and written to disk. They do not 
> use the cached manifests from the earlier step,but rather load the files 
> through a different code path. After that all previously cached appxmanifest 
> instances are then written to disk, which effectively overwrites the content 
> of package.windows.appxmanifest. Since this is the only manifest that gets 
> loaded early on, this does not affect the other appxmanifest files.



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

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

[jira] [Commented] (CB-10443) Android release build with --keystore option fails with undescriptive error message

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121055#comment-15121055
 ] 

ASF subversion and git services commented on CB-10443:
--

Commit 1494082a2a463d750fdd72355cb8b4b0a80275d9 in cordova-android's branch 
refs/heads/master from Dimitar Kerezov
[ https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;h=1494082 ]

CB-10443 Fix `this.root` null reference

parseOpts function referenced this.root but the this object is not the new Api 
as expected. This leads to an exception upon calling path.relative(this.root, 
...).


> Android release build with --keystore option fails with undescriptive error 
> message
> ---
>
> Key: CB-10443
> URL: https://issues.apache.org/jira/browse/CB-10443
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 5.2.0
>Reporter: Vladimir Kotikov
>Assignee: Vladimir Kotikov
>  Labels: android, reproduced, triaged
> Fix For: 5.3.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The issue and repro steps are described in 
> https://github.com/apache/cordova-android/pull/248



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

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

[jira] [Commented] (CB-10456) InAppBrowser hangs if I close it programmatically on Android

[Sergey Grebnov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121073#comment-15121073
 ] 

Sergey Grebnov commented on CB-10456:
-

This happens because the following check is not in ui thread so triggered 
before showWebPage method is completed which is in ui thread

https://github.com/apache/cordova-plugin-inappbrowser/blob/master/src/android/InAppBrowser.java#L368

> InAppBrowser hangs if I close it programmatically on Android
> 
>
> Key: CB-10456
> URL: https://issues.apache.org/jira/browse/CB-10456
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin InAppBrowser
>Reporter: Sergey Grebnov
>Assignee: Sergey Grebnov
>  Labels: Andriod, triaged
>
> I use the following unit test. I see that close method is called but browser 
> still on top and does not respond to close and back button.
> PS. If I do location.reload() or execute the same code from Chrome remote 
> inspector then everything works as expected.
> {code}
> it("inappbrowser.spec.3 should retun InAppBrowser instance with 
> required methods", function () {
> iabInstance = cordova.InAppBrowser.open(url, '_blank');
> expect(iabInstance).toBeDefined();
> 
> expect(iabInstance.addEventListener).toEqual(jasmine.any(Function));
> 
> expect(iabInstance.removeEventListener).toEqual(jasmine.any(Function));
> expect(iabInstance.close).toEqual(jasmine.any(Function));
> expect(iabInstance.show).toEqual(jasmine.any(Function));
> expect(iabInstance.executeScript).toEqual(jasmine.any(Function));
> expect(iabInstance.insertCSS).toEqual(jasmine.any(Function));
> iabInstance.close();
> iabInstance = null;
> });
> {code}
> May be related to CB-6702



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

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

[jira] [Commented] (CB-10138) plugin's metadata value not updating on Android

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121074#comment-15121074
 ] 

ASF GitHub Bot commented on CB-10138:
-

Github user sgrebnov commented on the pull request:

https://github.com/apache/cordova-android/pull/254#issuecomment-176075769
  
:+1: 


> plugin's metadata value not updating on Android
> ---
>
> Key: CB-10138
> URL: https://issues.apache.org/jira/browse/CB-10138
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 5.1.0
> Environment: Operating System: OS X 10.11.1, Platform: Android, 
> Installed platforms: android 5.0.0, iOS 3.9.2, cordova-plugin-inappbrowser 
> 1.1.0, Cordova version: 5.4.1, Oauth version: ngCordova v0.1.20-alpha
>Reporter: Maikel
>Assignee: Vladimir Kotikov
>  Labels: android, ionic, triaged
>
> I am using ngcordova and ionic to develop my app.
> I have updated cordova to version 5.4.1 and now the authentication via oath 
> (in a inappbrowser window) in my app is not working anymore because the oauth 
> function is telling me that the inappbrowser plugin is not installed.
> On stack overflow I found also this about it (cordova plugin's metadata value 
> not updating), 
> http://stackoverflow.com/questions/33822123/cordova-plugins-metadata-value-not-updating
> "And by debuging in deep i came to know that var cordovaMetadata = 
> cordova.require("cordova/plugin_list").metadata; this code give empty array 
> and that is reason plugin isn't working."



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

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

[jira] [Updated] (CB-10456) InAppBrowser hangs if I close it programmatically on AInAppBrowser is not closed if I close it programmatically on Android

[Sergey Grebnov (JIRA)]

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

Sergey Grebnov updated CB-10456:

Summary: InAppBrowser hangs if I close it programmatically on AInAppBrowser 
is not closed if I close it programmatically on Android  (was: InAppBrowser 
hangs if I close it programmatically on Android)

> InAppBrowser hangs if I close it programmatically on AInAppBrowser is not 
> closed if I close it programmatically on Android
> --
>
> Key: CB-10456
> URL: https://issues.apache.org/jira/browse/CB-10456
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin InAppBrowser
>Reporter: Sergey Grebnov
>Assignee: Sergey Grebnov
>  Labels: Andriod, triaged
>
> I use the following unit test. I see that close method is called but browser 
> still on top and does not respond to close and back button.
> PS. If I do location.reload() or execute the same code from Chrome remote 
> inspector then everything works as expected.
> {code}
> it("inappbrowser.spec.3 should retun InAppBrowser instance with 
> required methods", function () {
> iabInstance = cordova.InAppBrowser.open(url, '_blank');
> expect(iabInstance).toBeDefined();
> 
> expect(iabInstance.addEventListener).toEqual(jasmine.any(Function));
> 
> expect(iabInstance.removeEventListener).toEqual(jasmine.any(Function));
> expect(iabInstance.close).toEqual(jasmine.any(Function));
> expect(iabInstance.show).toEqual(jasmine.any(Function));
> expect(iabInstance.executeScript).toEqual(jasmine.any(Function));
> expect(iabInstance.insertCSS).toEqual(jasmine.any(Function));
> iabInstance.close();
> iabInstance = null;
> });
> {code}
> May be related to CB-6702



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

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

[jira] [Updated] (CB-10456) InAppBrowser is not closed if I close it programmatically on Android

[Sergey Grebnov (JIRA)]

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

Sergey Grebnov updated CB-10456:

Summary: InAppBrowser is not closed if I close it programmatically on 
Android  (was: InAppBrowser hangs if I close it programmatically on 
AInAppBrowser is not closed if I close it programmatically on Android)

> InAppBrowser is not closed if I close it programmatically on Android
> 
>
> Key: CB-10456
> URL: https://issues.apache.org/jira/browse/CB-10456
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin InAppBrowser
>Reporter: Sergey Grebnov
>Assignee: Sergey Grebnov
>  Labels: Andriod, triaged
>
> I use the following unit test. I see that close method is called but browser 
> still on top and does not respond to close and back button.
> PS. If I do location.reload() or execute the same code from Chrome remote 
> inspector then everything works as expected.
> {code}
> it("inappbrowser.spec.3 should retun InAppBrowser instance with 
> required methods", function () {
> iabInstance = cordova.InAppBrowser.open(url, '_blank');
> expect(iabInstance).toBeDefined();
> 
> expect(iabInstance.addEventListener).toEqual(jasmine.any(Function));
> 
> expect(iabInstance.removeEventListener).toEqual(jasmine.any(Function));
> expect(iabInstance.close).toEqual(jasmine.any(Function));
> expect(iabInstance.show).toEqual(jasmine.any(Function));
> expect(iabInstance.executeScript).toEqual(jasmine.any(Function));
> expect(iabInstance.insertCSS).toEqual(jasmine.any(Function));
> iabInstance.close();
> iabInstance = null;
> });
> {code}
> May be related to CB-6702



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

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

[jira] [Closed] (CB-10443) Android release build with --keystore option fails with undescriptive error message

[Vladimir Kotikov (JIRA)]

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

Vladimir Kotikov closed CB-10443.
-
Resolution: Fixed

> Android release build with --keystore option fails with undescriptive error 
> message
> ---
>
> Key: CB-10443
> URL: https://issues.apache.org/jira/browse/CB-10443
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 5.2.0
>Reporter: Vladimir Kotikov
>Assignee: Vladimir Kotikov
>  Labels: android, reproduced, triaged
> Fix For: 5.3.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The issue and repro steps are described in 
> https://github.com/apache/cordova-android/pull/248



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

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

[jira] [Commented] (CB-10440) Add CSS color names support for BackgroundColor on Windows

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121284#comment-15121284
 ] 

ASF subversion and git services commented on CB-10440:
--

Commit 35f48b4ea005b92a8b956f313a66ca3beabc82a9 in cordova-windows's branch 
refs/heads/master from [~daserge]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;h=35f48b4 ]

CB-10440 Add CSS color names support for BackgroundColor on Windows


> Add CSS color names support for BackgroundColor on Windows
> --
>
> Key: CB-10440
> URL: https://issues.apache.org/jira/browse/CB-10440
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Windows
>Reporter: Sergey Shakhnazarov
>Assignee: Sergey Shakhnazarov
>
> 1. Create a new Cordova project
> 2. Open config.xml
> 3. Add  to the file.
> 4. Build for Windows platform
>  Actual:
> APPX3037
> App manifest validation failed. Value '#transparent' of attribute 
> '/Package/Applications/Application/m3:VisualElements/@BackgroundColor' is not 
> a valid color name or color hexadecimal identifier.
>   
> This is because the generated appmanifest has this line :
> 
> where it doesn't expect the value to be a named color value other than a 
> hexadecimal color value.
> Expected:
> The appmanifest file can be generated correctly, with a value like:
> 
> or
> 



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

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

[jira] [Created] (CB-10467) Hardware back button, while InAppBrowser is opened, closes the app too in addition to closing InAppBrowser

[Sam Deepak (JIRA)]

Sam Deepak created CB-10467:
---

 Summary: Hardware back button, while InAppBrowser is opened, 
closes the app too in addition to closing InAppBrowser
 Key: CB-10467
 URL: https://issues.apache.org/jira/browse/CB-10467
 Project: Apache Cordova
  Issue Type: Bug
  Components: Plugin InAppBrowser
Affects Versions: 1.2.0
 Environment: Windows phone 8.1
Reporter: Sam Deepak


The hardware back button when tapped closes the app (puts in background mode) 
in addition to closing the InAppBrowser.

This behavior exists in windows phone only whereas it works fine in Android (it 
closes only the InAppBorwser).

Please help me fix this issue.



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

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

[jira] [Commented] (CB-10440) Add CSS color names support for BackgroundColor on Windows

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121286#comment-15121286
 ] 

ASF GitHub Bot commented on CB-10440:
-

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-windows/pull/142


> Add CSS color names support for BackgroundColor on Windows
> --
>
> Key: CB-10440
> URL: https://issues.apache.org/jira/browse/CB-10440
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Windows
>Reporter: Sergey Shakhnazarov
>Assignee: Sergey Shakhnazarov
>
> 1. Create a new Cordova project
> 2. Open config.xml
> 3. Add  to the file.
> 4. Build for Windows platform
>  Actual:
> APPX3037
> App manifest validation failed. Value '#transparent' of attribute 
> '/Package/Applications/Application/m3:VisualElements/@BackgroundColor' is not 
> a valid color name or color hexadecimal identifier.
>   
> This is because the generated appmanifest has this line :
> 
> where it doesn't expect the value to be a named color value other than a 
> hexadecimal color value.
> Expected:
> The appmanifest file can be generated correctly, with a value like:
> 
> or
> 



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

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

[jira] [Updated] (CB-10465) cordova.raw.emulate fires a cordova.raw.prepare with incorrect arguments

[Manuel Martiarena (JIRA)]

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

Manuel Martiarena updated CB-10465:
---
Affects Version/s: (was: 3.5.0)
   5.4.1

> cordova.raw.emulate fires a cordova.raw.prepare with incorrect arguments
> 
>
> Key: CB-10465
> URL: https://issues.apache.org/jira/browse/CB-10465
> Project: Apache Cordova
>  Issue Type: Bug
>Affects Versions: 5.4.1
>Reporter: Manuel Martiarena
>  Labels: cordova-lib
>
> All cordova.raw command now need to be called with arguments like this ticket 
> expains: https://issues.apache.org/jira/browse/CB-9987.
> Unfortunately the raw emulate command executes the raw prepare with the wrong 
> structure of arguments, with the side effect that if you want to emulate only 
> iOS, the other configured projects will also be add/checked/prepared.
> emulate.js calls it like this: 
> return require('./cordova').raw.prepare(options.platforms);
> https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/emulate.js
>  line 36
> But the argument should be an object with a key named platforms. like so:
> return require('./cordova').raw.prepare({platforms: options.platforms}); 



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

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

[jira] [Commented] (CB-10440) Add CSS color names support for BackgroundColor on Windows

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121423#comment-15121423
 ] 

ASF subversion and git services commented on CB-10440:
--

Commit b292ae8c96cab47d6600a8840d9d695b7ea2b732 in cordova-docs's branch 
refs/heads/master from [~daserge]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;h=b292ae8 ]

CB-10440 Add CSS color names support for BackgroundColor on Windows


> Add CSS color names support for BackgroundColor on Windows
> --
>
> Key: CB-10440
> URL: https://issues.apache.org/jira/browse/CB-10440
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Windows
>Reporter: Sergey Shakhnazarov
>Assignee: Sergey Shakhnazarov
>
> 1. Create a new Cordova project
> 2. Open config.xml
> 3. Add  to the file.
> 4. Build for Windows platform
>  Actual:
> APPX3037
> App manifest validation failed. Value '#transparent' of attribute 
> '/Package/Applications/Application/m3:VisualElements/@BackgroundColor' is not 
> a valid color name or color hexadecimal identifier.
>   
> This is because the generated appmanifest has this line :
> 
> where it doesn't expect the value to be a named color value other than a 
> hexadecimal color value.
> Expected:
> The appmanifest file can be generated correctly, with a value like:
> 
> or
> 



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

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

[jira] [Commented] (CB-10394) config-file changes are not written to package.windows.appxmanifest

[Vladimir Kotikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121132#comment-15121132
 ] 

Vladimir Kotikov commented on CB-10394:
---

We plan to do a patch release (4.3.1), including this fix, on the next week

> config-file changes are not written to package.windows.appxmanifest
> ---
>
> Key: CB-10394
> URL: https://issues.apache.org/jira/browse/CB-10394
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Windows
>Affects Versions: 4.3.0
>Reporter: Marco Biasini
>Assignee: Vladimir Kotikov
>  Labels: regression, triaged
>
> I've noticed that config-file changes defined in a plugin are not correctly 
> written to package.windows.appxmanifest file. After a plugin import, the file 
> does not contain these changes. The changes are correctly applied to the 
> other appxmanifest files (phone, windows10, windows80). 
> I've bested both with windows platform 4.3.0 as well as master and the 
> problem exists in both branches.
> The problem is related to the appxmanifest caching mechanism. The 
> package.windows.appxmanifest file is loaded early on to determine the package 
> name (through jsprojManager.getPackageName()). The appxmanifest content is 
> then cached in memory. Then, the config-file changes defined in the 
> plugin.xml file are applied to the manifests and written to disk. They do not 
> use the cached manifests from the earlier step,but rather load the files 
> through a different code path. After that all previously cached appxmanifest 
> instances are then written to disk, which effectively overwrites the content 
> of package.windows.appxmanifest. Since this is the only manifest that gets 
> loaded early on, this does not affect the other appxmanifest files.



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

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

[jira] [Created] (CB-10466) My payment link not working in cordova inappbrowser in windows phone

[Sam Deepak (JIRA)]

Sam Deepak created CB-10466:
---

 Summary: My payment link not working in cordova inappbrowser in 
windows phone
 Key: CB-10466
 URL: https://issues.apache.org/jira/browse/CB-10466
 Project: Apache Cordova
  Issue Type: Bug
  Components: Plugin InAppBrowser
Affects Versions: 1.2.0
 Environment: Windows phone 8.1
Reporter: Sam Deepak


I am using InAppBrowser to load the payment link and let the user pay for the 
product. Now this link flawlessly works in Android. But in Windows phone, it 
does not work i.e., certain scripts create error due to which the user could 
not proceed with payment link. 

The link works in IE or Edge browser from the same windows phone. It occurs 
only in InAppBrowser.
My Test payment Link: 
https://www.instamojo.com/bytesevolution/how-much-app-for-civil-construction-estimati/.

Please look at the android screen where it shows expanded view of details 
(name, email, phone ) when clicked on "Get it now" button, whereas if you look  
at the windows phone screen, it does not expand the details view at all. 
 
I am using Cordova inappbrowser latest version (1.2.0) to load this payment 
link in both android and windows phone. Please help me why it does not work in 
windows phones.



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

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

[jira] [Commented] (CB-10440) Add CSS color names support for BackgroundColor on Windows

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121425#comment-15121425
 ] 

ASF GitHub Bot commented on CB-10440:
-

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-docs/pull/466


> Add CSS color names support for BackgroundColor on Windows
> --
>
> Key: CB-10440
> URL: https://issues.apache.org/jira/browse/CB-10440
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Windows
>Reporter: Sergey Shakhnazarov
>Assignee: Sergey Shakhnazarov
>
> 1. Create a new Cordova project
> 2. Open config.xml
> 3. Add  to the file.
> 4. Build for Windows platform
>  Actual:
> APPX3037
> App manifest validation failed. Value '#transparent' of attribute 
> '/Package/Applications/Application/m3:VisualElements/@BackgroundColor' is not 
> a valid color name or color hexadecimal identifier.
>   
> This is because the generated appmanifest has this line :
> 
> where it doesn't expect the value to be a named color value other than a 
> hexadecimal color value.
> Expected:
> The appmanifest file can be generated correctly, with a value like:
> 
> or
> 



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

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

[jira] [Created] (CB-10468) Hiding default splash screen in IOS not working

[akash (JIRA)]

akash created CB-10468:
--

 Summary:  Hiding default splash screen  in IOS not working
 Key: CB-10468
 URL: https://issues.apache.org/jira/browse/CB-10468
 Project: Apache Cordova
  Issue Type: Bug
  Components: CordovaJS
Reporter: akash


 Hiding default splash screen  in IOS not working.
please advise



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

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

[jira] [Created] (CB-10464) Incorrect checksum for freed object - object was probably modified after being freed

[Giribabu (JIRA)]

Giribabu created CB-10464:
-

 Summary: Incorrect checksum for freed object - object was probably 
modified after being freed
 Key: CB-10464
 URL: https://issues.apache.org/jira/browse/CB-10464
 Project: Apache Cordova
  Issue Type: Test
  Components: iOS
Reporter: Giribabu


In cordova application, iPad 2,2 running iOS 9.0.1 crashed, crash logs as 
below. But in application there are no explicit calls for UIStatusBar.

Tried same scenario multiple times after crash, it did not crash.

Please help in finding issue.

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:

0   libsystem_kernel.dylib0x36c1dd24 __pthread_kill + 8
1   libsystem_pthread.dylib   0x36cc174a pthread_kill + 62
2   libsystem_c.dylib 0x36bb5f40 abort + 108
3   libsystem_malloc.dylib0x36c4f0bc free_list_checksum_botch + 0
4   libsystem_malloc.dylib0x36c4f0d8 free_list_checksum_botch + 28
5   libsystem_malloc.dylib0x36c46f9a tiny_malloc_from_free_list + 994
6   libsystem_malloc.dylib0x36c45a1e szone_malloc_should_clear + 222
7   libsystem_malloc.dylib0x36c4590a malloc_zone_malloc + 90
8   CoreFoundation0x249981e0 _CFRuntimeCreateInstance + 236
9   CoreGraphics  0x24cc71d8 CGTypeCreateInstance + 20
10  CoreGraphics  0x24cceb6c CGImageCreate + 484
11  CoreGraphics  0x24cce6ae CGBitmapContextCreateImage + 146
12  UIKit 0x2943faaa 
-[UIStatusBarForegroundStyleAttributes 
imageWithText:ofItemType:forWidth:lineBreakMode:letterSpacing:textAlignment:style:withLegibilityStyle:legibilityStrength:]
 + 558
13  UIKit 0x28b98e5c -[UIStatusBarItemView 
imageWithText:] + 240
14  UIKit 0x28b98c2a -[UIStatusBarItemView 
updateContentsAndWidth] + 34
15  UIKit 0x28b42bda -[UIStatusBarItemView 
setStatusBarData:actions:] + 90
16  UIKit 0x28b42b2a -[UIStatusBarLayoutManager 
_updateItemView:withData:actions:animated:] + 138
17  UIKit 0x28b429dc -[UIStatusBarLayoutManager 
updateItemsWithData:actions:animated:] + 176
18  UIKit 0x28b423fa -[UIStatusBarForegroundView 
_setStatusBarData:actions:animated:] + 986
19  UIKit 0x28b41ece -[UIStatusBarForegroundView 
setStatusBarData:actions:animated:] + 842
20  UIKit 0x28b4100a -[UIStatusBar 
statusBarServer:didReceiveStatusBarData:withActions:] + 170
21  UIKit 0x28b40f58 -[UIStatusBarServer 
_receivedStatusBarData:actions:] + 44
22  UIKit 0x28b40f1c 
_UIStatusBarReceivedStatusBarDataAndActions + 56
23  UIKit 0x28b40ea6 _XReceivedStatusBarDataAndActions 
+ 58
24  AppSupport0x2a33aa6e migHelperRecievePortCallout + 146
25  CoreFoundation0x24a4d3f2 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 34
26  CoreFoundation0x24a4cb06 __CFRunLoopDoSource1 + 342
27  CoreFoundation0x24a4af18 __CFRunLoopRun + 1688
28  CoreFoundation0x2499e248 CFRunLoopRunSpecific + 520
29  CoreFoundation0x2499e034 CFRunLoopRunInMode + 108
30  GraphicsServices  0x2da67ad0 GSEventRunModal + 160
31  UIKit 0x28bb38a8 UIApplicationMain + 144

Thanks in advance.



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

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

[jira] [Closed] (CB-10138) plugin's metadata value not updating on Android

[Vladimir Kotikov (JIRA)]

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

Vladimir Kotikov closed CB-10138.
-

> plugin's metadata value not updating on Android
> ---
>
> Key: CB-10138
> URL: https://issues.apache.org/jira/browse/CB-10138
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 5.1.0
> Environment: Operating System: OS X 10.11.1, Platform: Android, 
> Installed platforms: android 5.0.0, iOS 3.9.2, cordova-plugin-inappbrowser 
> 1.1.0, Cordova version: 5.4.1, Oauth version: ngCordova v0.1.20-alpha
>Reporter: Maikel
>Assignee: Vladimir Kotikov
>  Labels: android, ionic, triaged
>
> I am using ngcordova and ionic to develop my app.
> I have updated cordova to version 5.4.1 and now the authentication via oath 
> (in a inappbrowser window) in my app is not working anymore because the oauth 
> function is telling me that the inappbrowser plugin is not installed.
> On stack overflow I found also this about it (cordova plugin's metadata value 
> not updating), 
> http://stackoverflow.com/questions/33822123/cordova-plugins-metadata-value-not-updating
> "And by debuging in deep i came to know that var cordovaMetadata = 
> cordova.require("cordova/plugin_list").metadata; this code give empty array 
> and that is reason plugin isn't working."



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

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

[jira] [Created] (CB-10465) cordova.raw.emulate fires a cordova.raw.prepare with incorrect arguments

[Manuel Martiarena (JIRA)]

Manuel Martiarena created CB-10465:
--

 Summary: cordova.raw.emulate fires a cordova.raw.prepare with 
incorrect arguments
 Key: CB-10465
 URL: https://issues.apache.org/jira/browse/CB-10465
 Project: Apache Cordova
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Manuel Martiarena


All cordova.raw command now need to be called with arguments like this ticket 
expains: https://issues.apache.org/jira/browse/CB-9987.

Unfortunately the raw emulate command executes the raw prepare with the wrong 
structure of arguments, with the side effect that if you want to emulate only 
iOS, the other configured projects will also be add/checked/prepared.

emulate.js calls it like this: return 
require('./cordova').raw.prepare(options.platforms);
https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/emulate.js
 line 36

But the argument should be an object with a key named platforms. like so:
return require('./cordova').raw.prepare({platforms: options.platforms}); 



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

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

[jira] [Commented] (CB-10303) Windows platform ignores some build options

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121256#comment-15121256
 ] 

ASF GitHub Bot commented on CB-10303:
-

GitHub user vladimir-kotikov opened a pull request:

https://github.com/apache/cordova-windows/pull/145

CB-10303 Add tests to cover arguments parsing regression



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-windows CB-10303

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-windows/pull/145.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 #145


commit ecb57e6ee6802a2650e550919692680e0101c8f6
Author: Vladimir Kotikov 
Date:   2016-01-28T10:53:20Z

Refactor tests:

Use jamine spies instead of rewire in most cases
Do not stub console log to simplify debug

commit 03324a000164c2a07dcf00acca19d97867c09124
Author: Vladimir Kotikov 
Date:   2016-01-28T11:36:51Z

CB-10303 Adds tests to cover arguments parsing regression




> Windows platform ignores some build options
> ---
>
> Key: CB-10303
> URL: https://issues.apache.org/jira/browse/CB-10303
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Windows
>Affects Versions: 4.3.0
>Reporter: Vladimir Kotikov
>Assignee: Vladimir Kotikov
>Priority: Critical
> Fix For: 4.3.0
>
>
> When we run packaging, we put values in the build.json file like this:
> {code:title=build.json}
> {
>   "windows": {
> "release": {
>   "packageCertificateKeyFile": "res\\native\\windows\\CordovaApp.pfx",
>   "publisherId": "CN=995C8641-FD13-454D-B93F-C1E4381956B9"
> }
>   }
> }
> {code}
> After the packaging, the appxmanifest file has this in it: {{ Publisher="CN=$username$" Version="1.1.0.0" />}}
> The {{$username$}} should have been replaced by 
> CN=995C8641-FD13-454D-B93F-C1E4381956B9.
> Another problem, related to arguments parsing is that build.js ignores 
> {{options.archs}} and take it if I set {{options.argv='--archs=x64'}}



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

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

[jira] [Commented] (CB-10453) Cordova-Ubuntu Platform Release 4.3.3

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121258#comment-15121258
 ] 

ASF subversion and git services commented on CB-10453:
--

Commit f04e84882cbf03d524353cb43eba7e57df99c39b in cordova-ubuntu's branch 
refs/heads/4.3.x from [~dbarth]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-ubuntu.git;h=f04e848 ]

CB-10453 Updated RELEASENOTES and Version for release 4.3.3

Conflicts:
package.json


> Cordova-Ubuntu Platform Release 4.3.3
> -
>
> Key: CB-10453
> URL: https://issues.apache.org/jira/browse/CB-10453
> Project: Apache Cordova
>  Issue Type: Task
>  Components: Ubuntu
>Reporter: David Barth
>Assignee: Maxim Ermilov
>
> Following steps at 
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md



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

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

[jira] [Updated] (CB-10465) cordova.raw.emulate fires a cordova.raw.prepare with incorrect arguments

[Manuel Martiarena (JIRA)]

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

Manuel Martiarena updated CB-10465:
---
Description: 
All cordova.raw command now need to be called with arguments like this ticket 
expains: https://issues.apache.org/jira/browse/CB-9987.

Unfortunately the raw emulate command executes the raw prepare with the wrong 
structure of arguments, with the side effect that if you want to emulate only 
iOS, the other configured projects will also be add/checked/prepared.

emulate.js calls it like this: 
return require('./cordova').raw.prepare(options.platforms);
https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/emulate.js
 line 36

But the argument should be an object with a key named platforms. like so:
return require('./cordova').raw.prepare({platforms: options.platforms}); 

  was:
All cordova.raw command now need to be called with arguments like this ticket 
expains: https://issues.apache.org/jira/browse/CB-9987.

Unfortunately the raw emulate command executes the raw prepare with the wrong 
structure of arguments, with the side effect that if you want to emulate only 
iOS, the other configured projects will also be add/checked/prepared.

emulate.js calls it like this: return 
require('./cordova').raw.prepare(options.platforms);
https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/emulate.js
 line 36

But the argument should be an object with a key named platforms. like so:
return require('./cordova').raw.prepare({platforms: options.platforms}); 


> cordova.raw.emulate fires a cordova.raw.prepare with incorrect arguments
> 
>
> Key: CB-10465
> URL: https://issues.apache.org/jira/browse/CB-10465
> Project: Apache Cordova
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Manuel Martiarena
>  Labels: cordova-lib
>
> All cordova.raw command now need to be called with arguments like this ticket 
> expains: https://issues.apache.org/jira/browse/CB-9987.
> Unfortunately the raw emulate command executes the raw prepare with the wrong 
> structure of arguments, with the side effect that if you want to emulate only 
> iOS, the other configured projects will also be add/checked/prepared.
> emulate.js calls it like this: 
> return require('./cordova').raw.prepare(options.platforms);
> https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/emulate.js
>  line 36
> But the argument should be an object with a key named platforms. like so:
> return require('./cordova').raw.prepare({platforms: options.platforms}); 



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

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

[jira] [Commented] (CB-10303) Windows platform ignores some build options

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121270#comment-15121270
 ] 

ASF GitHub Bot commented on CB-10303:
-

Github user vladimir-kotikov commented on the pull request:

https://github.com/apache/cordova-windows/pull/145#issuecomment-176142684
  
@nikhilkh, could you please take a look, when possible


> Windows platform ignores some build options
> ---
>
> Key: CB-10303
> URL: https://issues.apache.org/jira/browse/CB-10303
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Windows
>Affects Versions: 4.3.0
>Reporter: Vladimir Kotikov
>Assignee: Vladimir Kotikov
>Priority: Critical
> Fix For: 4.3.0
>
>
> When we run packaging, we put values in the build.json file like this:
> {code:title=build.json}
> {
>   "windows": {
> "release": {
>   "packageCertificateKeyFile": "res\\native\\windows\\CordovaApp.pfx",
>   "publisherId": "CN=995C8641-FD13-454D-B93F-C1E4381956B9"
> }
>   }
> }
> {code}
> After the packaging, the appxmanifest file has this in it: {{ Publisher="CN=$username$" Version="1.1.0.0" />}}
> The {{$username$}} should have been replaced by 
> CN=995C8641-FD13-454D-B93F-C1E4381956B9.
> Another problem, related to arguments parsing is that build.js ignores 
> {{options.archs}} and take it if I set {{options.argv='--archs=x64'}}



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

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

[jira] [Updated] (CB-10467) Hardware back button, while InAppBrowser is opened, closes the app too in addition to closing InAppBrowser

[Sam Deepak (JIRA)]

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

Sam Deepak updated CB-10467:

Description: 
The hardware back button when tapped closes the app (puts in background mode) 
in addition to closing the InAppBrowser.

This behavior exists in windows phone only whereas it works fine in Android (it 
closes only the InAppBrowser).

Please help me fix this issue.

  was:
The hardware back button when tapped closes the app (puts in background mode) 
in addition to closing the InAppBrowser.

This behavior exists in windows phone only whereas it works fine in Android (it 
closes only the InAppBorwser).

Please help me fix this issue.


> Hardware back button, while InAppBrowser is opened, closes the app too in 
> addition to closing InAppBrowser
> --
>
> Key: CB-10467
> URL: https://issues.apache.org/jira/browse/CB-10467
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin InAppBrowser
>Affects Versions: 1.2.0
> Environment: Windows phone 8.1
>Reporter: Sam Deepak
>  Labels: cordova, inappbrowser
>
> The hardware back button when tapped closes the app (puts in background mode) 
> in addition to closing the InAppBrowser.
> This behavior exists in windows phone only whereas it works fine in Android 
> (it closes only the InAppBrowser).
> Please help me fix this issue.



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

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

[jira] [Commented] (CB-10451) InAppBrowser: loadstart event is not triggered on Windows

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122031#comment-15122031
 ] 

ASF GitHub Bot commented on CB-10451:
-

Github user sgrebnov commented on the pull request:


https://github.com/apache/cordova-plugin-inappbrowser/pull/145#issuecomment-176320293
  
setTimeout is required to support the following scenario. On ios, android 
and other platforms functionality creates InAppBrowser on native side, so ln2 
happens before webview is created and events are triggered. As a quick fix on 
Windows I made open method async so that it works (this is what docs recommend 
to use so we should support this). Since I made open async I made async other 
methods so that their functionality is triggered after open.
```
ln1: var ref  = cordova.InAppBrowser.open()
ln2: ref.addEventListener('startload', function() {..})
ln3: ref.close()
```

PS. Thank you for the setImmediate tip - will update the code


> InAppBrowser: loadstart event is not triggered on Windows
> -
>
> Key: CB-10451
> URL: https://issues.apache.org/jira/browse/CB-10451
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin InAppBrowser
>Reporter: Sergey Grebnov
>Assignee: Sergey Grebnov
>  Labels: Windows, triaged
>
> The following unit test fails as 'loadstart' callback is not called on 
> Windows. Main reason is that it is called internally when we do open before 
> we attach event handler. But this is what docs recommend and what other 
> people uses. We should make open method async (Windows proxy or 
> inappbrowser.js) so that handler could be added this way
> {code}
> it("inappbrowser.spec.4 should support loadstart and loadstop events", 
> function (done) {
> var onLoadStart = jasmine.createSpy('loadstart event 
> callback').and.callFake(function (evt) {
> verifyEvent(evt, 'loadstart');
> });
> iabInsance = cordova.InAppBrowser.open(url, '_blank');
> iabInsance.addEventListener('loadstart', onLoadStart);
> iabInsance.addEventListener('loadstop', function (evt) {
> verifyEvent(evt, 'loadstop');
> expect(onLoadStart).toHaveBeenCalled();
> done();
> });
> });
> {code}



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

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

[jira] [Updated] (CB-10270) camera.getPicture() returns an empty string

[Richard B Knoll (JIRA)]

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

Richard B Knoll updated CB-10270:
-
Priority: Critical  (was: Major)

> camera.getPicture() returns an empty string
> ---
>
> Key: CB-10270
> URL: https://issues.apache.org/jira/browse/CB-10270
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin Camera
>Affects Versions: 2.1.0
> Environment: Android 4.4.2 (api 19)
>Reporter: Alexander Sorokin
>Priority: Critical
>  Labels: android, reproduced, triaged
> Attachments: mobilespec-camera.7z
>
>
> Code sample to reproduce:
> {code}
> navigator.camera.getPicture(onSuccess, onFail, { 
> destinationType: Camera.DestinationType.FILE_URI,
> sourceType: Camera.PictureSourceType.PHOTOLIBRARY,
> correctOrientation: true
> });
> {code}
> {{onSuccess}} is called with an empty string as an argument.
> if {{correctOrientation}} is {{false}}, everything works as expected.



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

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

[jira] [Created] (CB-10469) Periodic Bug before resume event is called. On SOME Androids only

[Scott J. Pearson (JIRA)]

Scott J. Pearson created CB-10469:
-

 Summary: Periodic Bug before resume event is called. On SOME 
Androids only
 Key: CB-10469
 URL: https://issues.apache.org/jira/browse/CB-10469
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android, CordovaJS
 Environment: Mac OSX, Android releases.

cordova --version
5.3.3
Reporter: Scott J. Pearson
Priority: Blocker
 Fix For: Master


We do a research app that is the leading of its kind. We have a group in 
Botswana, Africa, who reports that our app crashes when resuming. (Not on load, 
but on resume.) The error messages (below) make it seem that this error is on 
the outside of our code. (We have an onResume function that is always called. I 
haven't found evidence that it reaches this point.)

Interestingly, it only happens on SOME of their Android devices. Also, we have 
not had this bug reported by any of our thousands of other iOS and Android 
users. They bought the Androids in Botswana (above South Africa), so I'm 
guessing that they may have an Android rejected by US inspection. Maybe I'm 
overly cynical.

Anyways, the error messages are below. It seems to be in handing the data 
structure over to the MainActivity. who or data is null. You probably know more 
than I do, though.

D/CordovaInterfaceImpl( 2471): Sending activity result to plugin
D/AndroidRuntime( 2471): Shutting down VM
W/dalvikvm( 2471): threadid=1: thread exiting with uncaught exception (group=0x4
16f1bc0)
E/AndroidRuntime( 2471): FATAL EXCEPTION: main
E/AndroidRuntime( 2471): Process: edu.vanderbilt.redcap, PID: 2471
E/AndroidRuntime( 2471): java.lang.RuntimeException: Unable to resume activity {
edu.vanderbilt.redcap/edu.vanderbilt.redcap.MainActivity}: java.lang.RuntimeExce
ption: Failure delivering result ResultInfo{who=null, request=34, result=-1, dat
a=null} to activity {edu.vanderbilt.redcap/edu.vanderbilt.redcap.MainActivity}:
java.lang.NullPointerException
E/AndroidRuntime( 2471):at android.app.ActivityThread.performResumeActiv
ity(ActivityThread.java:3056)
E/AndroidRuntime( 2471):at android.app.ActivityThread.handleResumeActivi
ty(ActivityThread.java:3085)
E/AndroidRuntime( 2471):at android.app.ActivityThread.handleLaunchActivi
ty(ActivityThread.java:2498)
E/AndroidRuntime( 2471):at android.app.ActivityThread.access$800(Activit
yThread.java:166)
E/AndroidRuntime( 2471):at android.app.ActivityThread$H.handleMessage(Ac
tivityThread.java:1283)
E/AndroidRuntime( 2471):at android.os.Handler.dispatchMessage(Handler.ja
va:102)
E/AndroidRuntime( 2471):at android.os.Looper.loop(Looper.java:136)
E/AndroidRuntime( 2471):at android.app.ActivityThread.main(ActivityThrea
d.java:5584)
E/AndroidRuntime( 2471):at java.lang.reflect.Method.invokeNative(Native
Method)
E/AndroidRuntime( 2471):at java.lang.reflect.Method.invoke(Method.java:5
15)
E/AndroidRuntime( 2471):at com.android.internal.os.ZygoteInit$MethodAndA
rgsCaller.run(ZygoteInit.java:1268)
E/AndroidRuntime( 2471):at com.android.internal.os.ZygoteInit.main(Zygot
eInit.java:1084)
E/AndroidRuntime( 2471):at dalvik.system.NativeStart.main(Native Method)

E/AndroidRuntime( 2471): Caused by: java.lang.RuntimeException: Failure deliveri
ng result ResultInfo{who=null, request=34, result=-1, data=null} to activity {ed
u.vanderbilt.redcap/edu.vanderbilt.redcap.MainActivity}: java.lang.NullPointerEx
ception
E/AndroidRuntime( 2471):at android.app.ActivityThread.deliverResults(Act
ivityThread.java:3641)
E/AndroidRuntime( 2471):at android.app.ActivityThread.performResumeActiv
ity(ActivityThread.java:3043)
E/AndroidRuntime( 2471):... 12 more
E/AndroidRuntime( 2471): Caused by: java.lang.NullPointerException
E/AndroidRuntime( 2471):at org.apache.cordova.camera.CameraLauncher.proc
essResultFromCamera(CameraLauncher.java:411)
E/AndroidRuntime( 2471):at org.apache.cordova.camera.CameraLauncher.onAc
tivityResult(CameraLauncher.java:610)
E/AndroidRuntime( 2471):at org.apache.cordova.CordovaInterfaceImpl.onAct
ivityResult(CordovaInterfaceImpl.java:120)
E/AndroidRuntime( 2471):at org.apache.cordova.CordovaActivity.onActivity
Result(CordovaActivity.java:353)
E/AndroidRuntime( 2471):at android.app.Activity.dispatchActivityResult(A
ctivity.java:5634)
E/AndroidRuntime( 2471):at android.app.ActivityThread.deliverResults(Act
ivityThread.java:3637)
E/AndroidRuntime( 2471):... 13 more
W/ActivityManager(  608):   Force finishing activity edu.vanderbilt.redcap/.Main
Activity




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

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

[jira] [Commented] (CB-6702) InAppBrowser hangs when opening more than one instance

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121536#comment-15121536
 ] 

ASF GitHub Bot commented on CB-6702:


GitHub user sgrebnov opened a pull request:

https://github.com/apache/cordova-plugin-inappbrowser/pull/144

CB-6702 InAppBrowser hangs when opening more than one instance

https://issues.apache.org/jira/browse/CB-6702

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-plugin-inappbrowser CB-6702

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-inappbrowser/pull/144.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 #144


commit 653f3b58617bfaa71f2a312506081361b7599a48
Author: sgrebnov 
Date:   2016-01-28T14:16:32Z

CB-6702 InAppBrowser hangs when opening more than one instance




> InAppBrowser hangs when opening more than one instance
> --
>
> Key: CB-6702
> URL: https://issues.apache.org/jira/browse/CB-6702
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin InAppBrowser
>Affects Versions: 3.4.0
> Environment: Android 4.4.2 - Nexus 7
> Android 4.4.2 - Nexus 10
>Reporter: Pablo Terradillos
>Assignee: Sergey Grebnov
>  Labels: Triaged, android, inappbrowser, reproduced
>
> Run:
> var ref1 = window.open('http://google.com', '_blank', 'location=yes');
> var ref2 = window.open('http://youtube.com', '_blank', 'location=yes');
> If I close the inappbrowser window containing youtube.com I can navigate on 
> the second window containing google.com but I'm not able to close it.
> What is more, it neither react to ref1.close();  



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

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

[jira] [Commented] (CB-6702) InAppBrowser hangs when opening more than one instance

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121557#comment-15121557
 ] 

ASF GitHub Bot commented on CB-6702:


Github user sgrebnov commented on the pull request:


https://github.com/apache/cordova-plugin-inappbrowser/pull/144#issuecomment-176206237
  
This fix is similar to what @mysegfault proposed below. I've just 
added logic to prevent the dialog for being dismissed twice.
https://github.com/apache/cordova-plugin-inappbrowser/pull/71/files


> InAppBrowser hangs when opening more than one instance
> --
>
> Key: CB-6702
> URL: https://issues.apache.org/jira/browse/CB-6702
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin InAppBrowser
>Affects Versions: 3.4.0
> Environment: Android 4.4.2 - Nexus 7
> Android 4.4.2 - Nexus 10
>Reporter: Pablo Terradillos
>Assignee: Sergey Grebnov
>  Labels: Triaged, android, inappbrowser, reproduced
>
> Run:
> var ref1 = window.open('http://google.com', '_blank', 'location=yes');
> var ref2 = window.open('http://youtube.com', '_blank', 'location=yes');
> If I close the inappbrowser window containing youtube.com I can navigate on 
> the second window containing google.com but I'm not able to close it.
> What is more, it neither react to ref1.close();  



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

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

[jira] [Commented] (CB-10468) Hiding default splash screen in IOS not working

[Sergey Shakhnazarov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121561#comment-15121561
 ] 

Sergey Shakhnazarov commented on CB-10468:
--

Does this work?
{code}

{code}

>  Hiding default splash screen  in IOS not working
> -
>
> Key: CB-10468
> URL: https://issues.apache.org/jira/browse/CB-10468
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS
>Reporter: akash
>
>  Hiding default splash screen  in IOS not working.
> please advise



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

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

[jira] [Commented] (CB-10468) Hiding default splash screen in IOS not working

[akash (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121522#comment-15121522
 ] 

akash commented on CB-10468:


Thanks Sergey for your reply.

Acutlally for Ios build, I don't  want to use, default splash screen.

How to do the same.

>  Hiding default splash screen  in IOS not working
> -
>
> Key: CB-10468
> URL: https://issues.apache.org/jira/browse/CB-10468
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS
>Reporter: akash
>
>  Hiding default splash screen  in IOS not working.
> please advise



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

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

[jira] [Commented] (CB-10468) Hiding default splash screen in IOS not working

[akash (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121564#comment-15121564
 ] 

akash commented on CB-10468:


No


>  Hiding default splash screen  in IOS not working
> -
>
> Key: CB-10468
> URL: https://issues.apache.org/jira/browse/CB-10468
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS
>Reporter: akash
>
>  Hiding default splash screen  in IOS not working.
> please advise



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

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

[jira] [Resolved] (CB-10440) Add CSS color names support for BackgroundColor on Windows

[Sergey Shakhnazarov (JIRA)]

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

Sergey Shakhnazarov resolved CB-10440.
--
Resolution: Fixed

Added in 4.4.0-dev

> Add CSS color names support for BackgroundColor on Windows
> --
>
> Key: CB-10440
> URL: https://issues.apache.org/jira/browse/CB-10440
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Windows
>Reporter: Sergey Shakhnazarov
>Assignee: Sergey Shakhnazarov
>
> 1. Create a new Cordova project
> 2. Open config.xml
> 3. Add  to the file.
> 4. Build for Windows platform
>  Actual:
> APPX3037
> App manifest validation failed. Value '#transparent' of attribute 
> '/Package/Applications/Application/m3:VisualElements/@BackgroundColor' is not 
> a valid color name or color hexadecimal identifier.
>   
> This is because the generated appmanifest has this line :
> 
> where it doesn't expect the value to be a named color value other than a 
> hexadecimal color value.
> Expected:
> The appmanifest file can be generated correctly, with a value like:
> 
> or
> 



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

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

[jira] [Commented] (CB-10468) Hiding default splash screen in IOS not working

[Sergey Shakhnazarov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-10468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121445#comment-15121445
 ] 

Sergey Shakhnazarov commented on CB-10468:
--

[~akashipru1953], do you mean app startup image by default splashscreen?
Could you please describe your scenario and what is not working?

>  Hiding default splash screen  in IOS not working
> -
>
> Key: CB-10468
> URL: https://issues.apache.org/jira/browse/CB-10468
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS
>Reporter: akash
>
>  Hiding default splash screen  in IOS not working.
> please advise



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

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

[jira] [Commented] (CB-6702) InAppBrowser hangs when opening more than one instance

[Sergey Grebnov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121548#comment-15121548
 ] 

Sergey Grebnov commented on CB-6702:


Adding full support for several InAppBrowser instances including browser events 
will be hard as CallbackContext is shared and exec calls don't pass unique 
InAppBrowser identifier so that we can determine which instance this command 
for. PR above just fixes hang issue.

> InAppBrowser hangs when opening more than one instance
> --
>
> Key: CB-6702
> URL: https://issues.apache.org/jira/browse/CB-6702
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Plugin InAppBrowser
>Affects Versions: 3.4.0
> Environment: Android 4.4.2 - Nexus 7
> Android 4.4.2 - Nexus 10
>Reporter: Pablo Terradillos
>Assignee: Sergey Grebnov
>  Labels: Triaged, android, inappbrowser, reproduced
>
> Run:
> var ref1 = window.open('http://google.com', '_blank', 'location=yes');
> var ref2 = window.open('http://youtube.com', '_blank', 'location=yes');
> If I close the inappbrowser window containing youtube.com I can navigate on 
> the second window containing google.com but I'm not able to close it.
> What is more, it neither react to ref1.close();  



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

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