<!--
Please make sure the checklist boxes are all checked before submitting the PR. The checklist
is intended as a quick reference, for complete details please see our Contributor Guidelines:
http://cordova.apache.org/contribute/contribute_guidelines.html
Thanks!
-->
### Platforms affected
Android
iOS (both UIWebView & WKWebView implementations)
### What does this PR do?
Adds support for [postMessage API](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) enabling pages loaded into the InappBrowser to post messages back to the parent Webview of the Cordova app.
For example, sending event messages associated with UI interactions such as button clicks from the wrapped page back to the parent app Webview.
### What testing has been done on this change?
Automated tests have been extended to cover the `message` event.
### Checklist
- [x ] Commit message follows the format: "GH-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
- [ x] Added automated test coverage as appropriate for this change.
For both UIWebView and WKWebView implementations on iOS.
<!--
Please make sure the checklist boxes are all checked before submitting the PR. The checklist
is intended as a quick reference, for complete details please see our Contributor Guidelines:
http://cordova.apache.org/contribute/contribute_guidelines.html
Thanks!
-->
### Platforms affected
iOS
### What does this PR do?
Fixes `beforeload` event (introduced by #276) for iOS
### What testing has been done on this change?
Tested both allow & deny loading of URL with both iOS implementations in [test container app](https://github.com/dpa99c/cordova-plugin-inappbrowser-wkwebview-test) (ignore its README).
- To test with UIWebView use options: `beforeload=yes,usewkwebview=no`
- To test with WKWebView use options: `beforeload=yes,usewkwebview=yes`
### Checklist
- [x] [Reported an issue](http://cordova.apache.org/contribute/issues.html) in the JIRA database
- [x] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
- [x] Added automated test coverage as appropriate for this change.
closes#349
### Platforms affected
iOS
### What does this PR do?
fix issue[ #340](https://github.com/apache/cordova-plugin-inappbrowser/issues/340) iOS CDVWKInAppBrowser evaluateJavascript method randomly gets blocked on iOS 12
### What testing has been done on this change?
manual testing
### Checklist
- [x] [Reported an issue](http://cordova.apache.org/contribute/issues.html) in the JIRA database
- [x] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
- [ ] Added automated test coverage as appropriate for this change.
### Platforms affected
n/a - development with TypeScript
### What does this PR do?
Updates the typings to match the latest published version on DefinitelyTyped.
See https://github.com/DefinitelyTyped/DefinitelyTyped/pull/17192 and https://stackoverflow.com/q/42095516/1902598
### What testing has been done on this change?
Project compiles again ;)
### Checklist
- [x] [Reported an issue](http://cordova.apache.org/contribute/issues.html) in the JIRA database
- [x] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
- n/a: Added automated test coverage as appropriate for this change.
fixes#300
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
When calling `.open()` with a target of `_system`, the InAppBrowser on iOS is both launching the URL in the system browser AND also broadcasting to open the URL within the app (calling handleOpenURL). The latter behavior is problematic in many circumstances (e.g. when you want to explicitly open a link in a browser which is a universal link handled by the app).
This commit attempts to address this by checking the return value from openURL -- if it does not open the URL successfully, then (and only then) the code falls back to broadcasting the event within the app to handleOpenURL.
