[jira] [Closed] (CB-10092) Can't find variable: StatusBar
[ https://issues.apache.org/jira/browse/CB-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Kotikov closed CB-10092. - Resolution: Invalid > Can't find variable: StatusBar > -- > > Key: CB-10092 > URL: https://issues.apache.org/jira/browse/CB-10092 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Statusbar >Affects Versions: 2.0.0 > Environment: iOS >Reporter: Kevin Campion > > cordova-plugin-statusbar 2.0.0 > Cordova 5.4.0 > iPhone 6 (iOS 9.1) > Ionic 1.7.10 > I installed the StatusBar plugin with this command: > # cordova plugin add cordova-plugin-statusbar > When I build and launch my project under the iOS simulator, this mistake > appears: > Can't find variable: StatusBar > I could see the plugin is loaded under Xcode's logs: > [CDVTimer][statusbar] 4.725993ms > This problem comes only if I use StatusBar just after the starting, under a > controller. -- 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-10118) statusbar plugin crashes during startup
[
https://issues.apache.org/jira/browse/CB-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kotikov updated CB-10118:
--
Labels: Browser reproduced triaged (was: )
> statusbar plugin crashes during startup
> ---
>
> Key: CB-10118
> URL: https://issues.apache.org/jira/browse/CB-10118
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin Statusbar
>Affects Versions: 5.4.1
>Reporter: Marc Luria
> Labels: Browser, reproduced, triaged
> Fix For: 5.4.0
>
>
> During startup, the plugin fails on the lines:
> define = function (id, factory) {
> if (modules[id]) {
> throw "module " + id + " already defined";
> }
> modules[id] = {
> id: id,
> factory: factory
> };
> };
> with the error Uncaught module cordova-plugin-statusbar.statusbar already
> defined
> I've only tested this so far in the browser plugin, partly because it's
> difficult to set a breakpoint in ios or android.
--
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-10118) statusbar plugin crashes during startup
[
https://issues.apache.org/jira/browse/CB-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kotikov updated CB-10118:
--
Priority: Trivial (was: Major)
> statusbar plugin crashes during startup
> ---
>
> Key: CB-10118
> URL: https://issues.apache.org/jira/browse/CB-10118
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin Statusbar
>Affects Versions: 5.4.1
>Reporter: Marc Luria
>Priority: Trivial
> Labels: Browser, reproduced, triaged
> Fix For: 5.4.0
>
>
> During startup, the plugin fails on the lines:
> define = function (id, factory) {
> if (modules[id]) {
> throw "module " + id + " already defined";
> }
> modules[id] = {
> id: id,
> factory: factory
> };
> };
> with the error Uncaught module cordova-plugin-statusbar.statusbar already
> defined
> I've only tested this so far in the browser plugin, partly because it's
> difficult to set a breakpoint in ios or android.
--
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-9915) preference StatusBarBackgroundColor defaulting to white instead transparent if not set if StatusBarOverlaysWebView set
[ https://issues.apache.org/jira/browse/CB-9915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Kotikov updated CB-9915: - Labels: triaged (was: ) > preference StatusBarBackgroundColor defaulting to white instead transparent > if not set if StatusBarOverlaysWebView set > -- > > Key: CB-9915 > URL: https://issues.apache.org/jira/browse/CB-9915 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Statusbar > Environment: mac os x 10.10.5 cordova 5.2.0 cordova-plugin-statusbar > 1.0.1 "StatusBar" >Reporter: Leonardo Silveira Nascimento Filho > Labels: triaged > > if i set preference StatusBarOverlaysWebView to false but not set > StatusBarBackgroundColor, it will default to white instead transparent. -- 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-9915) preference StatusBarBackgroundColor defaulting to white instead transparent if not set if StatusBarOverlaysWebView set
[ https://issues.apache.org/jira/browse/CB-9915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Kotikov closed CB-9915. Resolution: Invalid +1 to what [~jcesarmobile] said. This is not a bug, but just some misunderstanding of how Statusbar works. Closing > preference StatusBarBackgroundColor defaulting to white instead transparent > if not set if StatusBarOverlaysWebView set > -- > > Key: CB-9915 > URL: https://issues.apache.org/jira/browse/CB-9915 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Statusbar > Environment: mac os x 10.10.5 cordova 5.2.0 cordova-plugin-statusbar > 1.0.1 "StatusBar" >Reporter: Leonardo Silveira Nascimento Filho > Labels: triaged > > if i set preference StatusBarOverlaysWebView to false but not set > StatusBarBackgroundColor, it will default to white instead transparent. -- 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-6838) Battery Plugin needs to be deprecated or fixed
[ https://issues.apache.org/jira/browse/CB-6838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15071398#comment-15071398 ] Jesse Monroy commented on CB-6838: -- [~bowserj] what do you mean when you write "just lead Plugin Battery"? is this a typo? TIA Jesse > Battery Plugin needs to be deprecated or fixed > -- > > Key: CB-6838 > URL: https://issues.apache.org/jira/browse/CB-6838 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Battery Status >Reporter: Joe Bowser > > While investigating the Battery Plugin, I've discovered quite a few issues > with it that tells me that this will never actually work: > 1. This listens to BATTERY_CHANGED. We can never listen to this Broadcast > because the battery ALWAYS changes and this will drain the battery. Android > explicitly prevents this event from being listened to in the manifest. > 2. We don't set up a BroadcastReceiver for BATTERY_LOW, BATTERY_CHARGED > 3. We have no idea whether the phone is plugged into an AC Adapter or a > Computer, this is important information to have. > I think that it's probably a good idea for this plugin to be completely > re-written. -- 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] [Assigned] (CB-10118) statusbar plugin crashes during startup
[
https://issues.apache.org/jira/browse/CB-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kotikov reassigned CB-10118:
-
Assignee: Vladimir Kotikov
> statusbar plugin crashes during startup
> ---
>
> Key: CB-10118
> URL: https://issues.apache.org/jira/browse/CB-10118
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin Statusbar
>Affects Versions: 5.4.1
>Reporter: Marc Luria
>Assignee: Vladimir Kotikov
>Priority: Trivial
> Labels: Browser, reproduced, triaged
> Fix For: 5.4.0
>
>
> During startup, the plugin fails on the lines:
> define = function (id, factory) {
> if (modules[id]) {
> throw "module " + id + " already defined";
> }
> modules[id] = {
> id: id,
> factory: factory
> };
> };
> with the error Uncaught module cordova-plugin-statusbar.statusbar already
> defined
> I've only tested this so far in the browser plugin, partly because it's
> difficult to set a breakpoint in ios or android.
--
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] [Assigned] (CB-10158) StatusBar issue when recovering from fullscreen video playback in landscape mode
[
https://issues.apache.org/jira/browse/CB-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kotikov reassigned CB-10158:
-
Assignee: (was: Vladimir Kotikov)
> StatusBar issue when recovering from fullscreen video playback in landscape
> mode
>
>
> Key: CB-10158
> URL: https://issues.apache.org/jira/browse/CB-10158
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin Statusbar
>Affects Versions: 5.4.1
> Environment: Cordova version 5.4.1 (Using CLI, not platform tools)
> StatusBar plugin version 2.0.0
> Building app on OS X El Capitan
> Device platform: iOS 9.1
> TESTED IN SIMULATOR ONLY (iPhone 6 / iOS 9.1)
> Not tested for any other device platform
> Using the following configuration in config.xml:
> {code:xml}
>
>
>
>
>
>
>
> {code}
>Reporter: Ashraf Yussouff
> Labels: iOS, reproduced, triaged
> Attachments: Simulator Screen Shot Dec 7, 2015, 10.28.04 AM.png,
> Simulator Screen Shot Dec 7, 2015, 10.28.16 AM.png, Simulator Screen Shot Dec
> 7, 2015, 10.28.24 AM.png, Simulator Screen Shot Dec 7, 2015, 10.28.34 AM.png,
> Simulator Screen Shot Dec 7, 2015, 10.28.39 AM.png
>
>
> App uses Single Page Architecture. All HTML is loaded from a remote server
> into a div tag on the page. A header bar at the top of the page is fixed and
> is outside the div tag used for loading the remote HTML.
> With StatusBarOverlaysWebView=false in config.xml, app starts correctly in
> simulator with the status bar above the page header bar.
> Sequence of steps:
> # Load HTML with a tag for some mp4 video
> # Start playback of video
> # Simulate device rotation using Simulator->Hardware->Rotate Left
> #* Video automatically switches to fullscreen and fills the entire simulator
> screen
> # Simulate rotation back to portrait mode using Simulator->Hardware->Rotate
> Right
> # Click "Done" to exit native player
> # NOW THE STATUS BAR COVERS THE WEBVIEW - WebView is now pushed all the way
> up and behind the status bar.
> Problem has only been noticed when recovering from fullscreen video playback
> involving device rotation.
--
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-9371) Prepare deletes orientation preferences
[ https://issues.apache.org/jira/browse/CB-9371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15071197#comment-15071197 ] ASF GitHub Bot commented on CB-9371: Github user chrskrchr commented on the pull request: https://github.com/apache/cordova-lib/pull/260#issuecomment-167151080 Agreed - this is a useful change. I want to be able to specify different orientation settings for iPhone vs. iPad at the Xcode project level, and this change would allow me to do that without Cordova clobbering my project-level settings. > Prepare deletes orientation preferences > --- > > Key: CB-9371 > URL: https://issues.apache.org/jira/browse/CB-9371 > Project: Apache Cordova > Issue Type: Bug > Components: CordovaLib >Affects Versions: 5.1.1 >Reporter: Connor Pearson > > If a user does not have a orientation preference defined in config.xml then > running prepare will delete all orientation preferences in their info.plist. > I'd expect prepare to overwrite the values if the user chose an orientation > preferences, otherwise it should respect the values that are already there. -- 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-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070745#comment-15070745 ] Davide commented on CB-10254: - Because the device's internet is connected to wifi. The attached solution works flawless. I am going to try to use 1.4.1-dev and take off the ngCordova wrapper to see if it helps. > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- 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-10258) cordova-plugin-screen-orientation seems dead while it's incompatible with cordova-ios@4.0.x
Olivier Allouch created CB-10258: Summary: cordova-plugin-screen-orientation seems dead while it's incompatible with cordova-ios@4.0.x Key: CB-10258 URL: https://issues.apache.org/jira/browse/CB-10258 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 5.4.1 Environment: cordova-ios@4.0.1 (the latest) Reporter: Olivier Allouch cordova-plugin-screen-orientation github seems dead, the issues are piling up and it's now incompatible with the new and great cordova-ios@4.0.x (CDVShared.h is now gone). This plugin should be core as it's widely used. see: https://github.com/gbenvenuti/cordova-plugin-screen-orientation/issues/80 and the other repo issues... The code is quite small and seems simple...for an Objective C coder :( Note that android/crosswalk doesn't need it because of the W3C API. -- 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-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070878#comment-15070878 ] Davide commented on CB-10254: - I did several rebooting of the device and now the device is uploading consistently with version 1.4.1. Sometimes it still hangs, but simply restarting the app solves that. I think the windows phone itself is aborting pending requests but I am not sure.The task array all show status aborts but I don't think that's handled in the plugin > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- 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-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070883#comment-15070883 ] Sergey Shakhnazarov commented on CB-10254: -- Can you modify the app code to create a new FileTransfer object each time the upload starts to ensure id increment and see if it helps? > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-10254) file-transfer for windows platform broken
[
https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070889#comment-15070889
]
Davide edited comment on CB-10254 at 12/24/15 11:09 AM:
Like below?
{quote}
upload: function (server, filePath, options, trustAllHosts) {
var q = $q.defer();
var ft = new FileTransfer();
var uri = (options && options.encodeURI === false) ? server :
encodeURI(server);
if (options && options.timeout !== undefined && options.timeout !==
null) {
$timeout(function () {
ft.abort();
}, options.timeout);
options.timeout = null;
}
ft.onprogress = function (progress) {
q.notify(progress);
};
q.promise.abort = function () {
ft.abort();
};
ft.upload(filePath, uri, q.resolve, q.reject, options, trustAllHosts);
return q.promise;
}
{quote}
was (Author: perfectioncsgo):
Like below?
upload: function (server, filePath, options, trustAllHosts) {
var q = $q.defer();
var ft = new FileTransfer();
var uri = (options && options.encodeURI === false) ? server :
encodeURI(server);
if (options && options.timeout !== undefined && options.timeout !==
null) {
$timeout(function () {
ft.abort();
}, options.timeout);
options.timeout = null;
}
ft.onprogress = function (progress) {
q.notify(progress);
};
q.promise.abort = function () {
ft.abort();
};
ft.upload(filePath, uri, q.resolve, q.reject, options, trustAllHosts);
return q.promise;
}
> file-transfer for windows platform broken
> -
>
> Key: CB-10254
> URL: https://issues.apache.org/jira/browse/CB-10254
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin File Transfer
>Affects Versions: 3.5.0
> Environment: Windows Phone 8.1, Nokia Lumia 520
>Reporter: Davide
>Priority: Blocker
> Attachments: FTTest.zip
>
>
> Only been able to test this on a Nokia Lumia 520. The current implementation
> of BackgroundTransfer uploads will almost always stay on pending
> indefinately, which means that there may never be a callback unless the
> operation is manually canceled.
> Notably, this is also an issue with a multitude of things. When disabling
> apps running in the background and also disabling time and date
> synchronization, this problem may not always occur.
> Perhaps it's a bug in BackgroundTransfer itself?
--
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] [Issue Comment Deleted] (CB-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide updated CB-10254: Comment: was deleted (was: If you decide that this problem is device specific, feel free to close this issue. However, I'd like to know why the transferOperations are getting status 2/cancelled without callbacks.) > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- 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-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070893#comment-15070893 ] Sergey Shakhnazarov commented on CB-10254: -- Yes. So if it was that way already here is another question: Do you upload multiple files at once? Is there a chance of the duplicated filenames if so (this might cause an exception)? Can you try to organize the uploads in a queue and see if this helps? > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- 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-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070907#comment-15070907 ] Sergey Shakhnazarov commented on CB-10254: -- Ok, I close this then - please reopen if you find this happening again (ideally with repro steps). An alternative to BackgroundUploader can be [HttpClient|https://code.msdn.microsoft.com/windowsapps/HttpClient-sample-55700664] - it's much faster although requires some low-level code. > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- 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-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070863#comment-15070863 ] Davide commented on CB-10254: - Upgrading my application to version 1.4.1-dev and removing ngCordova doesn't fix it either. It worked for the first 3 uploads. After that there is no more callback. Not even after a hard reset of the device. // update internal TransferOperation object with newly created promise var uploadOperation = upload.startAsync(); fileTransferOps[uploadId].promise = uploadOperation; I was going through the debug version in this and when I look at the array of fileTransferOps @ line 68. The callback that I am expecting isn't happening. But the previous requests have state 2, which I assume simply they were cancelled (aborted?) by something? > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070878#comment-15070878 ] Davide edited comment on CB-10254 at 12/24/15 11:00 AM: I did several rebooting of the device and now the device is uploading consistently with version 1.4.1. Sometimes it still hangs, but simply restarting the app solves that. I think the windows phone itself is aborting pending requests but I am not sure.The task array all show status canceled but I don't think that's handled in the plugin was (Author: perfectioncsgo): I did several rebooting of the device and now the device is uploading consistently with version 1.4.1. Sometimes it still hangs, but simply restarting the app solves that. I think the windows phone itself is aborting pending requests but I am not sure.The task array all show status aborts but I don't think that's handled in the plugin > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- 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-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070886#comment-15070886 ] Davide commented on CB-10254: - If you decide that this problem is device specific, feel free to close this issue. However, I'd like to know why the transferOperations are getting status 2/cancelled without callbacks. > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-10254) file-transfer for windows platform broken
[
https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070889#comment-15070889
]
Davide edited comment on CB-10254 at 12/24/15 11:10 AM:
Like below?
upload: function (server, filePath, options, trustAllHosts) {
var q = $q.defer();
var ft = new FileTransfer();
var uri = (options && options.encodeURI === false) ? server :
encodeURI(server);
if (options && options.timeout !== undefined && options.timeout !==
null) {
$timeout(function () {
ft.abort();
}, options.timeout);
options.timeout = null;
}
ft.onprogress = function (progress) {
q.notify(progress);
};
q.promise.abort = function () {
ft.abort();
};
ft.upload(filePath, uri, q.resolve, q.reject, options, trustAllHosts);
return q.promise;
}
was (Author: perfectioncsgo):
Like below?
bq.
upload: function (server, filePath, options, trustAllHosts) {
var q = $q.defer();
var ft = new FileTransfer();
var uri = (options && options.encodeURI === false) ? server :
encodeURI(server);
if (options && options.timeout !== undefined && options.timeout !==
null) {
$timeout(function () {
ft.abort();
}, options.timeout);
options.timeout = null;
}
ft.onprogress = function (progress) {
q.notify(progress);
};
q.promise.abort = function () {
ft.abort();
};
ft.upload(filePath, uri, q.resolve, q.reject, options, trustAllHosts);
return q.promise;
}
> file-transfer for windows platform broken
> -
>
> Key: CB-10254
> URL: https://issues.apache.org/jira/browse/CB-10254
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin File Transfer
>Affects Versions: 3.5.0
> Environment: Windows Phone 8.1, Nokia Lumia 520
>Reporter: Davide
>Priority: Blocker
> Attachments: FTTest.zip
>
>
> Only been able to test this on a Nokia Lumia 520. The current implementation
> of BackgroundTransfer uploads will almost always stay on pending
> indefinately, which means that there may never be a callback unless the
> operation is manually canceled.
> Notably, this is also an issue with a multitude of things. When disabling
> apps running in the background and also disabling time and date
> synchronization, this problem may not always occur.
> Perhaps it's a bug in BackgroundTransfer itself?
--
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-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shakhnazarov resolved CB-10254. -- Resolution: Cannot Reproduce > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-10254) file-transfer for windows platform broken
[
https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070863#comment-15070863
]
Davide edited comment on CB-10254 at 12/24/15 10:45 AM:
Upgrading my application to version 1.4.1-dev and removing ngCordova doesn't
fix it either. It worked for the first 3 uploads. After that there is no more
callback. Not even after a hard reset of the device.
{quote}
// update internal TransferOperation object with newly created promise
var uploadOperation = upload.startAsync();
fileTransferOps[uploadId].promise = uploadOperation;
{quote}
I was going through the debug version in this and when I look at the array of
fileTransferOps @ line 68.
The callback that I am expecting isn't happening. But the previous requests
have state 2, which I assume simply they were cancelled (aborted?) by something?
was (Author: perfectioncsgo):
Upgrading my application to version 1.4.1-dev and removing ngCordova doesn't
fix it either. It worked for the first 3 uploads. After that there is no more
callback. Not even after a hard reset of the device.
// update internal TransferOperation object with newly created promise
var uploadOperation = upload.startAsync();
fileTransferOps[uploadId].promise = uploadOperation;
I was going through the debug version in this and when I look at the array of
fileTransferOps @ line 68.
The callback that I am expecting isn't happening. But the previous requests
have state 2, which I assume simply they were cancelled (aborted?) by something?
> file-transfer for windows platform broken
> -
>
> Key: CB-10254
> URL: https://issues.apache.org/jira/browse/CB-10254
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin File Transfer
>Affects Versions: 3.5.0
> Environment: Windows Phone 8.1, Nokia Lumia 520
>Reporter: Davide
>Priority: Blocker
> Attachments: FTTest.zip
>
>
> Only been able to test this on a Nokia Lumia 520. The current implementation
> of BackgroundTransfer uploads will almost always stay on pending
> indefinately, which means that there may never be a callback unless the
> operation is manually canceled.
> Notably, this is also an issue with a multitude of things. When disabling
> apps running in the background and also disabling time and date
> synchronization, this problem may not always occur.
> Perhaps it's a bug in BackgroundTransfer itself?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Comment Edited] (CB-10254) file-transfer for windows platform broken
[
https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070889#comment-15070889
]
Davide edited comment on CB-10254 at 12/24/15 11:10 AM:
Like below?
bq.
upload: function (server, filePath, options, trustAllHosts) {
var q = $q.defer();
var ft = new FileTransfer();
var uri = (options && options.encodeURI === false) ? server :
encodeURI(server);
if (options && options.timeout !== undefined && options.timeout !==
null) {
$timeout(function () {
ft.abort();
}, options.timeout);
options.timeout = null;
}
ft.onprogress = function (progress) {
q.notify(progress);
};
q.promise.abort = function () {
ft.abort();
};
ft.upload(filePath, uri, q.resolve, q.reject, options, trustAllHosts);
return q.promise;
}
was (Author: perfectioncsgo):
Like below?
{quote}
upload: function (server, filePath, options, trustAllHosts) {
var q = $q.defer();
var ft = new FileTransfer();
var uri = (options && options.encodeURI === false) ? server :
encodeURI(server);
if (options && options.timeout !== undefined && options.timeout !==
null) {
$timeout(function () {
ft.abort();
}, options.timeout);
options.timeout = null;
}
ft.onprogress = function (progress) {
q.notify(progress);
};
q.promise.abort = function () {
ft.abort();
};
ft.upload(filePath, uri, q.resolve, q.reject, options, trustAllHosts);
return q.promise;
}
{quote}
> file-transfer for windows platform broken
> -
>
> Key: CB-10254
> URL: https://issues.apache.org/jira/browse/CB-10254
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin File Transfer
>Affects Versions: 3.5.0
> Environment: Windows Phone 8.1, Nokia Lumia 520
>Reporter: Davide
>Priority: Blocker
> Attachments: FTTest.zip
>
>
> Only been able to test this on a Nokia Lumia 520. The current implementation
> of BackgroundTransfer uploads will almost always stay on pending
> indefinately, which means that there may never be a callback unless the
> operation is manually canceled.
> Notably, this is also an issue with a multitude of things. When disabling
> apps running in the background and also disabling time and date
> synchronization, this problem may not always occur.
> Perhaps it's a bug in BackgroundTransfer itself?
--
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-10254) file-transfer for windows platform broken
[
https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070889#comment-15070889
]
Davide commented on CB-10254:
-
Like below?
upload: function (server, filePath, options, trustAllHosts) {
var q = $q.defer();
var ft = new FileTransfer();
var uri = (options && options.encodeURI === false) ? server :
encodeURI(server);
if (options && options.timeout !== undefined && options.timeout !==
null) {
$timeout(function () {
ft.abort();
}, options.timeout);
options.timeout = null;
}
ft.onprogress = function (progress) {
q.notify(progress);
};
q.promise.abort = function () {
ft.abort();
};
ft.upload(filePath, uri, q.resolve, q.reject, options, trustAllHosts);
return q.promise;
}
> file-transfer for windows platform broken
> -
>
> Key: CB-10254
> URL: https://issues.apache.org/jira/browse/CB-10254
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin File Transfer
>Affects Versions: 3.5.0
> Environment: Windows Phone 8.1, Nokia Lumia 520
>Reporter: Davide
>Priority: Blocker
> Attachments: FTTest.zip
>
>
> Only been able to test this on a Nokia Lumia 520. The current implementation
> of BackgroundTransfer uploads will almost always stay on pending
> indefinately, which means that there may never be a callback unless the
> operation is manually canceled.
> Notably, this is also an issue with a multitude of things. When disabling
> apps running in the background and also disabling time and date
> synchronization, this problem may not always occur.
> Perhaps it's a bug in BackgroundTransfer itself?
--
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-10254) file-transfer for windows platform broken
[ https://issues.apache.org/jira/browse/CB-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15070899#comment-15070899 ] Davide commented on CB-10254: - The images taken in the album are prefixed with a unique values. My upload function above is placed in an array of promises. I upload both multiple and single images. However, right now the uploads are working and the problem isn't reproducing anymore. Nothing has changed in the code other than working with 1.4.1-dev and a full device restart. I'm getting progress callbacks and everything. Maybe this was fixed somewhere in 1.4.1 and just required a hard reset? (Potentially related: http://forums.windowscentral.com/windows-phone-8-1-preview-developers/278607-store-apps-pending.html ) > file-transfer for windows platform broken > - > > Key: CB-10254 > URL: https://issues.apache.org/jira/browse/CB-10254 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin File Transfer >Affects Versions: 3.5.0 > Environment: Windows Phone 8.1, Nokia Lumia 520 >Reporter: Davide >Priority: Blocker > Attachments: FTTest.zip > > > Only been able to test this on a Nokia Lumia 520. The current implementation > of BackgroundTransfer uploads will almost always stay on pending > indefinately, which means that there may never be a callback unless the > operation is manually canceled. > Notably, this is also an issue with a multitude of things. When disabling > apps running in the background and also disabling time and date > synchronization, this problem may not always occur. > Perhaps it's a bug in BackgroundTransfer itself? -- 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] [Assigned] (CB-10158) StatusBar issue when recovering from fullscreen video playback in landscape mode
[
https://issues.apache.org/jira/browse/CB-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kotikov reassigned CB-10158:
-
Assignee: Vladimir Kotikov
> StatusBar issue when recovering from fullscreen video playback in landscape
> mode
>
>
> Key: CB-10158
> URL: https://issues.apache.org/jira/browse/CB-10158
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin Statusbar
>Affects Versions: 5.4.1
> Environment: Cordova version 5.4.1 (Using CLI, not platform tools)
> StatusBar plugin version 2.0.0
> Building app on OS X El Capitan
> Device platform: iOS 9.1
> TESTED IN SIMULATOR ONLY (iPhone 6 / iOS 9.1)
> Not tested for any other device platform
> Using the following configuration in config.xml:
> {code:xml}
>
>
>
>
>
>
>
> {code}
>Reporter: Ashraf Yussouff
>Assignee: Vladimir Kotikov
> Labels: iOS, reproduced, triaged
> Attachments: Simulator Screen Shot Dec 7, 2015, 10.28.04 AM.png,
> Simulator Screen Shot Dec 7, 2015, 10.28.16 AM.png, Simulator Screen Shot Dec
> 7, 2015, 10.28.24 AM.png, Simulator Screen Shot Dec 7, 2015, 10.28.34 AM.png,
> Simulator Screen Shot Dec 7, 2015, 10.28.39 AM.png
>
>
> App uses Single Page Architecture. All HTML is loaded from a remote server
> into a div tag on the page. A header bar at the top of the page is fixed and
> is outside the div tag used for loading the remote HTML.
> With StatusBarOverlaysWebView=false in config.xml, app starts correctly in
> simulator with the status bar above the page header bar.
> Sequence of steps:
> # Load HTML with a tag for some mp4 video
> # Start playback of video
> # Simulate device rotation using Simulator->Hardware->Rotate Left
> #* Video automatically switches to fullscreen and fills the entire simulator
> screen
> # Simulate rotation back to portrait mode using Simulator->Hardware->Rotate
> Right
> # Click "Done" to exit native player
> # NOW THE STATUS BAR COVERS THE WEBVIEW - WebView is now pushed all the way
> up and behind the status bar.
> Problem has only been noticed when recovering from fullscreen video playback
> involving device rotation.
--
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-10255) Add options to hide splashscreen navigation and status bars on Android
[
https://issues.apache.org/jira/browse/CB-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15071054#comment-15071054
]
ASF GitHub Bot commented on CB-10255:
-
Github user daserge commented on the pull request:
https://github.com/apache/cordova-plugin-splashscreen/pull/45#issuecomment-167118349
Combining `splashDialog.getWindow().setFlags` and
`splashDialog.getWindow().getDecorView().setSystemUiVisibility` approach works
on 4.0.3 (with and without soft navbar), 4.3 and 5.1.1:
```java
if (isForceFullScreen()) {
splashDialog.getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
WindowManager.LayoutParams.FLAG_FULLSCREEN);
splashDialog.getWindow().getDecorView().setSystemUiVisibility(
View.SYSTEM_UI_FLAG_HIDE_NAVIGATION |
View.SYSTEM_UI_FLAG_FULLSCREEN);
}
```
(the current code works properly only for >=Lollipop)
What do you think on updating to this?
> Add options to hide splashscreen navigation and status bars on Android
> --
>
> Key: CB-10255
> URL: https://issues.apache.org/jira/browse/CB-10255
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Plugin SplashScreen
>Reporter: Sergey Shakhnazarov
> Labels: android
>
--
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-10158) StatusBar issue when recovering from fullscreen video playback in landscape mode
[
https://issues.apache.org/jira/browse/CB-10158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kotikov updated CB-10158:
--
Labels: iOS reproduced triaged (was: )
> StatusBar issue when recovering from fullscreen video playback in landscape
> mode
>
>
> Key: CB-10158
> URL: https://issues.apache.org/jira/browse/CB-10158
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin Statusbar
>Affects Versions: 5.4.1
> Environment: Cordova version 5.4.1 (Using CLI, not platform tools)
> StatusBar plugin version 2.0.0
> Building app on OS X El Capitan
> Device platform: iOS 9.1
> TESTED IN SIMULATOR ONLY (iPhone 6 / iOS 9.1)
> Not tested for any other device platform
> Using the following configuration in config.xml:
> {code:xml}
>
>
>
>
>
>
>
> {code}
>Reporter: Ashraf Yussouff
> Labels: iOS, reproduced, triaged
> Attachments: Simulator Screen Shot Dec 7, 2015, 10.28.04 AM.png,
> Simulator Screen Shot Dec 7, 2015, 10.28.16 AM.png, Simulator Screen Shot Dec
> 7, 2015, 10.28.24 AM.png, Simulator Screen Shot Dec 7, 2015, 10.28.34 AM.png,
> Simulator Screen Shot Dec 7, 2015, 10.28.39 AM.png
>
>
> App uses Single Page Architecture. All HTML is loaded from a remote server
> into a div tag on the page. A header bar at the top of the page is fixed and
> is outside the div tag used for loading the remote HTML.
> With StatusBarOverlaysWebView=false in config.xml, app starts correctly in
> simulator with the status bar above the page header bar.
> Sequence of steps:
> # Load HTML with a tag for some mp4 video
> # Start playback of video
> # Simulate device rotation using Simulator->Hardware->Rotate Left
> #* Video automatically switches to fullscreen and fills the entire simulator
> screen
> # Simulate rotation back to portrait mode using Simulator->Hardware->Rotate
> Right
> # Click "Done" to exit native player
> # NOW THE STATUS BAR COVERS THE WEBVIEW - WebView is now pushed all the way
> up and behind the status bar.
> Problem has only been noticed when recovering from fullscreen video playback
> involving device rotation.
--
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
