Remove dependency on cordova-plugin-wkwebview-engine

[imgx64]

We want to use this plugin with cordova-plugin-ionic-webview, but this plugin contains <dependency id="cordova-plugin-wkwebview-engine" /> in plugin.xml. cordova-plugin-ionic-webview conflicts with cordova-plugin-wkwebview-engine and we get duplicate symbol errors at build time.

Should this dependency be removed? Anyone who wants to use this probably already installed cordova-plugin-wkwebview-engine.

[gvanmat]

@imgx64 The cordova-plugin-wkwebivew-file-xhr was built specifically to overcome new CORS constraints of the latest version of the safari browser "wkwebview" introduced using the cordova-plugin-wkwebview-engine. It's never been tested using the ionic-webview. Not sure if it would even work. The JS side of the plugin doesn't always go thru the cordova JS API. It directly posts messages to the window.webkit.messageHandlers for optimal performance.

[imgx64]

@gvanmat cordova-plugin-ionic-webview is a fork of cordova-plugin-wkwebview-engine and uses WKWebView. I'll do some tests and see if this plugin works with it if I remove the dependency.

[imgx64]

I tested it and it does work with cordova-plugin-ionic-webview if I remove the dependency.

[gvanmat]

@imgx64 I don't see the value add of using the ionic-webview plugin with the wkwebview-file-xhr plugin over wkwebview-engine. There are two main features of the wkwebivew-file-xhr plugin:

1) The default behavior of WKWebView is to raise a cross origin exception when loading files from the main bundle using the file protocol - "file://". This plugin works around this shortcoming by loading files via native code if the web view's current location has "file" protocol and the target URL passed to the open method of the XMLHttpRequest is relative. As a security measure, the plugin verifies that the standardized path of the target URL is within the "www" folder of the application's main bundle.

2) Since the application's starting page is loaded from the device's file system, all XHR requests to remote endpoints are considered cross origin. For such requests, WKWebView specifies "null" as the value of the Origin header, which will be rejected by endpoints that are configured to disallow requests from the null origin. This plugin works around that issue by handling all remote requests at the native layer where the origin header will be excluded.

I believe the ionic plugin addresses #1 by running a local http server. This plugin addresses #1 without the overhead of creating a http server. It seems like installing the wkwebview-file-xhr plugin will override the use of the local server? What value add would the ionic plugin provide?

[rdantonio]

I can't speak for @imgx64 but personally I use ionic for addressing the issue you mentioned as it seems to work better for my use cases (we use a custom system similar to this plugin which does not use the www folder) and I use the InterceptRemoteRequests feature of this plugin to work around the CORS restrictions of AJAX requests that our application uses to communicate with our backend. It's been working very well so far and has solved many of our problems when updating to WKWebView

[gvanmat]

@rdantonio and @imgx64. It sounds like the ionic plugin provides similar features to the wkwebview-engine + wkwebivew-file-xhr. At this time, there doesn't seem to be a good reason to remove the dependency on the apache wkwebview-engine since they are parallel solutions.

[mlynch]

(Max from the Ionic team here). Does this plugin allow for HTML5 routing somehow?

We'd love to not use a webserver. It's not ideal, but it appeared to be necessary for HTML5 routing. Open to finding a middle ground here and would love your thoughts!

[gvanmat]

@mlynch Hi Max. The file-xhr plugin only intercepts XMLHttpRequest and the Fetch API. It doesn't intercept the history API.

I assume you are talking about an error like this: SecurityError: Blocked attempt to use history.pushState() to change session history URL from....

We started seeing this error with with iOS v 11.3 and 11.4. It was not seen in 11.2. I think it's this issue: https://bugs.webkit.org/show_bug.cgi?id=183028

The bug is resolved but I don't know in what version the fix will appear.

[mlynch]

Thanks @gvanmat. I just realized that one of the biggest challenges with HTML5 routing is to enable direct navigation to a page but pass that through to the index file, which isn't really something native mobile apps need to handle anyways.

I'm going to spend some time playing with this plugin and see if we can offer it as an alternative to ours down the road.

[gvanmat]

@mlynch Sounds great. Please let us know of any issues you run into. If it looks like a good fit, combining efforts might be most beneficial for the communities.