Throwing this in here for consideration, although it is not strictly related to the DNT and other networking issues, but WKWebView is much more likely to get new accessibility support enhancements. It may even be that Apple, known for not giving much on backward compatibility, may deprecate UIWebView in the near to medium future, which includes possible removal.
Marco On 08.12.2014 21:18, Stefan Arentz wrote: > 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 _______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
