CB-7179 (iOS): Add WKWebView support for iOS

[dpa99c]

Platforms affected

iOS

What does this PR do?

This PR adds support for WKWebView to the InappBrowser plugin on iOS.
It:

• builds on the initial work done by Shazron on the wkwebview branch.
• takes on feedback from CB-7179 (iOS): Finish off WKWebView implementation #245
• contains some major changes, but with UIWebView now deprecated in iOS 12, then getting this plugin to support WKWebView seems now to be a higher priority.

Additional changes in this PR include:

• Separate UIWebView and WKWebView implementations which are invoked by an intermediate dispatcher dependent on the usewkwebview option.
• Adds shared cookie pool via CDVWKProcessPoolFactory, enabling app Webview to share cookies with IAB Webviews (pulled from Niklas Merz)
• Implements WKWebView delegates to make event handlers and script injection work
• Replaces iframe bridge with WKScriptMessageHandler bridge
• Updates the automated and manual tests for this plugin to test both webview implementations when running on iOS.

Any feedback/suggestions/bug reports/collaboration to improve the implementation in this PR would be most welcome.

What testing has been done on this change?

The automated and manual tests have been run as outlined here and all tests appear to pass for the iOS platform against both webview implementations.

Note: other platforms have not been tested because they have not been changed.

Notes

• A restructure of the native iOS implementation was necessary in order to enable the UIWebView and WKWebView implementations to exist side-by-side.
• No dependency has been added on cordova-plugin-wkwebview-engine for the iOS platform
  • If usewkwebview=yes is set and the WKWebView engine classes don't exist in the project, the 'loaderror' callback will be invoked when attempting to call InappBrowser.open().
  • Conditional pre-processor statements are used to detect the presence of WKWebViewEngine classes at build time to prevent build errors if not present
    • Note: the __has_include macro appears to only work in the device environment.
      • On the iOS Simulator it always evaluates to false.
      • This means the WKWebView implementation only works on devices - on the Simulator usewkwebview=yes will result in a loaderror.
  • The same classes exist in cordova-plugin-ionic-webview as in cordova-plugin-inappbrowser so usewkwebview=yes will work with both.
• There is currently a fair bit of duplication in the UIWebView vs WKWebView implementations. This could be cleaned up with some refactoring using inheritance, although this is tricky in Objective-C (not my strongest language).
• clearsessioncache is yet to be implemented in the WKWebView implementation. This is because the httpCookieStore interface was only added in iOS 11 and so to support iOS 10 and below, a different mechanism must be used to find and remove session cookies. This is not trivial and may not even be possible.
• The WKWebView implementation was initially developed as a separate WKWebView-only version of this plugin: cordova-plugin-inappbrowser-wkwebview
• A Cordova test project specifically to test switching between Webview implementations can be found here.

Checklist

• Reported an issue in the JIRA database
  • https://issues.apache.org/jira/browse/CB-7179
• 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.
  • CB-7179 (iOS): Add support to optionally use WKWebView for iOS
• Added automated test coverage as appropriate for this change.
  • No additional test coverage needed as no functionality has changed, just the implementation.

[dpa99c]

Travis CI build is failing because, as noted above, the __has_include macro appears to only work in the device environment, so fails when Travis spins up the iOS Simulator 😞

[dpa99c]

@infil00p @stevengill @agrieve @shazron @purplecabbage Could you guys review this when you get a chance?

[shazron]

Sorry for the late review. Could you resolve the conflicts before review? Thanks!

[dpa99c]

@shazron I've resolved the merge conflicts and rebased to a single commit.
Hopefully you have time to review before more conflicts arise with new commits to master.

[christianliebel]

@dpa99c Does “shared cookie pool” mean that the IAB can share cookies with the WebView as well? Unfortunately, there are new merge conflicts…

@shazron Do you have any plans on when this should be merged?

[dpa99c]

@christianliebel

