Background: we have two choices for embedding a web view in an iOS application: UIWebView, which has been there since the early days, and now with iOS8, the new WKWebView. The UIWebView is what for example Chrome and pretty much every other third-party app uses while WKWebView is what Safari (and newer third party apps) uses.
The UIWebView is very minimal but it gets the job done. Basically you can ask it to load content, handle navigation and execute JavaScript when a page has loaded. But, no JIT. So about 3x slower than WKWebView. The WKWebView is new with iOS8 and exposes a much richer API. It has for example wonderful gesture support so you can swipe left just like in Mobile Safari. It also supports user scripts much better, which would allow us to introduce HTML5 APIs that WebKit does not know about. And it runs Nitro at full speed. It seems obvious to use the new WKWebView but there is a big limitation: it is impossible to intercept the URL Loading System. I found this out when I was trying to add support for a custom header (DNT) in a little experiment. https://github.com/st3fan/WebKitExperiments/blob/master/DoNotTrack/BasicBrowser/ViewController.swift#L6 How this works is as follows: by providing a custom NSURLProtocol class it is relatively trivial to intercept URL loading. In my example I simply build on top of the built-in NSURLConnection and the only custom thing I do there is to add a DNT header for outgoing requests. This same mechanism can also be used to inspect and modify requests for things like Mixed Content detection and would probably be part of Tracking Protection. Now the sad news. Unfortunately this only works on UIWebView. I see that my `CustomURLProtocol.canInitWithRequest()` is being called, but other than that nothing happens. I assume this is because the WKWebView executes network and content in a remote process. Which is good for security and performance, but closes the door to customizations like this. So, it seems we have to make a choice between slower UIWebView or a less optimal WKWebView. Note that there is not a good product definition just yet, but because so many of our better features depend on access to networking, I can only assume this will be a problem in the long run. I’ve been staring at this for a while now and I don’t really see a good workaround. I’d love to hear some suggestions or questions. S. _______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
