Fixes CB-11074: WKWebView configuration is not considered

[akofman]

I updated the configuration before the WKWebView initialisation in order to consider it.
It implies that the updateWithInfo method doesn't update it anymore. I'm not sure it is really a problem but I'd prefer @shazron to confirm.

Thanks for the reviews !

[akofman]

Any feedback ?

[shazron]

It still needs to be able to update it dynamically. I would refactor it to not remove the existing code, but create a new - (WKWebViewConfiguration*) createConfigurationFromSettings:(NSDictionary*)settings;

That way it can be used in both updateSettings and initWithFrame

[ephemer]

As I commented in the base repo, this PR doesn't do what it says it does yet.

@shazron is it normal to change the settings after the WebView has already been inited? When? It seems like this feature (of changing settings after init) is creating unnecessary work for us.

My preferred approach would be to init the CDVPlugin/WebViewEngine instance, but not the WKWebView immediately, because for that to work, we need the commandDelegate to be set. The problem with that approach is that this check in CDVViewController.m will fail, causing self.webViewEngine to fallback to UIWebView:

if (!self.webViewEngine || ![self.webViewEngine conformsToProtocol:@protocol(CDVWebViewEngineProtocol)] || ![self.webViewEngine canLoadRequest:[NSURLRequest requestWithURL:self.appUrl]]) {
    self.webViewEngine = [[NSClassFromString(defaultWebViewEngineClass) alloc] initWithFrame:bounds];
}

So that approach wouldn't work as is.

The only thing I can image that would work in the current CDVViewController.m structure is that we init a WKWebView with default options on init, then re-init the WKWebView in pluginInitialize with the user's actual settings, because it's only then that commandDelegate.settings is finally available. It's a bit more work but might be the only way to get around the current issues.

[shazron]

@ephemer not just settings (which as you said will probably not a frequent scenario), but setting the other delegates. updateWithInfo will be used for certain apps that need to set their own delegates on the webViewEngines -- a minor case, but I encountered this just last week.

I don't think self.webViewEngine will fail in the case of your 'preferred approach' you mentioned since that is just the CDVPlugin object wrapper that will always be instantiated unless WKWebView is not available:

cordova-plugin-wkwebview-engine/src/ios/CDVWKWebViewEngine.m

Lines 47 to 49 in 33a7517

	if (NSClassFromString(@"WKWebView") == nil) {
	return nil;
	}

I'll comment on your #8 pull request.

[kenichi-fukushima]

A drive-by comment:
In our app, we ended up subclassing CDVWKWebViewEngine and creating another instance of WKWebView in -pluginInizialize so that we can use configuration values that we want. I'd suggest factoring out the code to create WKWebViewConfiguration to another method so that Cordova users can customize the logic by code rather than static configurations in a file. This means you can't create a web view instance in the initializer any more. This is OK because CDVWKWebViewEngine doesn't have to conform to the usual plugin semantics and you can add a factory method like -webView.

[macrozone]

It seems that this bug prevents autoplay in

I needed to switch back to UiWebview in my meteor application because of this.

See also meteor/meteor#7173

[shazron]

I'm creating failing unit tests for this first, I think we have passed the point where we can argue about the implementation, but we need objective verification: https://issues.apache.org/jira/browse/CB-11496

[macrozone]

Any update on this? In my opinion, this is a very severe issue with WKWebview.

[shazron]

I have failing unit tests that do objectively verify that as others have shown, yes, we can't update the configuration dynamically (I've tried all sorts of clever runtime tricks, to no avail).

The WKWebViewConfiguration.preferences (WKPreferences) can however be updated dynamically. I will update https://issues.apache.org/jira/browse/CB-11496 with the unit tests to reflect this, as well as document this. After doing so, I will re-review this pull request with that in mind.

[macrozone]

@shazron : cool, thanks. Is there any short-time workaround known?

[shazron]

Please see #13, and let's continue discussion there.

[shazron]

Please provide feedback on #13, I will be pulling that in soon.