Does “shared cookie pool” mean that the IAB can share cookies with the WebView as well?

Yes, it uses the CDVWKProcessPoolFactory class from cordova-plugin-wkwebview-engine in order to share cookies between the Cordova app Webview and the IAB Webview so setting a cookie in one makes it available in the other. This is currently enabled by default, but could be made optional.

Unfortunately, there are new merge conflicts…

Since the master branch is being continually updated, this PR branch will undoubtedly get out of sync with it. But there's no point in me continually resolving merge conflicts if this PR is never going to be reviewed/merged.

@shazron If cordova-plugin-wkwebview-engine is integrated into cordova-ios@5, maybe it would make sense to align this PR with cordova-ios@5?

This would eliminate the need for the __has_include Objective-C macro which is used to detect the conditional presence of the cordova-plugin-wkwebview-engine classes in the build, but which only appears to work in the device environment so is currently causing the Travis CI build to fail due to tests failing in the Simulator.

[janpio]

Just an aside: master is being updated mainly because other PRs were reviewed and merged.

[ghost]

Hi, any news when this PR will be merged and released into a new version?

[janpio]

As soon as 1) @dpa99c had the time to fix the conflicts, 2) someone or multiple ones from Apache Cordova (or the community, like you @rafaelberrocalj!) had time to test and review (hopefully with Approval), 3) then someone from Apache Cordova who takes the responsibility of merging the PR and finally 4) someone from Apache Cordova creates a new release of the plugin.

[dpa99c]

I have done my part and resolved the existing merge conflicts.
Hopefully the rest of the steps can follow before more conflicts arise.

[janpio]

Non-Obj-C parts of the PR look good. Left 2 comments.

[janpio]

What will happen if no WKWebView plugin is installed?

[dpa99c]

If usewkwebview=yes and no WKWebView plugin is installed, the loaderror callback will be invoked with the error message "usewkwebview option specified but cordova-plugin-wkwebview-engine not present"

[janpio]

Ah, got it.

2 suggestions:

1. Change "this" in the note to "Using usewkwebview=yes requires ..."
2. Change the loaderror callback to not refer to the specific plugin, but just mention "... but no plugin that supplies a WKWebView engine present" (or similar)

[dpa99c]

OK, I've made tweaks based on those suggestions

[janpio]

What does this onload param do? Couldn't find it anywhere else.

[dpa99c]

onload specifies whether to initialize the plugin when the app controller initializes. There's some docs about it here.
It ensures that pluginInitialize() is called on app startup, rather than the first plugin invocation.

[janpio]

I learned something, thanks ;)

Why this change? Could this have any side effects?

[dpa99c]

It just ensures that the default values defined by pluginInitialize() are set right away at app startup.
I don't remember the exact reason it was needed (it's been a few months since I created this PR) but I'm pretty sure it was necessary.
The change is minimal and will not cause side effects.

[shazron]

Travis is failing with:

/var/folders/my/m6ynh3bn6tq06h7xr3js0z7r0000gn/T/tmp-38722rDILqkxoJNN/platforms/ios/HelloCordova/Plugins/cordova-plugin-inappbrowser/CDVUIInAppBrowser.m:255:39: error: use of undeclared identifier 'baseWindowLevel'

            [tmpWindow setWindowLevel:baseWindowLevel+1];

[janpio]

(Oh great, I think that is from another PR.)

[dpa99c]

@shazron This change was added by PR #284 which is present on master and I have merged into this branch to resolve the merge conflict.

[shazron]

@dpa99c Unfortunately the build issue remains, do you have the ability to fix it? It might be a merge issue that removed something, not sure what. I tested this locally by installing the plugin from your branch and the error is still there.

[dpa99c]

@shazron you were right - I missed a line from that PR when resolving the merge conflict - I've updated this PR branch to correct this and Travis CI build is no longer failing because of this.

