Update InAppBrowser.java to allow custom URI schemes and intents

[AhrenFullStop]

in line with allowing custom URI schemes and this issue I've changed the if statement that enforces http for no apparent reason: #548

Platforms affected

IOS and Android, allows custom URI Schemes

Motivation and Context

fixes issue here: #548
Allows the user to use window.open() to open custom URI's such as intents (tel:// or anotherapp://) easily.

Description

All I did was remove an if statement that checks for the URI starting with Http, Https or File. so that the uri can be in any format.

Testing

Tested locally, working.

Checklist

• [ x] I've run the tests to see all new and existing tests pass
• I added automated test coverage as appropriate for this change - no, tiny change
• [ x] Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
• [x ] If this Pull Request resolves an issue, I linked to the issue in the text above (and used the correct keyword to close issues using keywords)
• [ x] I've updated the documentation if necessary

[AhrenFullStop]

allow custom URI schemes and intents

[jim0020]

I could really use this right now. I have a need to redirect to a custom url scheme which is working great in iOS, but is dead in the water in Android.

[NiklasMerz]

Looks like there was already a long discussion about custom schemes for iOS in this PR #274

Those two PR should be reviewed together.

[brody2consult]

In addition to #274, I discovered 2 more PRs that looks related:

• CB-14013: (android) Change the InAppBrowser to allow custom schemes for oAuth #263 - allow custom schemes for oAuth on Android (seems to be merged in 2018)
• documenting the custom schemes handling #357 - document custom schemes handling

We would like to keep the behavior on Android, iOS, and other platforms as consistent as possible. I don't know if we should discuss this in an existing issue, new issue, or somewhere else?

[NiklasMerz]

Indeed. It looks like #263 already introduces AllowedSchemes and that should make this PR obsolete and can be closed?

But the inconsistencies may still exists, like said in the other PRs.

[brody2consult]

I would really favor that we try to understand the why before merging or closing. It looks like #263 added some functionality but it does not do what they needed in #548 for some reason.

[NiklasMerz]

@AhrenFullStop Did you try #263 to solve your problem? We would like to understand if this PR is still necessary for certain use cases.

[GitToTheHub]

I think this is fixed by #263 which allows custom shemes