On Android, if the app defines an intent-filter for a given URL, and
then tries to use inappbrowser to launch that URL via the _system
target, the default handler for that intent is the app itself.
That behavior can lead to circular loops, and ultimately is not what the
developer wants -- the link should be launched in a browser.
Because there is no easy way to find the "default" system browser on a
device, this solution will do two things:
1) Check if the app is one of the targets for this intent
2) If so, create a custom chooser with all other targets, excluding the
current app.
If the app is not a target, then the current (existing) behavior is
preserved.
The only real "downside" to this approach is that a default handler can no longer be set for these URLs within the app, and a chooser will be shown each time the user taps a link that opens in a new browser.
Fixes https://issues.apache.org/jira/browse/CB-10795
check for whitelisting custom schemes via a new "AllowedSchemes"
preference configuration item. Allows custom schemes like
"mycoolapp://" or "wevotetwitterscheme://"
In file inappbrowser.js: Added new "customscheme" channel.
check for whitelisting custom schemes via a new "AllowedSchemes"
preference configuration item. Allows custom schemes like
"mycoolapp://" or "wevotetwitterscheme://"
In file inappbrowser.js: Added new "customscheme" channel.
"AllowedSchemes" in a new preference configuration item.
There is a new check in shouldOverrideUrlLoading, to allow whitelisted
custom schemes like "mycoolapp://"
inappbrowser.js: Added "customscheme" channel.
"AllowedSchemes" in a new preference configuration item.
There is a new check in shouldOverrideUrlLoading, to allow whitelisted
custom schemes like "mycoolapp://"
inappbrowser.js: Added "customscheme" channel.
Added support for hiding the web view container. This maintains the browser
session without closing it. The browser window can be repeatedly hidden and
shown.
** This has only been tested on android and ios **
amazon/android:
An additional `hide` action was added to `InAppBrowser#execute`. It is
identical to `show`, except that it calls `dialog.hide()` instead.
blackberry10:
no changes
firefoxos:
Added a `hide` method that is identical to `show`, indicating it is not
supported.
ios:
Added a `hide` method that is identical to `show`, except that it uses
`dismissViewControllerAnimated`. It checks the value of
`_previousStatusBarStyle`. If it is `-1`, the method returns with no
action performed. If it is not, it is set to `-1.`
ubuntu:
Added a `hide` method that sets `CordovaWrapper.global.inappbrowser.visible` to
`false`.
windows:
Added a `hide` method that sets `browserWrap.style.display` to `none`.
wp:
Added a `hide` method that is identical to `show`, except that it sets
`browser.Visibility` to `Visibility.Collapsed` and sets `AppBar.IsVisible` to
`false`.
HadwareBackButton value persists across usages. By default hardwareBack value is null. In this case we should set hadwareBackButton to default value.
This closes#188
Dan Polivy