However, the Travis job is still failing because the tests are building/running against the iOS 9.3 SDK, however the new WKWebView implementation uses some properties of the WKWebViewConfiguration class which were only introduced in the iOS 10 SDK, such as ignoresViewportScaleLimits.
Use of these properties is necessary to support options currently supported by the UIWebView implementation (enableviewportscale, allowinlinemediaplayback, mediaplaybackrequiresuseraction ).

Is building against iOS 9 SDK still a mandatory requirement for cordova-plugin-inappbrowser?

[shazron]

We should update it to test only against the iOS 10 SDK, and make a note of it in the release notes, and also bump a minor version at least.

[ghost]

Hi, can i test this pull request somehow in config.xml?
I know it's possible use a github url/branch but i don't know a pull request.

[NiklasMerz]

You can install the plugin from the branch which this pull request is based on via:

cordova plugin add https://github.com/dpa99c/cordova-plugin-inappbrowser#CB-7179

[ghost]

With this changes i still need to use https://github.com/apache/cordova-plugin-wkwebview-engine ?

[dpa99c]

@rafaelberrocalj yes, if you want to use the WKWebView implementation, you'll need the WKWebView engine plugin

[janpio]

Ok thanks, so the iOS 9.3 test I readded should probably fail.

But currently both are failing:

...
cordova-paramedic: waiting for test results
appium: Error: [execute(null,[])] getaddrinfo ENOTFOUND ondemand.saucelabs.com ondemand.saucelabs.com:80
cordova-paramedic: Tests failed to complete; ending appium session. The error is:
Error: waitForTests: Seems like device not connected to local server in 540 secs
    at null._onTimeout (/private/tmp/paramedic/lib/paramedic.js:467:24)
    at Timer.listOnTimeout (timers.js:92:15)
...

*sigh (Investigating)

[janpio]

And as it came it's gone - now the tests are just failing because they don't get their results from Saucelabs :/

[janpio]

Confirmed that the switch to Xcode8.3 is not the cause for the test failures:
#312

[dpa99c]

Confirmed that the switch to Xcode8.3 is not the cause for the test failures:
#312

OK, there must be something preventing the tests running via cordova-paramedic because when I manually start them in the Simulator, they all pass. Will setup cordova-paramedic and investigate.

[dpa99c]

@janpio I think I've figured out why the tests are failing in this PR, even in Xcode 8.3/iOS 10:

This PR requires that cordova-plugin-wkwebview-engine be present in the Cordova project so its classes can be used by the WKWebView implementation in this PR. This means the main Cordova Webview is using WKWebView instead of UIWebView. And this seems to screw up cordova-paramedic - it can no longer communicate its results back to the local server.

I confirmed this by running cordova-paramedic against your janpio-xcode8.3 branch first without cordova-plugin-wkwebview-engine present (i.e. using UIWebView):

Then with cordova-plugin-wkwebview-engine present (i.e. using WKWebView):

As you can see, in this second case the tests timed out while trying to connect to the local server, leading to the same error observed in the Travis CI logs. However, as you can see from the Simulator screenshot, all the tests passed.

I then ran the cordova-paramedic against the branch for this PR:

As you can see, a similar result: all tests passed in the Simulator, but tests failed due to a timeout connecting to the local server.

The upshot is that it seems currently cordova-paramedic is not compatible when the main Cordova Webview is WKWebView and this presents a problem for this PR which requires it to be so.

I'm guessing since UIWebView is now deprecated in iOS 12, we'll be moving at some point to make WKWebView the default Cordova Webview (in cordova-ios@5 ??), so at some point cordova-paramedic is going to need to be fixed to work with WKWebView.

[dpa99c]

Thanks to @knight9999 for helping to resolve apache/cordova-paramedic#52, Travis tests are now passing for iOS.

But failing on other platforms for some reason.

[dpa99c]

@shazron @janpio What's now blocking this PR?

