Is WKWebView missing input file support?

I think the no reply's says it all. Hopefully in the next release this will be supported together with the ability to change the context menu. WebUIDelegate had both those options.

This issue is blocking me too and it seems like a crazy omission from the WKWebView's API. It means that any "select file..." button click event in the Web App that I host in the WKWebView cannot be intercepted.

Perhaps it is possible to workaround it with some alternative JavaScript calls? i.e. if possible, in the JS code, replace this:

"<input type="file">

with some kind of JS callback back into the a Native function, and from there the native function could pop open the file chooser dialog, etc. However I have no idea then how you'd pass the selected file back to the hosted web page? How would that be possible? Hmmm....

Any suggestions?

I am so glad that anyone at least acknowledges the problem. Felt like I was the only one.

Trust me I tried every possible hybrid method with Open Panel etc. but logically due to security reasons there is no way to manipulate the process unless you are sending raw data of the file to the javascript and let JS handle it from there. Unfortunately you will not always have that luxury to implement and it feels cumbersum to know UIWebView simply had delegates to handle these events. =(

I'm glad I'm not the only one with this issue too! 🙂 There seems to be very little about it though from any of the googl'ing I've been doing. According to this, it is a known "bug" but the bug was reported over a year ago and seems to be gone dead: https://bugs.webkit.org/show_bug.cgi?id=139745

I'm also having other issues with WKWebView, specifically around the JavaScript <--> Native interface - I've posted here about it: https://forums.developer.apple.com/message/81821#81821

Exactly. It's odd, since WKWebView seems to be the preferred way forward, also due to to the shared framework iOS and OSX.

On your other issue, if it's a callback you are after were you aware you could use:

userContentController.addScriptMessageHandler(self, name: "someFunc");

You can capture this with:

func userContentController(userContentController: WKUserContentController, didReceiveScriptMessage message: WKScriptMessage)

In JavaScript to communicate back to your code you can use:

webkit.messageHandlers.someFunc.postMessage("Object, Array or String you like to push back to your code");

Hey, thanks for that! I was aware of that mechanism alright, but it really doesn't offer the same level of power as what you can do with the old WebView - i.e. that mechansim doesn't allow you to directly call a Native function and get a result back. With the WebView, I could directly call Native (Objective C) functions, as if they were local functions.

In other words, today I do this (very roughly):

JavaScript:

var result = window.myNativeObject.foo()

Where "myNativeObject" is a registered "WindowScriptObject" and "foo()" is a public function defined in the myNativeObject's class.

The mechanism you mention is probably reasonably workable if the JavaScript doesn't care about getting a result back from Native and can just fire and forget. However in my case, my Web app code is very closely coupled to the native logic...