[jira] [Commented] (CB-12270) Getting "Error capturing image" when saveToPhotoAlbum is true on some Android devices
[ https://issues.apache.org/jira/browse/CB-12270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637597#comment-16637597 ] Dan Polivy commented on CB-12270: - I've run into a similar issue, and I believe this is a dupe of https://issues.apache.org/jira/browse/CB-12964 which was fixed on June 28, 2017. Have you all tried this with a newer version of the plugin? > Getting "Error capturing image" when saveToPhotoAlbum is true on some Android > devices > - > > Key: CB-12270 > URL: https://issues.apache.org/jira/browse/CB-12270 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-camera >Reporter: Huseyin Candan >Priority: Major > > I get this error on Samsung Galaxy J2 (SM-J200F) with Android v.5.1.1. > When I change saveToPhotoAlbum to false, it works. > According to the user, the issue occurred on device with no change in the > app. It was working and one day error started. Maybe, Android version is > updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-2627) HTML File Input should support accept/source attributes
[ https://issues.apache.org/jira/browse/CB-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590562#comment-16590562 ] Dan Polivy commented on CB-2627: [~NiklasMerz]: is your commit still active anywhere? Link is dead. I'm running into this issue, as well. Being able to launch either the camera or file picker from an HTML5 input in Cordova on Android would be a huge win for me – it works in every other platform but I really don't want to have to special case Android with different logic. I've done a bunch of work in a fork of the Camera plugin to support an intent chooser to allow the user to choose between camera or library, which might be a viable starting point to port into the files linked above. That logic is here: [https://github.com/dpolivy/cordova-plugin-camera/blob/55068396a8554d70c7df193bad5aab075526a1c2/src/android/CameraLauncher.java#L265] If I understand this correctly, the approach here should be to modify [openFileChooser|[https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/engine/SystemWebChromeClient.java#L232]] to provide the appropriate intents in a Chooser based upon the acceptType parameter. If I did this, I'd probably only handle the "image/*" type to start (and maybe the capture attribute, though I don't know if that is propagated). I'm not very familiar with the test framework for this core component – any guidance on how one would build appropriate tests to verify this? > HTML File Input should support accept/source attributes > --- > > Key: CB-2627 > URL: https://issues.apache.org/jira/browse/CB-2627 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-android >Reporter: Michael Migdol >Priority: Minor > > [CB-2086] always opens a generic File Picker, regardless of the values passed > in for the mimetypes in the accept attribute, or the source attribute. The > Android Browser correctly examines these attributes and starts up an activity > with either: a camera intent, a camera/image intent, a camcorder intent, a > sound recorder intent, or a sound recorder/audio intent. > I'm not sure what cross-pollination is allowed between the Android codebase > and Cordova's, but it appears that > packages/apps/Browser/src/com/android/browser/UploadHandler.java from the > Android source tree contains exactly what we need to accomplish the same. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-14234) InAppBrowser iOS calls handleOpenURL in same app for _system URLs
[ https://issues.apache.org/jira/browse/CB-14234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16573442#comment-16573442 ] Dan Polivy commented on CB-14234: - [~jcesarmobile]: I'm looking into this, and was wondering if the logic could be simplified to use the return value from openURL to determine whether to post the notification within the app. openURL returns a BOOL indicating whether the URL was successfully opened ([https://developer.apple.com/documentation/uikit/uiapplication/1622961-openurl?language=objc)] – would a better fix be to check the return value from that, and if it is NO _then_ we post the notification within the app? I am still curious as to the reason why the notification would be posted to the app at all. I don't see a scenario when you explicitly try to open a URL in the system browser where it would be expected to open in the app instead. That code appears to have been in there from the beginning, though, so I don't know the context/history under which it was added, and whether removing it would break any existing use case. cc:[~hermwong] who made the initial commit, in case he has insight to share. I'm happy to submit a PR but would appreciate some input first. > InAppBrowser iOS calls handleOpenURL in same app for _system URLs > - > > Key: CB-14234 > URL: https://issues.apache.org/jira/browse/CB-14234 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-inappbrowser >Affects Versions: 3.0.0 >Reporter: Dan Polivy >Priority: Minor > > The change to fix CB-11178 has caused some undesirable behavior with > InAppBrowser on iOS. Now, whenever you try to open a URL in the system > browser, by calling `cordova.InAppBrowser.open(url, "_system")`, it opens the > system browser AND calls `handleOpenURL` _in your app_ with the same URL. > In my case, my app is a URL handler for a corresponding web domain (app > links). I am trying to open a page on this web domain in the system browser > from within my app. If my app's handleOpenURL is called with a URL also on > the domain, then my handler thinks it is handling an app link and it causes > the app to navigate to another URL, which in this case is not desired or > expected. > Prior to the fix for CB-11178, this worked perfectly. Is there any other way > to address the fix for CB-11178 without inheriting this incorrect and > undesirable behavior? > [~jcesarmobile]: FYI as you committed the fix in question. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-14234) InAppBrowser iOS calls handleOpenURL in same app for _system URLs
[ https://issues.apache.org/jira/browse/CB-14234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16563833#comment-16563833 ] Dan Polivy commented on CB-14234: - [~jcesarmobile]: I can't differentiate the URL in handleOpenURL, because it *could* be a legitimate URL the app can handle, but in *this case* I want it to open in the system browser, not the app. It's weird to me that the syntax of window.open(url, "_system") would even attempt to open in the app – by specifying the target as "_system" that's a pretty explicit statement you want it to open in the system browser. For my purposes, not sending handleOpenURL for http/https should address this, as we do check the incoming URL to validate it before handling it. Other schemes (aside from our custom scheme which launches the app) should be ignored. I'm curious, though, under what scenario is it expected to call handleOpenURL on the app when trying to open a URL (http/https or otherwise) in the system? > InAppBrowser iOS calls handleOpenURL in same app for _system URLs > - > > Key: CB-14234 > URL: https://issues.apache.org/jira/browse/CB-14234 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-inappbrowser >Affects Versions: 3.0.0 >Reporter: Dan Polivy >Priority: Minor > > The change to fix CB-11178 has caused some undesirable behavior with > InAppBrowser on iOS. Now, whenever you try to open a URL in the system > browser, by calling `cordova.InAppBrowser.open(url, "_system")`, it opens the > system browser AND calls `handleOpenURL` _in your app_ with the same URL. > In my case, my app is a URL handler for a corresponding web domain (app > links). I am trying to open a page on this web domain in the system browser > from within my app. If my app's handleOpenURL is called with a URL also on > the domain, then my handler thinks it is handling an app link and it causes > the app to navigate to another URL, which in this case is not desired or > expected. > Prior to the fix for CB-11178, this worked perfectly. Is there any other way > to address the fix for CB-11178 without inheriting this incorrect and > undesirable behavior? > [~jcesarmobile]: FYI as you committed the fix in question. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-14234) InAppBrowser iOS calls handleOpenURL in same app for _system URLs
[ https://issues.apache.org/jira/browse/CB-14234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16562652#comment-16562652 ] Dan Polivy commented on CB-14234: - Linking the issue that is causing this incorrect/undesirable behavior. > InAppBrowser iOS calls handleOpenURL in same app for _system URLs > - > > Key: CB-14234 > URL: https://issues.apache.org/jira/browse/CB-14234 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-inappbrowser >Affects Versions: 3.0.0 >Reporter: Dan Polivy >Priority: Critical > > The change to fix CB-11178 has caused some undesirable behavior with > InAppBrowser on iOS. Now, whenever you try to open a URL in the system > browser, by calling `cordova.InAppBrowser.open(url, "_system")`, it opens the > system browser AND calls `handleOpenURL` _in your app_ with the same URL. > In my case, my app is a URL handler for a corresponding web domain (app > links). I am trying to open a page on this web domain in the system browser > from within my app. If my app's handleOpenURL is called with a URL also on > the domain, then my handler thinks it is handling an app link and it causes > the app to navigate to another URL, which in this case is not desired or > expected. > Prior to the fix for CB-11178, this worked perfectly. Is there any other way > to address the fix for CB-11178 without inheriting this incorrect and > undesirable behavior? > [~jcesarmobile]: FYI as you committed the fix in question. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-14234) InAppBrowser iOS calls handleOpenURL in same app for _system URLs
Dan Polivy created CB-14234: --- Summary: InAppBrowser iOS calls handleOpenURL in same app for _system URLs Key: CB-14234 URL: https://issues.apache.org/jira/browse/CB-14234 Project: Apache Cordova Issue Type: Bug Components: cordova-plugin-inappbrowser Affects Versions: 3.0.0 Reporter: Dan Polivy The change to fix CB-11178 has caused some undesirable behavior with InAppBrowser on iOS. Now, whenever you try to open a URL in the system browser, by calling `cordova.InAppBrowser.open(url, "_system")`, it opens the system browser AND calls `handleOpenURL` _in your app_ with the same URL. In my case, my app is a URL handler for a corresponding web domain (app links). I am trying to open a page on this web domain in the system browser from within my app. If my app's handleOpenURL is called with a URL also on the domain, then my handler thinks it is handling an app link and it causes the app to navigate to another URL, which in this case is not desired or expected. Prior to the fix for CB-11178, this worked perfectly. Is there any other way to address the fix for CB-11178 without inheriting this incorrect and undesirable behavior? [~jcesarmobile]: FYI as you committed the fix in question. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-14076) Setting UIWebViewDelegate via updateWithInfo doesn't work
[
https://issues.apache.org/jira/browse/CB-14076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474830#comment-16474830
]
Dan Polivy commented on CB-14076:
-
[~shazron]: See PR for a fix. I believe we just need to update the variable
passed in as the delegate; this seems to work just fine in my testing.
> Setting UIWebViewDelegate via updateWithInfo doesn't work
> -
>
> Key: CB-14076
> URL: https://issues.apache.org/jira/browse/CB-14076
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-ios
>Affects Versions: cordova-ios 4.5.0
>Reporter: Dan Polivy
>Assignee: Suraj Pindoria
>Priority: Major
>
> I have an existing Cordova app where I have manually modified
> {{MainViewController.m}} to add my own {{UIWebViewDelegate}} implementation
> -- however, I'd like to do this the "right" way and use a plugin (so I can
> truly treat the platform code as a build artifact).
> From [this
> guide|https://github.com/apache/cordova-ios/blob/master/guides/Setting%20Delegates%2C%20Preferences%20and%20Script%20Message%20Handlers%20in%20the%20WebView.md],
> I see that I should be able to set my {{UIWebViewDelegate}} from my plugin
> code; however, this isn't working. My implementation is not getting called.
> In [the
> code|https://github.com/apache/cordova-ios/blob/3507af4ac68ed13cfb4d8ecfd0e91e747a9c6875/CordovaLib/Classes/Private/Plugins/CDVUIWebViewEngine/CDVUIWebViewEngine.m#L179],
> it appears to be always using the {{CDVViewController}} as the delegate, no
> matter what is passed in.
> Is this a bug? Am I just doing it wrong? What's the correct way to do this?
> My scenario here is to trap the {{didFailLoadWithError}} event for some
> special handling (our Cordova app uses remote resources, and I want to allow
> a retry option if they don't load). This is working just fine when I modify
> the application source directly.
> (Also posted on SO:
> https://stackoverflow.com/questions/50162345/how-do-you-implement-uiwebviewdelegate-from-a-cordova-ios-plugin)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-14076) Setting UIWebViewDelegate via updateWithInfo doesn't work
Dan Polivy created CB-14076:
---
Summary: Setting UIWebViewDelegate via updateWithInfo doesn't work
Key: CB-14076
URL: https://issues.apache.org/jira/browse/CB-14076
Project: Apache Cordova
Issue Type: Bug
Components: cordova-ios
Affects Versions: cordova-ios 4.5.0
Reporter: Dan Polivy
Assignee: Suraj Pindoria
I have an existing Cordova app where I have manually modified
{{MainViewController.m}} to add my own {{UIWebViewDelegate}} implementation --
however, I'd like to do this the "right" way and use a plugin (so I can truly
treat the platform code as a build artifact).
From [this
guide|https://github.com/apache/cordova-ios/blob/master/guides/Setting%20Delegates%2C%20Preferences%20and%20Script%20Message%20Handlers%20in%20the%20WebView.md],
I see that I should be able to set my {{UIWebViewDelegate}} from my plugin
code; however, this isn't working. My implementation is not getting called.
In [the
code|https://github.com/apache/cordova-ios/blob/3507af4ac68ed13cfb4d8ecfd0e91e747a9c6875/CordovaLib/Classes/Private/Plugins/CDVUIWebViewEngine/CDVUIWebViewEngine.m#L179],
it appears to be always using the {{CDVViewController}} as the delegate, no
matter what is passed in.
Is this a bug? Am I just doing it wrong? What's the correct way to do this?
My scenario here is to trap the {{didFailLoadWithError}} event for some special
handling (our Cordova app uses remote resources, and I want to allow a retry
option if they don't load). This is working just fine when I modify the
application source directly.
(Also posted on SO:
https://stackoverflow.com/questions/50162345/how-do-you-implement-uiwebviewdelegate-from-a-cordova-ios-plugin)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-10600) 'cordova run android --release' does not use signed and zip-aligned version of APK
[ https://issues.apache.org/jira/browse/CB-10600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15189634#comment-15189634 ] Dan Polivy commented on CB-10600: - [~nikhilkh] Sure, I can take a stab at it. My only concern is that I don't really know this code, so I don't know if this omission is intentional or if it will have other effects down the road. Are there specific tests I should run to verify? It would also be good to have someone with more familiarity of this component chime in. > 'cordova run android --release' does not use signed and zip-aligned version > of APK > -- > > Key: CB-10600 > URL: https://issues.apache.org/jira/browse/CB-10600 > Project: Apache Cordova > Issue Type: Bug > Components: Android > Environment: Tested on Windows 8.1 with Cordova CLI 6.0.0 (and Ionic > CLI 1.7.14) >Reporter: Eric Gopak >Assignee: Joe Bowser >Priority: Minor > Labels: triaged > > Running command `cordova run android --release` builds the app successfully, > both unsigned and signed/zip-aligned versions. However, it then tries to use > the unsigned version of the APK. Here are the last lines of the output: > . > BUILD SUCCESSFUL > Total time: 31.35 secs > Built the following apk(s): > > C:/X/platforms/android/build/outputs/apk/android-armv7-release-unsigned.apk > C:/X/platforms/android/build/outputs/apk/android-armv7-release.apk > Using apk: > C:/X/platforms/android/build/outputs/apk/android-armv7-release-unsigned.apk > ERROR running one or more of the platforms: Failed to install apk to device: > pkg: /data/local/tmp/android-armv7-release-unsigned.apk > Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES] > You may not have the required environment or OS to run this project > It has worked before I updated Cordova with 'npm install -g cordova'. > I specify signing properties in a file 'release-signing.properties', which I > copy to platforms/android/ folder. During the run/build I get prompted for > the password, just as it has always been. > I believe it is just a problem of choosing the wrong APK from the list of > built APKs (Cordova probably chooses the one that comes earlier > lexicographically) -- 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-10600) 'cordova run android --release' does not use signed and zip-aligned version of APK
[
https://issues.apache.org/jira/browse/CB-10600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15189625#comment-15189625
]
Dan Polivy commented on CB-10600:
-
[~bowserj] I can reproduce this consistently now. Using Cordova 6.0.0. It seems
to come down to this line of code:
https://github.com/apache/cordova-android/blob/master/bin/templates/cordova/lib/builders/GenericBuilder.js#L112
Why is the release case different from debug in NOT excluding {{-unsigned}}
from the target apk name? When I locally modify this to exclude {{-unsigned}},
then it picks up the correct apk and runs just fine.
I am discussing this on slack if you want to chat more about it.
> 'cordova run android --release' does not use signed and zip-aligned version
> of APK
> --
>
> Key: CB-10600
> URL: https://issues.apache.org/jira/browse/CB-10600
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
> Environment: Tested on Windows 8.1 with Cordova CLI 6.0.0 (and Ionic
> CLI 1.7.14)
>Reporter: Eric Gopak
>Assignee: Joe Bowser
>Priority: Minor
> Labels: triaged
>
> Running command `cordova run android --release` builds the app successfully,
> both unsigned and signed/zip-aligned versions. However, it then tries to use
> the unsigned version of the APK. Here are the last lines of the output:
> .
> BUILD SUCCESSFUL
> Total time: 31.35 secs
> Built the following apk(s):
>
> C:/X/platforms/android/build/outputs/apk/android-armv7-release-unsigned.apk
> C:/X/platforms/android/build/outputs/apk/android-armv7-release.apk
> Using apk:
> C:/X/platforms/android/build/outputs/apk/android-armv7-release-unsigned.apk
> ERROR running one or more of the platforms: Failed to install apk to device:
> pkg: /data/local/tmp/android-armv7-release-unsigned.apk
> Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES]
> You may not have the required environment or OS to run this project
> It has worked before I updated Cordova with 'npm install -g cordova'.
> I specify signing properties in a file 'release-signing.properties', which I
> copy to platforms/android/ folder. During the run/build I get prompted for
> the password, just as it has always been.
> I believe it is just a problem of choosing the wrong APK from the list of
> built APKs (Cordova probably chooses the one that comes earlier
> lexicographically)
--
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-10795) [InAppBrowser] Circular loop if app had an intent-filter defined for the URL being opened
[
https://issues.apache.org/jira/browse/CB-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15181344#comment-15181344
]
Dan Polivy commented on CB-10795:
-
Would a valid solution here be to always show a chooser that filters out the
current app? The only downside to this is that a 'default' cannot be set.
> [InAppBrowser] Circular loop if app had an intent-filter defined for the URL
> being opened
> -
>
> Key: CB-10795
> URL: https://issues.apache.org/jira/browse/CB-10795
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin InAppBrowser
>Reporter: Dan Polivy
>
> Consider the following scenario:
> 1. App "X" has an intent-filter defined that says it can open URLs for
> "www.example.com". (e.g., using
> https://github.com/EddyVerbruggen/Custom-URL-scheme plugin)
> 2. App "X" wants to launch a specific URL on www.example.com in the system
> browser.
> 3. App "X" uses InAppBrowser plugin and calls {{window.open}} with
> {{_system}} as the target.
> Actual:
> Since the app itself has an intent-filter defined for "www.example.com",
> InAppBrowser will just re-launch the app with the intent. In some cases, if a
> default handler is not chosen, one will get a chooser, however the app will
> still be listed as the default option.
> Expected:
> The app should be able to launch the URL in the system browser to avoid a
> circular redirect.
> There is some discussion of this issue on stackoverflow:
> http://stackoverflow.com/questions/18682833/how-to-exclude-a-specific-application-from-action-view-intent
> http://stackoverflow.com/questions/29529027/open-url-in-browser-even-though-my-app-registered-an-intent-filter-for-it
> I think it might be reasonable for InAppBrowser, in {{openExternal}}, to
> explicitly remove the current app from the list.
--
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-10795) [InAppBrowser] Circular loop if app had an intent-filter defined for the URL being opened
Dan Polivy created CB-10795:
---
Summary: [InAppBrowser] Circular loop if app had an intent-filter
defined for the URL being opened
Key: CB-10795
URL: https://issues.apache.org/jira/browse/CB-10795
Project: Apache Cordova
Issue Type: Bug
Components: Plugin InAppBrowser
Reporter: Dan Polivy
Consider the following scenario:
1. App "X" has an intent-filter defined that says it can open URLs for
"www.example.com". (e.g., using
https://github.com/EddyVerbruggen/Custom-URL-scheme plugin)
2. App "X" wants to launch a specific URL on www.example.com in the system
browser.
3. App "X" uses InAppBrowser plugin and calls {{window.open}} with {{_system}}
as the target.
Actual:
Since the app itself has an intent-filter defined for "www.example.com",
InAppBrowser will just re-launch the app with the intent. In some cases, if a
default handler is not chosen, one will get a chooser, however the app will
still be listed as the default option.
Expected:
The app should be able to launch the URL in the system browser to avoid a
circular redirect.
There is some discussion of this issue on stackoverflow:
http://stackoverflow.com/questions/18682833/how-to-exclude-a-specific-application-from-action-view-intent
http://stackoverflow.com/questions/29529027/open-url-in-browser-even-though-my-app-registered-an-intent-filter-for-it
I think it might be reasonable for InAppBrowser, in {{openExternal}}, to
explicitly remove the current app from the list.
--
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-10704) [iOS] Add support for Universal Links in cordova-ios
[
https://issues.apache.org/jira/browse/CB-10704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15177924#comment-15177924
]
Dan Polivy commented on CB-10704:
-
I looked at that plugin, but it was quite heavyweight for what most people
would need. Plus, it uses a different mechanism than the "standard"
handleOpenUrl() that is used by the existing custom URL scheme. I think it
would be simpler to be unified to use the same code on the JS side.
> [iOS] Add support for Universal Links in cordova-ios
>
>
> Key: CB-10704
> URL: https://issues.apache.org/jira/browse/CB-10704
> Project: Apache Cordova
> Issue Type: New Feature
> Components: iOS
>Reporter: Dan Polivy
>Priority: Minor
> Labels: cordova-ios-4.1.1
>
> iOS 9 introduced support for Universal Links
> (https://developer.apple.com/library/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html)
> -- essentially, the ability to launch an app directly given an http/https
> URL without requiring a custom URL scheme.
> It would be nice to have built-in support for this in the cordova-ios
> template, similar to how the existing {{openURL}} functionality works.
> I created a gist that has an implementation of the necessary delegate to do
> this, and it works using the existing {{CDVHandleOpenURL}} private plugin. In
> addition to the gist, a new entitlement needs to be added to the project (not
> sure if this is currently supported in a standard way), and a server-side
> configuration file must be uploaded to your domain.
> https://gist.github.com/dpolivy/b181d881c0137d98be57
> I've tested this briefly by modifying my project in Xcode, and it seems to
> work well!
--
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-10704) [iOS] Add support for Universal Links in cordova-ios
Dan Polivy created CB-10704:
---
Summary: [iOS] Add support for Universal Links in cordova-ios
Key: CB-10704
URL: https://issues.apache.org/jira/browse/CB-10704
Project: Apache Cordova
Issue Type: New Feature
Components: iOS
Reporter: Dan Polivy
Priority: Minor
iOS 9 introduced support for Universal Links
(https://developer.apple.com/library/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html)
-- essentially, the ability to launch an app directly given an http/https URL
without requiring a custom URL scheme.
It would be nice to have built-in support for this in the cordova-ios template,
similar to how the existing {{openURL}} functionality works.
I created a gist that has an implementation of the necessary delegate to do
this, and it works using the existing {{CDVHandleOpenURL}} private plugin. In
addition to the gist, a new entitlement needs to be added to the project (not
sure if this is currently supported in a standard way), and a server-side
configuration file must be uploaded to your domain.
https://gist.github.com/dpolivy/b181d881c0137d98be57
I've tested this briefly by modifying my project in Xcode, and it seems to work
well!
--
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-9975) No longer able to use "all" as orientation for ios
[ https://issues.apache.org/jira/browse/CB-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166506#comment-15166506 ] Dan Polivy commented on CB-9975: FYI, I opened a new issue for the platform-specific preference not taking precedence: https://issues.apache.org/jira/browse/CB-10694 > No longer able to use "all" as orientation for ios > -- > > Key: CB-9975 > URL: https://issues.apache.org/jira/browse/CB-9975 > Project: Apache Cordova > Issue Type: Bug > Components: CordovaLib >Affects Versions: 5.4.0 >Reporter: Raymond Camden >Assignee: Shazron Abdullah >Priority: Trivial > Fix For: 5.4.1 > > > Yesterday I blogged about iOS and orientation > (http://www.raymondcamden.com/2015/11/09/cordova-ios-and-orientation-wondering-why-it-is-locked). > Today on Twitter someone noticed that when they set orientation now, they > get an error in the CLI. I updated my CLI to the latest, and can confirm it > is now broken. If you set ios orientation to all, you get: > Unsupported global orientation: all > Defaulting to value: default > This is obviously wrong on two accounts - it wasn't a global orientation (it > was ios only) and all should be supported. -- 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-10694) Platform-specific configuration preferences don't override global settings
[
https://issues.apache.org/jira/browse/CB-10694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Polivy updated CB-10694:
Description:
In the following scenario, the platform-specific orientation value is not
taking preference as I would expect:
{{global: default, ios: all --> no plist entries}}
In this scenario, both the global and the platform specific preference setting
get copied to the platform's config.xml, and the 'default' wins out. Is it a
supported scenario to "override" a global preference with a platform specific
setting?
I am testing with cordova@6.0.0.
This is related to https://issues.apache.org/jira/browse/CB-9975 and
https://issues.apache.org/jira/browse/CB-8783
was:
In the following scenario, the platform-specific orientation value is not
taking preference as I would expect:
{{global: default, ios: all --> no plist entries}}
In this scenario, both the global and the platform specific preference setting
get copied to the platform's config.xml, and the 'default' wins out. Is it a
supported scenario to "override" a global preference with a platform specific
setting?
I am testing with cordova@6.0.0.
This is related to #9975 and #8783
> Platform-specific configuration preferences don't override global settings
> --
>
> Key: CB-10694
> URL: https://issues.apache.org/jira/browse/CB-10694
> Project: Apache Cordova
> Issue Type: Bug
> Components: CordovaLib
>Affects Versions: 6.0.0, 5.4.1
>Reporter: Dan Polivy
>Priority: Minor
>
> In the following scenario, the platform-specific orientation value is not
> taking preference as I would expect:
> {{global: default, ios: all --> no plist entries}}
> In this scenario, both the global and the platform specific preference
> setting get copied to the platform's config.xml, and the 'default' wins out.
> Is it a supported scenario to "override" a global preference with a platform
> specific setting?
> I am testing with cordova@6.0.0.
> This is related to https://issues.apache.org/jira/browse/CB-9975 and
> https://issues.apache.org/jira/browse/CB-8783
--
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-10692) [Android] SplashScreen plugin crashes due to race condition on hide
[
https://issues.apache.org/jira/browse/CB-10692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Polivy updated CB-10692:
Description:
On Android, there is a small race condition in the code to hide the splash
screen when a fade out is used. It may only be visible in certain edge cases,
but the net result is that the app will crash.
Specifically, if multiple calls come in to {{removeSplashScreen}} in a row,
it's possible for the first call to null out {{splashImageView}} before the
second call uses it (but after the second call tests for {{splashDialog ==
null}}), because of the animation delay.
Crashing code:
https://github.com/apache/cordova-plugin-splashscreen/blob/master/src/android/SplashScreen.java#L219
My repro for this scenario is due to having a native dialog box that appears if
we have a network connection error when trying to connect to the starting URL
(in my case, it is a remote URL). The dialog box has a 'retry' button which
allows the user to retry the network request. When the user does this, we tell
the webview to load a new URL; the webview then re-initializes the plugin
manager, which in turn sends onPause and onDestroy events to the Splash Screen
plugin. It's this sequence of events, which, in quick succession, can trigger
the crash.
was:
On Android, there is a small race condition in the code to hide the splash
screen when a fade out is used. It may only be visible in certain edge cases,
but the net result is that the app will crash.
Specifically, if multiple calls come in to {{removeSplashScreen}} in a row,
it's possible for the first call to null out {{splashImageView}} before the
second call uses it (but after the second call tests for {{splashDialog ==
null}}), because of the animation delay.
Crashing code:
https://github.com/apache/cordova-plugin-splashscreen/blob/master/src/android/SplashScreen.java#L219
The easiest fix is likely to protect this will a null check prior to using it.
> [Android] SplashScreen plugin crashes due to race condition on hide
> ---
>
> Key: CB-10692
> URL: https://issues.apache.org/jira/browse/CB-10692
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin SplashScreen
>Affects Versions: 3.2.0
>Reporter: Dan Polivy
>
> On Android, there is a small race condition in the code to hide the splash
> screen when a fade out is used. It may only be visible in certain edge cases,
> but the net result is that the app will crash.
> Specifically, if multiple calls come in to {{removeSplashScreen}} in a row,
> it's possible for the first call to null out {{splashImageView}} before the
> second call uses it (but after the second call tests for {{splashDialog ==
> null}}), because of the animation delay.
> Crashing code:
> https://github.com/apache/cordova-plugin-splashscreen/blob/master/src/android/SplashScreen.java#L219
> My repro for this scenario is due to having a native dialog box that appears
> if we have a network connection error when trying to connect to the starting
> URL (in my case, it is a remote URL). The dialog box has a 'retry' button
> which allows the user to retry the network request. When the user does this,
> we tell the webview to load a new URL; the webview then re-initializes the
> plugin manager, which in turn sends onPause and onDestroy events to the
> Splash Screen plugin. It's this sequence of events, which, in quick
> succession, can trigger the crash.
--
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-10692) [Android] SplashScreen plugin crashes due to race condition on hide
Dan Polivy created CB-10692:
---
Summary: [Android] SplashScreen plugin crashes due to race
condition on hide
Key: CB-10692
URL: https://issues.apache.org/jira/browse/CB-10692
Project: Apache Cordova
Issue Type: Bug
Components: Plugin SplashScreen
Affects Versions: 3.2.0
Reporter: Dan Polivy
On Android, there is a small race condition in the code to hide the splash
screen. It may only be visible in certain edge cases, but the net result is
that the app will crash.
Specifically, if multiple calls come in to {{removeSplashScreen}}, it's
possible for the first call to null out {{splashImageView}} before the second
call uses it (but after the second call tests for {{splashDialog == null}}).
https://github.com/apache/cordova-plugin-splashscreen/blob/master/src/android/SplashScreen.java#L219
The easiest fix is likely to protect this will a null check prior to using it.
--
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-7746) [WP8 & 8.1] AutoHideSplashScreen "false" isn't taken in account
[ https://issues.apache.org/jira/browse/CB-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166398#comment-15166398 ] Dan Polivy edited comment on CB-7746 at 2/25/16 12:21 AM: -- What version of the plugin are you using? As far as I can tell, auto hide has been supported in WP for a while, but it may have been broken until this commit: https://github.com/apache/cordova-plugin-splashscreen/commit/ac23964ac6e5f7a77a62ed9923344857109e71fb was (Author: dpolivy): What version of the plugin are you using? As far as I can tell, auto hide has been supported in WP for a while: https://github.com/apache/cordova-plugin-splashscreen/commit/988517df7fffae4aab0527816de6015abac5a9dc > [WP8 & 8.1] AutoHideSplashScreen "false" isn't taken in account > --- > > Key: CB-7746 > URL: https://issues.apache.org/jira/browse/CB-7746 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin SplashScreen >Affects Versions: 3.6.3 > Environment: Cordova 3.6.3 - WindowsPhone8 & 8.1 - VisualStudio 2013 > - Windows 8.1 (64) >Reporter: Nicolas Albert > Labels: cordova, splashscreen, wp8 > > I use the preference: > > With the plugin: > > I want that the splash screen remains until I call > "navigator.splashscreen.hide()". That works fine for Android and IOS, but not > for WindowsPhone8 (or 8.1) => the splashscreen is visible less than 1 second > and doesn't wait the "hide()" call (many seconds later). -- 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-7746) [WP8 & 8.1] AutoHideSplashScreen "false" isn't taken in account
[ https://issues.apache.org/jira/browse/CB-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15166398#comment-15166398 ] Dan Polivy commented on CB-7746: What version of the plugin are you using? As far as I can tell, auto hide has been supported in WP for a while: https://github.com/apache/cordova-plugin-splashscreen/commit/988517df7fffae4aab0527816de6015abac5a9dc > [WP8 & 8.1] AutoHideSplashScreen "false" isn't taken in account > --- > > Key: CB-7746 > URL: https://issues.apache.org/jira/browse/CB-7746 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin SplashScreen >Affects Versions: 3.6.3 > Environment: Cordova 3.6.3 - WindowsPhone8 & 8.1 - VisualStudio 2013 > - Windows 8.1 (64) >Reporter: Nicolas Albert > Labels: cordova, splashscreen, wp8 > > I use the preference: > > With the plugin: > > I want that the splash screen remains until I call > "navigator.splashscreen.hide()". That works fine for Android and IOS, but not > for WindowsPhone8 (or 8.1) => the splashscreen is visible less than 1 second > and doesn't wait the "hide()" call (many seconds later). -- 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-10263) Fix splashscreen plugin filenames for Asset Catalog
[
https://issues.apache.org/jira/browse/CB-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15155324#comment-15155324
]
Dan Polivy commented on CB-10263:
-
Adding my additional github comments to the bug:
When creating a brand new cordova-ios@4.0.1 project, it, too, does not have a
UILaunchImageFile key in the plist. So it seems like this is something that
manually must be added in order for the splashscreen plugin to work correctly
with asset catalogs? I did manually add it to my project and it seems to work.
But I think there's some additional documentation and/or updates to the ios
templates necessary here.
> Fix splashscreen plugin filenames for Asset Catalog
> ---
>
> Key: CB-10263
> URL: https://issues.apache.org/jira/browse/CB-10263
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin SplashScreen
> Environment: ios@4.0.1
>Reporter: Sergey Shakhnazarov
>Assignee: Sergey Shakhnazarov
>Priority: Critical
> Labels: ios
>
> {code}
> cordova create test
> cd test
> cordova platform add ios@4
> cordova plugin add https://github.com/apache/cordova-plugin-splashscreen
> {code}
> {code}
> // add to config.xml:
>
>
>
> height="480"/>
> height="960"/>
> height="1024"/>
> width="1536" height="2048"/>
> height="768"/>
> width="2048" height="1536"/>
> height="1136"/>
> height="1334"/>
> height="2208"/>
> height="1242"/>
>
>
>
>
>
>
>
> {code}
> {code}
> // add to index.js deviceready event:
> setTimeout(navigator.splashscreen.hide, 3000);
> {code}
> {code}
> cordova emulate ios --target=iPhone-6-Plus
> {code}
> Splash screen will be shown briefly and after that the image will disappear
> leaving only the spinner.
> The following message will be logged out:
> *WARNING: The splashscreen image named LaunchImage-736h was not found*
--
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-9975) No longer able to use "all" as orientation for ios
[ https://issues.apache.org/jira/browse/CB-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15154588#comment-15154588 ] Dan Polivy commented on CB-9975: I believe there's still an issue here; in the following scenario, the platform-specific value is not taking preference as I would expect: global: default, ios: all --> no plist entries In this scenario, both the global and the platform specific preference setting get copied to the platform's config.xml, and the 'default' wins out. Is it a supported scenario to "override" a global preference with a platform specific setting? I am testing with cordova@6.0.0. > No longer able to use "all" as orientation for ios > -- > > Key: CB-9975 > URL: https://issues.apache.org/jira/browse/CB-9975 > Project: Apache Cordova > Issue Type: Bug > Components: CordovaLib >Affects Versions: 5.4.0 >Reporter: Raymond Camden >Assignee: Shazron Abdullah >Priority: Trivial > Fix For: 5.4.1 > > > Yesterday I blogged about iOS and orientation > (http://www.raymondcamden.com/2015/11/09/cordova-ios-and-orientation-wondering-why-it-is-locked). > Today on Twitter someone noticed that when they set orientation now, they > get an error in the CLI. I updated my CLI to the latest, and can confirm it > is now broken. If you set ios orientation to all, you get: > Unsupported global orientation: all > Defaulting to value: default > This is obviously wrong on two accounts - it wasn't a global orientation (it > was ios only) and all should be supported. -- 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-7229) --browserify should be saved when creating a new project
[ https://issues.apache.org/jira/browse/CB-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15149482#comment-15149482 ] Dan Polivy commented on CB-7229: [~stevegill] Is there any mechanism in the current releases to "remember" browserify as an option, so it doesn't have to be specified? > --browserify should be saved when creating a new project > > > Key: CB-7229 > URL: https://issues.apache.org/jira/browse/CB-7229 > Project: Apache Cordova > Issue Type: Sub-task > Components: CLI, CordovaLib >Reporter: Steve Gill > Fix For: 3.8.0 > > > "cordova create --browserify test com.example.test browserifyTest" > The browserify flag should be saved somewhere (config file?) to keep note > that the project is a browserify project. That way, adding/removing > platforms/plugins should be able to check to see if the project was created > as a browserify project. This will also stop the need to add --browserify > everytime you add/rm a plugin or platform. -- 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-10498) Resume event not guaranteed to be received with plugin result
[ https://issues.apache.org/jira/browse/CB-10498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15131204#comment-15131204 ] Dan Polivy commented on CB-10498: - Sounds like a good solution. If you have a PR/build, I'm happy to give it a try. > Resume event not guaranteed to be received with plugin result > - > > Key: CB-10498 > URL: https://issues.apache.org/jira/browse/CB-10498 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Reporter: Richard B Knoll >Assignee: Richard B Knoll > Labels: android, triaged > > The save/restore API delivers results in the resume event. The issue is, it > is possible to "miss" the resume event if you don't add an event handler in > time. -- 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-10498) Resume event not guaranteed to be received with plugin result
[ https://issues.apache.org/jira/browse/CB-10498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15131384#comment-15131384 ] Dan Polivy commented on CB-10498: - [~riknoll] Just played with it a bit, seems to work well for me! I'm getting the events after the app re-launches, and I'm also getting resume events when I power on/off the display. It'd be great to get this merged and into a point release soon. > Resume event not guaranteed to be received with plugin result > - > > Key: CB-10498 > URL: https://issues.apache.org/jira/browse/CB-10498 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Reporter: Richard B Knoll >Assignee: Richard B Knoll > Labels: android, triaged > > The save/restore API delivers results in the resume event. The issue is, it > is possible to "miss" the resume event if you don't add an event handler in > time. -- 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-8789) Cordova iOS to support Asset Catalog for App icons and splashscreens
[ https://issues.apache.org/jira/browse/CB-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120299#comment-15120299 ] Dan Polivy commented on CB-8789: When updating to cordova-ios@4.0.1, is it supposed to automatically convert existing icons and splash screens to using an asset catalog (if using the config.xml icon/splash tags)? I didn't see that happen for my project when updating from 3.8.0. > Cordova iOS to support Asset Catalog for App icons and splashscreens > > > Key: CB-8789 > URL: https://issues.apache.org/jira/browse/CB-8789 > Project: Apache Cordova > Issue Type: Improvement > Components: iOS >Reporter: Carlos Santana >Assignee: Shazron Abdullah > Labels: cordova-ios-4.0.x > > IBM has a future requirement to support Asset Catalog for App icons and > splash screens in our downstream distribution (MobileFirst) of Cordova. > Enterprise use cases: > Leverage Catalog Assets to manage splash screens and app icons, instead of > using deprecated methods. > Tasks: > - Modify Xcode project structure for Cordova to use Asset Catalog > - Modify Cordova CLI to manage icons and spashscreens my managing Asset > Catalog content. > IBM has intention on working on this changes in Cordova, but if someone else > wants to work on it before we get to it that also works for us :-) > Related JIRA issues: > [CB-8027 | https://issues.apache.org/jira/browse/CB-8027] -- 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-8917) Add api/way to get plugins results even when Cordova activity restarts
[
https://issues.apache.org/jira/browse/CB-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120382#comment-15120382
]
Dan Polivy commented on CB-8917:
Sounds good. Let me know if you need anything else to take it to the list. (I'm
also on there, though mostly as a lurker). I'd love to see this addressed soon
:)
I was thinking about it a little more and I think it is ok for {{resume}} to be
sticky. I wonder if {{pause}} should also be sticky, then, to have the same
semantics? Seems like that would at least eliminate any potential issues making
it sticky might have, because at least it would be behaviorally consistent.
> Add api/way to get plugins results even when Cordova activity restarts
>
>
> Key: CB-8917
> URL: https://issues.apache.org/jira/browse/CB-8917
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Android
>Reporter: Bnaya
>Assignee: Richard B Knoll
>
> In android when you have a plugin that opens new activity the CordovaActivity
> will be killed and you won't get the result from the plugin.
> The new activity will get the results but because the plugin objects are dead
> and the webview reloaded you can get the data to the js callback.
> The most noticeable example is the camera plugin. (And maybe its the same
> with even more platforms)
> possible solution for this is to add metadata to the device ready event with
> incoming data from plugins.
--
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-8917) Add api/way to get plugins results even when Cordova activity restarts
[ https://issues.apache.org/jira/browse/CB-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120265#comment-15120265 ] Dan Polivy commented on CB-8917: [~riknoll] Yes, I think that's exactly what's happening. I'm playing around with changing the `onResume` channel to a "sticky" channel in cordova.js, and that does seem to fix it -- my handler does get called when it is attached. I'm not sure if that is a safe change, though. But it certainly does seem to fix it. > Add api/way to get plugins results even when Cordova activity restarts > > > Key: CB-8917 > URL: https://issues.apache.org/jira/browse/CB-8917 > Project: Apache Cordova > Issue Type: Improvement > Components: Android >Reporter: Bnaya >Assignee: Richard B Knoll > > In android when you have a plugin that opens new activity the CordovaActivity > will be killed and you won't get the result from the plugin. > The new activity will get the results but because the plugin objects are dead > and the webview reloaded you can get the data to the js callback. > The most noticeable example is the camera plugin. (And maybe its the same > with even more platforms) > possible solution for this is to add metadata to the device ready event with > incoming data from plugins. -- 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-8917) Add api/way to get plugins results even when Cordova activity restarts
[ https://issues.apache.org/jira/browse/CB-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120192#comment-15120192 ] Dan Polivy commented on CB-8917: [~riknoll] If the resume event is fired before the cordova.js has fully loaded, and the client has subscribed to the resume event, what happens? I'm playing with this now using android@5.1.0 and the updated Camera plugin, and on resume I can see the resume event be fired from the native side, but I don't appear to be receiving it in the JS. Note, we are loading our start page via a remote URL, so there's a little more latency on startup than a typical app. Should the resume event be 'sticky' in this scenario, so that it is fired when the client subscribes (if it has been fired by the native code)? > Add api/way to get plugins results even when Cordova activity restarts > > > Key: CB-8917 > URL: https://issues.apache.org/jira/browse/CB-8917 > Project: Apache Cordova > Issue Type: Improvement > Components: Android >Reporter: Bnaya >Assignee: Richard B Knoll > > In android when you have a plugin that opens new activity the CordovaActivity > will be killed and you won't get the result from the plugin. > The new activity will get the results but because the plugin objects are dead > and the webview reloaded you can get the data to the js callback. > The most noticeable example is the camera plugin. (And maybe its the same > with even more platforms) > possible solution for this is to add metadata to the device ready event with > incoming data from plugins. -- 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-8917) Add api/way to get plugins results even when Cordova activity restarts
[
https://issues.apache.org/jira/browse/CB-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15120253#comment-15120253
]
Dan Polivy commented on CB-8917:
[~riknoll] I believe it is getting into the JS side of things, but the issue is
that my `resume` handler isn't registered at the time that the event is fired
from cordova.js. Using console.log, I can see that `onMessageFromNative()` is
called and the event is fired, but that happens before I've called
`document.addEventListener('resume', onResume, false)`.
I subscribe to `resume` from within my `ondeviceready` handler. I find that if
I do it before `ondeviceready` is signalled, then the resume handler doesn't
get called at all (verified just by powering the screen off/on). Is that
expected?
> Add api/way to get plugins results even when Cordova activity restarts
>
>
> Key: CB-8917
> URL: https://issues.apache.org/jira/browse/CB-8917
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Android
>Reporter: Bnaya
>Assignee: Richard B Knoll
>
> In android when you have a plugin that opens new activity the CordovaActivity
> will be killed and you won't get the result from the plugin.
> The new activity will get the results but because the plugin objects are dead
> and the webview reloaded you can get the data to the js callback.
> The most noticeable example is the camera plugin. (And maybe its the same
> with even more platforms)
> possible solution for this is to add metadata to the device ready event with
> incoming data from plugins.
--
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-9060) [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent
[ https://issues.apache.org/jira/browse/CB-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15099152#comment-15099152 ] Dan Polivy commented on CB-9060: Joe, this issue is still present (I just updated to 4.1.1). Can you take another look? I'm happy to help you out here. I believe this is a pretty easy fix, and it would be nice to have it addressed in the core framework. > [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent > - > > Key: CB-9060 > URL: https://issues.apache.org/jira/browse/CB-9060 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 4.0.0 >Reporter: Dan Polivy >Assignee: Joe Bowser >Priority: Minor > > With cordova-android@4.0.0 and the new whitelist functionality, it seems that > calls to CordovaWebView.showWebPage (via CordovaWebViewImpl implementation) > are getting launched both in the app WebView AND via Intent in the system > browser. > This happens when, for example, the Cordova app is hosted remotely, so the > actual URL is a http://www.somedomain.com/url, and the developer has included > the following in config.xml: > > http://*/*; /> > https://*/*; /> > Then, if in the app, there is a call to showWebPage with a URL at > http://www.somedomain.com, it will launch in both places. > Should there be a return statement at Line 216 to prevent any attempt to load > the URL externally, if we actually load it internally? > https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebViewImpl.java#L216 -- 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-9060) [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent
[ https://issues.apache.org/jira/browse/CB-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14621035#comment-14621035 ] Dan Polivy commented on CB-9060: Can you try against cordova-android@4.0.2? I don't know what's changed in master or if that will have any impact on it. If you run it with a debugger attached, you should see the error handler called when WebView can't lookup the invalid URL. If that's not getting called, then perhaps you need to adjust the whitelist, or use another URL which you know won't resolve, or use a good URL, but test with network connectivity turned off. I could probably send you a zip of my project directory if that helps. On the unsupported comment, if you have any suggestions on how to better handle the scenario of starting a remote app without network connectivity that doesn't result in a white screen, I'd love to discuss (we can take that discussion elsewhere)! [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent - Key: CB-9060 URL: https://issues.apache.org/jira/browse/CB-9060 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 4.0.0 Reporter: Dan Polivy Assignee: Joe Bowser Priority: Minor With cordova-android@4.0.0 and the new whitelist functionality, it seems that calls to CordovaWebView.showWebPage (via CordovaWebViewImpl implementation) are getting launched both in the app WebView AND via Intent in the system browser. This happens when, for example, the Cordova app is hosted remotely, so the actual URL is a http://www.somedomain.com/url, and the developer has included the following in config.xml: !-- Allow links to web pages to open in a browser -- allow-intent href=http://*/*; / allow-intent href=https://*/*; / Then, if in the app, there is a call to showWebPage with a URL at http://www.somedomain.com, it will launch in both places. Should there be a return statement at Line 216 to prevent any attempt to load the URL externally, if we actually load it internally? https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebViewImpl.java#L216 -- 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-9060) [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent
[ https://issues.apache.org/jira/browse/CB-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14619342#comment-14619342 ] Dan Polivy commented on CB-9060: [~bowserj] have you been able to repro this with the gist I provided? [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent - Key: CB-9060 URL: https://issues.apache.org/jira/browse/CB-9060 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 4.0.0 Reporter: Dan Polivy Assignee: Joe Bowser Priority: Minor With cordova-android@4.0.0 and the new whitelist functionality, it seems that calls to CordovaWebView.showWebPage (via CordovaWebViewImpl implementation) are getting launched both in the app WebView AND via Intent in the system browser. This happens when, for example, the Cordova app is hosted remotely, so the actual URL is a http://www.somedomain.com/url, and the developer has included the following in config.xml: !-- Allow links to web pages to open in a browser -- allow-intent href=http://*/*; / allow-intent href=https://*/*; / Then, if in the app, there is a call to showWebPage with a URL at http://www.somedomain.com, it will launch in both places. Should there be a return statement at Line 216 to prevent any attempt to load the URL externally, if we actually load it internally? https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebViewImpl.java#L216 -- 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-7667) [Camera] iOS8: Handle case where camera is not authorized
[ https://issues.apache.org/jira/browse/CB-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Polivy closed CB-7667. -- Closing as this PR has been incorporated. [Camera] iOS8: Handle case where camera is not authorized - Key: CB-7667 URL: https://issues.apache.org/jira/browse/CB-7667 Project: Apache Cordova Issue Type: Sub-task Components: Plugin Camera, Plugin Media Capture Affects Versions: 3.5.0 Environment: iOS 8 Reporter: Dan Polivy Assignee: Shazron Abdullah Priority: Minor In iOS 8, it's possible for the camera to be disabled for any given app; in iOS 7, this was only possible in certain regions (e.g. China). If the camera is disabled, and someone launches the Camera plugin to capture an image from the camera, they'll just get the camera UI with a black screen, and no indication that the camera permission is disabled for the app. A better UX would be to show the user a prompt indicating that the camera permission is disabled, and (on iOS 8) providing a button to take them to the Settings app to change it. As of iOS 7, there's a new API to test whether the app has access to capture the desired media type: https://developer.apple.com/library/ios/documentation/AVFoundation/Reference/AVCaptureDevice_Class/index.html#//apple_ref/occ/clm/AVCaptureDevice/authorizationStatusForMediaType: [AVCaptureDevice authorizationStatusForMediaType:mediaType]; -- 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-9060) [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent
[ https://issues.apache.org/jira/browse/CB-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14602221#comment-14602221 ] Dan Polivy commented on CB-9060: Thanks for investigating, Joe. Here's a more complete repro: https://gist.github.com/dpolivy/3b4f72f3e65d307a20e8 When you start the app, you'll get the dialog saying the app couldn't connect to the server. Hit RETRY. Then, you'll see the launcher intent appear asking which browser you want to load it in. Plus, it will also navigate the webview to the URL. That's the issue I'm referring to. If I'm using the Cordova APIs incorrectly here, let me know -- but this worked just fine pre-4.0.0. [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent - Key: CB-9060 URL: https://issues.apache.org/jira/browse/CB-9060 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 4.0.0 Reporter: Dan Polivy Assignee: Joe Bowser Priority: Minor With cordova-android@4.0.0 and the new whitelist functionality, it seems that calls to CordovaWebView.showWebPage (via CordovaWebViewImpl implementation) are getting launched both in the app WebView AND via Intent in the system browser. This happens when, for example, the Cordova app is hosted remotely, so the actual URL is a http://www.somedomain.com/url, and the developer has included the following in config.xml: !-- Allow links to web pages to open in a browser -- allow-intent href=http://*/*; / allow-intent href=https://*/*; / Then, if in the app, there is a call to showWebPage with a URL at http://www.somedomain.com, it will launch in both places. Should there be a return statement at Line 216 to prevent any attempt to load the URL externally, if we actually load it internally? https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebViewImpl.java#L216 -- 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-9060) [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent
[ https://issues.apache.org/jira/browse/CB-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14602223#comment-14602223 ] Dan Polivy commented on CB-9060: Also, this is with cordova-android@4.0.2, and I believe it will repro with any version of Android. I have 5.1.1 on my Nexus 5 right now for testing, but I believe it also happened on 4.4.4, and should also repro in the emulator. [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent - Key: CB-9060 URL: https://issues.apache.org/jira/browse/CB-9060 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 4.0.0 Reporter: Dan Polivy Assignee: Joe Bowser Priority: Minor With cordova-android@4.0.0 and the new whitelist functionality, it seems that calls to CordovaWebView.showWebPage (via CordovaWebViewImpl implementation) are getting launched both in the app WebView AND via Intent in the system browser. This happens when, for example, the Cordova app is hosted remotely, so the actual URL is a http://www.somedomain.com/url, and the developer has included the following in config.xml: !-- Allow links to web pages to open in a browser -- allow-intent href=http://*/*; / allow-intent href=https://*/*; / Then, if in the app, there is a call to showWebPage with a URL at http://www.somedomain.com, it will launch in both places. Should there be a return statement at Line 216 to prevent any attempt to load the URL externally, if we actually load it internally? https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebViewImpl.java#L216 -- 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-9193) [Camera] Add option to choose from library even if source is camera
Dan Polivy created CB-9193: -- Summary: [Camera] Add option to choose from library even if source is camera Key: CB-9193 URL: https://issues.apache.org/jira/browse/CB-9193 Project: Apache Cordova Issue Type: Improvement Components: Plugin Camera Reporter: Dan Polivy There are many scenarios where an app might allow a user to take a picture via the camera, OR choose a photo from their library. With the current camera plugin implementation, the developer must first present some type of chooser UI to allow the user to initiate either the camera, or the library. A potentially more efficient approach is to launch the camera by default, and within the camera UI provide an option to switch over to the library -- similar to the way the default Camera app works in iOS. I am working on a PR to add this functionality via a new CameraOptions setting. -- 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-8658) Cordova camera plugin displays a black screen when the user denies access to the camera in iOS
[ https://issues.apache.org/jira/browse/CB-8658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14588980#comment-14588980 ] Dan Polivy commented on CB-8658: I believe this issue is now addressed since this commit was merged into the plugin: https://github.com/apache/cordova-plugin-camera/commit/9f9e5ef4a9c5cf2a829e220ee627e7efc8110cd6 Cordova camera plugin displays a black screen when the user denies access to the camera in iOS -- Key: CB-8658 URL: https://issues.apache.org/jira/browse/CB-8658 Project: Apache Cordova Issue Type: Bug Components: Plugin Camera Affects Versions: 3.7.0 Environment: IOS Reporter: DotNetWise Labels: bug, camera, cordova, plugin Attachments: privacy.png, screen.png I'm making use of the cordova camera plugin in my App (which is supported only for iOS now) and the app uses both the camera and the photo library to select photos. There is an issue with how the plugin responds when ever the user denies access to the device camera. Check out the screen shot below when the user denies access to the camera: https://stackoverflow.com/questions/28427783/cordova-camera-plugin-displays-a-black-screen-when-the-user-denies-access-to-the -- 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-9094) [android] Splashscreen is incorrectly hidden after delay if show is called with no timeout
Dan Polivy created CB-9094: -- Summary: [android] Splashscreen is incorrectly hidden after delay if show is called with no timeout Key: CB-9094 URL: https://issues.apache.org/jira/browse/CB-9094 Project: Apache Cordova Issue Type: Bug Components: Plugin SplashScreen Reporter: Dan Polivy Priority: Minor The Android SplashScreen plugin's showSplashScreen() method takes a parameter that determines whether the splashscreen should be hidden after a configurable delay. If an initial call to show the splash screen comes in with a delay, but while it is visible a second call comes in to show the splashscreen WITHOUT a delay, the splash screen will still be removed after the initial delay. In this scenario, I would expect that, due to the second call to show without auto-hiding, the splash screen would stay visible until the hide() method is called. Repro steps: 1. Splash screen is automatically shown on startup (e.g. showSplashScreen(true) is called in plugin initializer). If no SplashScreenDelay is specified in config.xml, then a default of 3s is used. 2. While the splash screen is still visible, the user calls navigator.splashscreen.show() from code (meaning it should be shown without a timeout, e.g. showSplashScreen(false) is called from onMessage). Actual: Splash screen disappears after delay. Expected: Splash screen should stay visible until hide() is explicitly called. -- 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-9060) [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent
Dan Polivy created CB-9060: -- Summary: [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent Key: CB-9060 URL: https://issues.apache.org/jira/browse/CB-9060 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 4.0.0 Reporter: Dan Polivy With cordova-android@4.0.0 and the new whitelist functionality, it seems that calls to CordovaWebView.showWebPage (via CordovaWebViewImpl implementation) are getting launched both in the app WebView AND via Intent in the system browser. This happens when, for example, the Cordova app is hosted remotely, so the actual URL is a http://www.somedomain.com/url, and the developer has included the following in config.xml: !-- Allow links to web pages to open in a browser -- allow-intent href=http://*/*; / allow-intent href=https://*/*; / Should there be a return statement at Line 216 to prevent any attempt to load the URL externally, if we actually load it internally? https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebViewImpl.java#L216 -- 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-9060) [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent
[ https://issues.apache.org/jira/browse/CB-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Polivy updated CB-9060: --- Description: With cordova-android@4.0.0 and the new whitelist functionality, it seems that calls to CordovaWebView.showWebPage (via CordovaWebViewImpl implementation) are getting launched both in the app WebView AND via Intent in the system browser. This happens when, for example, the Cordova app is hosted remotely, so the actual URL is a http://www.somedomain.com/url, and the developer has included the following in config.xml: !-- Allow links to web pages to open in a browser -- allow-intent href=http://*/*; / allow-intent href=https://*/*; / Then, if in the app, there is a call to showWebPage with a URL at http://www.somedomain.com, it will launch in both places. Should there be a return statement at Line 216 to prevent any attempt to load the URL externally, if we actually load it internally? https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebViewImpl.java#L216 was: With cordova-android@4.0.0 and the new whitelist functionality, it seems that calls to CordovaWebView.showWebPage (via CordovaWebViewImpl implementation) are getting launched both in the app WebView AND via Intent in the system browser. This happens when, for example, the Cordova app is hosted remotely, so the actual URL is a http://www.somedomain.com/url, and the developer has included the following in config.xml: !-- Allow links to web pages to open in a browser -- allow-intent href=http://*/*; / allow-intent href=https://*/*; / Should there be a return statement at Line 216 to prevent any attempt to load the URL externally, if we actually load it internally? https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebViewImpl.java#L216 [Android] CordovaWebViewImpl.showWebPage loads in WebView AND launches intent - Key: CB-9060 URL: https://issues.apache.org/jira/browse/CB-9060 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 4.0.0 Reporter: Dan Polivy With cordova-android@4.0.0 and the new whitelist functionality, it seems that calls to CordovaWebView.showWebPage (via CordovaWebViewImpl implementation) are getting launched both in the app WebView AND via Intent in the system browser. This happens when, for example, the Cordova app is hosted remotely, so the actual URL is a http://www.somedomain.com/url, and the developer has included the following in config.xml: !-- Allow links to web pages to open in a browser -- allow-intent href=http://*/*; / allow-intent href=https://*/*; / Then, if in the app, there is a call to showWebPage with a URL at http://www.somedomain.com, it will launch in both places. Should there be a return statement at Line 216 to prevent any attempt to load the URL externally, if we actually load it internally? https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaWebViewImpl.java#L216 -- 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-8761) WP8: FileTransfer does not inherit cookies from WebBrowser
[ https://issues.apache.org/jira/browse/CB-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Polivy resolved CB-8761. Resolution: Fixed WP8: FileTransfer does not inherit cookies from WebBrowser -- Key: CB-8761 URL: https://issues.apache.org/jira/browse/CB-8761 Project: Apache Cordova Issue Type: Improvement Components: Plugin File Transfer Reporter: Dan Polivy On Android and iOS (and presumably other platforms), the file transfer plugin will inherit any relevant cookies from the WebBrowser control when communicating with a particular domain. On WP8, however, that is not the case, as HttpWebRequest does not share cookies with the WebBrowser control. When cookies are used for authentication, and authentication is required for file uploads, it becomes important to be able to set cookies on the HttpWebRequest containing the upload. This should be supported on WP8 like it is on other platforms. I have built a solution to this problem that works; it essentially copies the relevant cookies from the WebBrowser control and manually generates a Cookie header for the HttpWebRequest. Due to some bugs in the version of .NET on WP8, not all cookie data is accessible in this manner (e.g. path, domain), however enough is there to get the job done. This fix is more limited to only scenarios where the browser scheme and host match that of the file transfer request to avoid any security issues with cookies going to the wrong domain. In my scenario, I am hosting my web pages remotely, on the same server I upload files to, so this works OK. Unfortunately, it won't help with scenarios where the transfer is to a different remote host. -- 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-8988) [splashscreen] iOS splash screen rotation incorrectly scales image
Dan Polivy created CB-8988: -- Summary: [splashscreen] iOS splash screen rotation incorrectly scales image Key: CB-8988 URL: https://issues.apache.org/jira/browse/CB-8988 Project: Apache Cordova Issue Type: Bug Components: Plugin SplashScreen Environment: iOS Reporter: Dan Polivy On iOS devices, if rotation occurs while the splash screen is visible, it ends up horribly/incorrectly scaling the existing image, instead of loading the correctly oriented image. This happens on both iPad and iPhone -- although technically iPhone should not allow rotation at all. (I see there is another issue tracking that for iPhone.) From debugging, the issue appears to be that the interfaceOrientation of the viewController has not been updated at the time that the frame/bounds changes are observed by the plugin. Thus, even though the frame/bounds change, the correct image for the new orientation is never loaded. I will provide a PR with an alternate fix shortly. I found it worked better to use [[UIApplication sharedApplication] statusBarOrientation] to determine orientation. -- 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-8758) WP8: splashscreen.hide() causes exception to be thrown
Dan Polivy created CB-8758:
--
Summary: WP8: splashscreen.hide() causes exception to be thrown
Key: CB-8758
URL: https://issues.apache.org/jira/browse/CB-8758
Project: Apache Cordova
Issue Type: Bug
Components: Plugin SplashScreen, WP8
Reporter: Dan Polivy
Assignee: Jesse MacFadyen
When calling the hide() method on splashscreen, on WP8, the call to
Popup.IsOpen throws a TargetInvocationException due to invalid cross-thread
access.
I don't know the specifics, but most likely the threading model for how plugins
are executed has changed over time, exposing this exception.
+ [System.Reflection.TargetInvocationException]
{System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation. --- System.UnauthorizedAccessException: Invalid
cross-thread access.
at MS.Internal.XcpImports.CheckThread()
at System.Windows.DependencyObject.GetValueInternal(DependencyProperty dp)
at System.Windows.FrameworkElement.GetValueInternal(DependencyProperty dp)
at System.Windows.Controls.Primitives.Popup.get_IsOpen()
at WPCordovaClassLib.Cordova.Commands.SplashScreen.hide(String options)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[]
arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj,
Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags
invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at WPCordovaClassLib.Cordova.Commands.BaseCommand.InvokeMethodNamed(String
methodName, Object[] args)
at WPCordovaClassLib.Cordova.Commands.BaseCommand.InvokeMethodNamed(String
callbackId, String methodName, Object[] args)
at
WPCordovaClassLib.Cordova.NativeExecution.c__DisplayClass6.ProcessCommandb__2()}
System.Reflection.TargetInvocationException
--
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-8750) WP8: Splashscreen should support pixel-perfect images for each resolution
Dan Polivy created CB-8750: -- Summary: WP8: Splashscreen should support pixel-perfect images for each resolution Key: CB-8750 URL: https://issues.apache.org/jira/browse/CB-8750 Project: Apache Cordova Issue Type: Improvement Components: Plugin SplashScreen, WP8 Affects Versions: 3.7.1 Reporter: Dan Polivy Assignee: Jesse MacFadyen Priority: Minor Currently, the splashscreen plugin on Windows Phone only supports a single SplashScreenImage.jpg file, and scales that to fit all device resolutions. But, it is possible to detect the resolution of the device, and allow for pixel-perfect splash screens for each individual resolution. I have some local changes that I will send as a PR to the plugin that allows one to specify three different images, each of different resolutions to match those supported by WP8. Resolution Dimensions File name WVGA480 x 800 SplashScreenImage.screen-WVGA.jpg 720p720 x 1280 SplashScreenImage.screen-720p.jpg WXGA768 x 1280 SplashScreenImage.screen-WXGA.jpg -- 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-6990) concatenate all plugins with cordova.js
[ https://issues.apache.org/jira/browse/CB-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14368214#comment-14368214 ] Dan Polivy commented on CB-6990: Has anyone started looking at this at all, or are there other hooks available to achieve the same end result? concatenate all plugins with cordova.js --- Key: CB-6990 URL: https://issues.apache.org/jira/browse/CB-6990 Project: Apache Cordova Issue Type: Improvement Components: CordovaJS Affects Versions: 3.5.0 Reporter: Anis Kadri Assignee: Steve Gill Fix For: 4.0.0 Use browserify to concatenate all plugins with cordova.js (instead of using dynamically loading cordova_plugins.js). To make it backward compatible with existing plugins, use browserify transforms to change the path of the require() calls with real paths. -- 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-7028) Memory leak in plugins when navigating from native page
[ https://issues.apache.org/jira/browse/CB-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14220665#comment-14220665 ] Dan Polivy commented on CB-7028: This change seems to be causing an issue for me with a barcode scanning plugin I'm using. When the plug-in is launched (via a Task), it appears the WebBrowser_Unloaded event is triggered, which removes all of the callbacks, including those for the plug-in that launched. As a result, when the plugin tries to return data back to the script, it fails to do so. Is this expected? Any suggestions on how to work around this? Memory leak in plugins when navigating from native page --- Key: CB-7028 URL: https://issues.apache.org/jira/browse/CB-7028 Project: Apache Cordova Issue Type: Bug Components: Plugin Device, Plugin Network Information, WP8 Affects Versions: 3.5.0 Reporter: Staci Cooper Assignee: Staci Cooper Priority: Minor Fix For: 3.6.0 When navigating between a native and hybrid page in wp8, if the network-information or device plugins are installed, there is a memory leak (in addition to leak solved in CB-6924), caused by the hybrid page never being garbage collected. -- 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-7667) [Camera] iOS8: Handle case where camera is not authorized
Dan Polivy created CB-7667: -- Summary: [Camera] iOS8: Handle case where camera is not authorized Key: CB-7667 URL: https://issues.apache.org/jira/browse/CB-7667 Project: Apache Cordova Issue Type: Bug Components: iOS, Plugin Camera, Plugin Media Capture Affects Versions: 3.5.0 Environment: iOS 8 Reporter: Dan Polivy Priority: Minor In iOS 8, it's possible for the camera to be disabled for any given app; in iOS 7, this was only possible in certain regions (e.g. China). If the camera is disabled, and someone launches the Camera plugin to capture an image from the camera, they'll just get the camera UI with a black screen, and no indication that the camera permission is disabled for the app. A better UX would be to show the user a prompt indicating that the camera permission is disabled, and (on iOS 8) providing a button to take them to the Settings app to change it. As of iOS 7, there's a new API to test whether the app has access to capture the desired media type: https://developer.apple.com/library/ios/documentation/AVFoundation/Reference/AVCaptureDevice_Class/index.html#//apple_ref/occ/clm/AVCaptureDevice/authorizationStatusForMediaType: [AVCaptureDevice authorizationStatusForMediaType:mediaType]; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CB-6313) Extra boundary in FileTransfer upload on Windows Phone
Dan Polivy created CB-6313:
--
Summary: Extra boundary in FileTransfer upload on Windows Phone
Key: CB-6313
URL: https://issues.apache.org/jira/browse/CB-6313
Project: Apache Cordova
Issue Type: Bug
Components: Plugin File Transfer, WP8
Affects Versions: 3.4.0
Environment: Windows Phone 8; Cordova 3.4.0
Reporter: Dan Polivy
Assignee: Jesse MacFadyen
I am using the File Transfer plugin on Windows Phone 8, and am adding
additional parameters to the upload via FileTransferOptions.params. When doing
this, I've found that an extra boundary is emitted into the request, which
unfortunately causes my node.js server (running express) to fail in parsing the
form submission.
The form submission ends up looking like this (notice the extra boundary
included after the parameters, and before the file itself):
--8d1119c8955f52c
Content-Disposition: form-data; name=param1
1
--8d1119c8955f52c
Content-Disposition: form-data; name=param2
2
--8d1119c8955f52c
--8d1119c8955f52c
Content-Disposition: form-data; name=file;
filename=///CapturedImagesCache/C__Data_Users_Public_Pictures_Camera
Roll_WP_20140319_001_jpg.jpg
{data}
--8d1119c8955f52c--
I've reviewed the code, and believe it is simply a one line fix to remove the
line causing the issue, but confirmation from one of the owners would be
helpful.
For me, it is line 746 of FileTransfer.cs:
requestStream.Write(boundaryBytes, 0, boundaryBytes.Length);
I've confirmed that commenting out this line in my app will allow the upload to
complete successfully.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6231) Better approach for preventing rubberband in Windows Phone 8
Dan Polivy created CB-6231:
--
Summary: Better approach for preventing rubberband in Windows
Phone 8
Key: CB-6231
URL: https://issues.apache.org/jira/browse/CB-6231
Project: Apache Cordova
Issue Type: Improvement
Components: WP8
Affects Versions: 3.4.0
Reporter: Dan Polivy
Assignee: Jesse MacFadyen
Priority: Minor
I've been looking for a good solution for the DisallowOverscroll setting that
works on Windows Phone 8; I've tried the
{{this.CordovaView.DisableBouncyScrolling}} setting, but it has the side effect
of making intended scrolling feel really sluggish, because it only responds
to swipes and doesn't track real-time under one's finger.
Using [this
approach|http://stackoverflow.com/questions/21652548/bouncing-when-overflow-set-to-auto-or-scroll-in-wp8-webbrowser-control],
I came up with an alternate implementation that works in the same scenarios as
{{DisableBouncyScrolling}}, but feels a lot nicer. Note that with _both_
implementations, if inertia causes the scrolling to hit the top or bottom, you
still get a small bounce -- I don't think there's any way to avoid that on WP8
at the moment.
I thought I'd share it here, in case you'd like to add it as another option in
the WP8 Cordova implementation. I'm happy to attempt a pull request if you'd
like (just not sure the best place for the JS code to live if it's part of the
'system').
{code:title=BrowserMouseHelper.cs|borderStyle=solid}
// This goes in the Border_ManipulationDelta event handler
var allowScroll = _browser.InvokeScript(eval, new string[] {
(function(delta) { return isScrollingAllowed(delta); })( +
e.DeltaManipulation.Translation.Y.ToString() + ) }) as string;
if (allowScroll == false)
{
e.Handled = true;
}
{code}
{code:title=.js file|borderStyle=solid}
// This goes in a JS file that's part of the app; I'm using jQuery, but it can
be written without that dependency
isScrollingAllowed = function(delta) {
var scrollTop = $(document).scrollTop(),
top = scrollTop === 0,
bottom = scrollTop + $(window).height() ===
$(document).height();
return ((top delta 0) || (bottom delta 0)).toString();
};
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CB-6231) Better approach for preventing rubberband in Windows Phone 8
[
https://issues.apache.org/jira/browse/CB-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Polivy updated CB-6231:
---
Description:
I've been looking for a good solution for the DisallowOverscroll setting that
works on Windows Phone 8; I've tried the
{{this.CordovaView.DisableBouncyScrolling}} setting, but it has the side effect
of making intended scrolling feel really sluggish, because it only responds
to swipes and doesn't track real-time under one's finger.
Using [this
approach|http://stackoverflow.com/questions/21652548/bouncing-when-overflow-set-to-auto-or-scroll-in-wp8-webbrowser-control],
I came up with an alternate implementation that works in the same scenarios as
{{DisableBouncyScrolling}}, but feels a lot nicer. Note that with _both_
implementations, if inertia causes the scrolling to hit the top or bottom, you
still get a small bounce -- I don't think there's any way to avoid that on WP8
at the moment.
I thought I'd share it here, in case you'd like to add it as another option in
the WP8 Cordova implementation. I'm happy to attempt a pull request if you'd
like (just not sure the best place for the JS code to live if it's part of the
'system').
{code:title=BrowserMouseHelper.cs|borderStyle=solid}
// This goes in the Border_ManipulationDelta event handler
var allowScroll = _browser.InvokeScript(eval, new string[] {
(function(delta) { return isScrollingAllowed(delta); })( +
e.DeltaManipulation.Translation.Y.ToString() + ) }) as string;
if (allowScroll == false)
{
e.Handled = true;
}
{code}
{code:title=.js file|borderStyle=solid}
// This goes in a JS file that's part of the app; I'm using jQuery, but it can
be written without that dependency
isScrollingAllowed = function(delta) {
var scrollTop = $(document).scrollTop(),
top = scrollTop === 0,
bottom = scrollTop + $(window).height() ===
$(document).height();
return !((top delta 0) || (bottom delta 0)).toString();
};
{code}
was:
I've been looking for a good solution for the DisallowOverscroll setting that
works on Windows Phone 8; I've tried the
{{this.CordovaView.DisableBouncyScrolling}} setting, but it has the side effect
of making intended scrolling feel really sluggish, because it only responds
to swipes and doesn't track real-time under one's finger.
Using [this
approach|http://stackoverflow.com/questions/21652548/bouncing-when-overflow-set-to-auto-or-scroll-in-wp8-webbrowser-control],
I came up with an alternate implementation that works in the same scenarios as
{{DisableBouncyScrolling}}, but feels a lot nicer. Note that with _both_
implementations, if inertia causes the scrolling to hit the top or bottom, you
still get a small bounce -- I don't think there's any way to avoid that on WP8
at the moment.
I thought I'd share it here, in case you'd like to add it as another option in
the WP8 Cordova implementation. I'm happy to attempt a pull request if you'd
like (just not sure the best place for the JS code to live if it's part of the
'system').
{code:title=BrowserMouseHelper.cs|borderStyle=solid}
// This goes in the Border_ManipulationDelta event handler
var allowScroll = _browser.InvokeScript(eval, new string[] {
(function(delta) { return isScrollingAllowed(delta); })( +
e.DeltaManipulation.Translation.Y.ToString() + ) }) as string;
if (allowScroll == false)
{
e.Handled = true;
}
{code}
{code:title=.js file|borderStyle=solid}
// This goes in a JS file that's part of the app; I'm using jQuery, but it can
be written without that dependency
isScrollingAllowed = function(delta) {
var scrollTop = $(document).scrollTop(),
top = scrollTop === 0,
bottom = scrollTop + $(window).height() ===
$(document).height();
return ((top delta 0) || (bottom delta 0)).toString();
};
{code}
Better approach for preventing rubberband in Windows Phone 8
Key: CB-6231
URL: https://issues.apache.org/jira/browse/CB-6231
Project: Apache Cordova
Issue Type: Improvement
Components: WP8
Affects Versions: 3.4.0
Reporter: Dan Polivy
Assignee: Jesse MacFadyen
Priority: Minor
Labels: scrolling
I've been looking for a good solution for the DisallowOverscroll setting
that works on Windows Phone 8; I've tried the
{{this.CordovaView.DisableBouncyScrolling}} setting, but it has the side
effect of making intended scrolling feel really sluggish, because it only
responds to swipes and doesn't track real-time under one's finger.
Using [this