All merge conflicts with master are currently resolved and the Travis CI tests are now passing for iOS. The Travis tests for "browser-edge" and "android-6.0" failed on the last run due to timeout/connectivity issues, but then the tests are currently failing on master for similar reasons.

[purplecabbage]

We can’t have this dependency, even in a test ... what if knight9999 makes a commit to master? It could break our tests ...

[dpa99c]

Without the code in that plugin, cordova-paramedic tests fail with WKWebView.
What do you suggest? Bundle the plugin code inside tests/ within this plugin?

[purplecabbage]

The plugin itself is only 2 lines. There are a couple things we could do.

1. Ask @knight9999 to publish the allowfileaccess plugin to npm, and have our test depend on that published version.
2. make the wk-allowfileaccess a cordova supported plugin, and also do suggestion 1, but replace Ken with 'we'
3. revisit the decision to not allow file access directly in the wkwebview plugin, could we just default to NO, but allow the developer to turn it on? ( This would require a firm warning about app store rejection possibilities, so it might make things too easy for developers and lead to rejections. )
4. Include it in the paramedic repo as a spec plugin, as suggested by Ken [1]

[1] apache/cordova-paramedic#52

[dpa99c]

@knight9999 Ken, any preference in Jesse's above options?
This isn't something I can resolve myself to unblock this PR: all of the above require action on the part of Cordova maintainers and it has wider implications in terms of test support for WKWebView on iOS, i.e. for cordova-plugin-wkwebview-engine and cordova-ios@5.

[knight9999]

Now I have updated my plugin to change author 'Apache Cordovaand licenseApache-2.0`.
But I think it is better to change github repository before publishing to npm. Now I am asking this to cordova members.

[knight9999]

I have published my plugin https://www.npmjs.com/package/cordova-plugin-wkwebview-engine-allowfileaccess .

[svanzoest]

So the websites you display in the InAppBrowser were using local storage, which was not there after the switch to WKWebView? How did you solve this @svanzoest?

We used https://github.com/MaKleSoft/cordova-plugin-migrate-localstorage however that did not migrate the inappbrowser localstorage. @geeetarguy plans to make a PR against that repo so it will migrate inappbrowser localstorage as well.

This PR is now available MaKleSoft/cordova-plugin-migrate-localstorage#4

[purplecabbage]

Every other way of doing this is messy and involves crazy git rebasing, so I am gonna just merge this as is, and see if I can address my concern about the test dependency in another pr.
Thanks for all you work on this @dpa99c !!

[dpa99c]

@purplecabbage great, thanks for unblocking this. I will be on standby to help resolve any issues with the new implementation.

[jonathanli2]

Hi,
After upgrading our ios Fiori client application to the new inappbrowser, somehow, the content in the main webview (UIWebview or WKWebView) is disabled and cannot response to user actions. The same app works normal when using inappbrowser version 2.0.x.

I submitted an issue for this at
#334

The testing projects are shared at
https://sap-my.sharepoint.com/:f:/p/jonathan_li/EmulfDR6x9RBuQdj5u1-NrwBYchculWO6RAfoC_NTM8XLw?e=YzzUkh

Any idea for this issue?

Thanks
Jonathan

[jonathanli2]

I created a simple iOS UIWebView cordova app with just inappbrowser plugin added into the project, and it can repeat the same issue.

The project (basictest.zip) is shared at the folder of
https://sap-my.sharepoint.com/:f:/p/jonathan_li/EmulfDR6x9RBuQdj5u1-NrwBYchculWO6RAfoC_NTM8XLw?e=YzzUkh

The project (basictest.zip) only has a simple openInappbrowser button, once index.html is opened, then clicking toolbar's done button to close the inappbrowser. After the inappbrowser is closed. Clicking on the main UIWebView's openInappbrowser button again will do nothing, it seems the main UIWebView is disabled.

This indicates the issue is in the new inappbrowser plugin's implementation.

Thanks
Jonathan