I wanted to comment on the JIT difference in WKWebView. JS performance alone is not really a good indicator for a webapp's performance. For now, I am willing to trade Networking flexibility for a JS speed bump. Some benchmarks [1] show that the JIT difference does not yield a dramatic performance improvement.
[1] http://developer.telerik.com/featured/why-ios-8s-wkwebview-is-a-big-deal-for-hybrid-development/ ----- Original Message ----- > I think a lot of our "platform" direction (DNT, Tracking Protection, Mixed > Content Blocking, SafeBrowsing) depend on accessing the URL Loading System. > As Heath mentions, we will need to consider it for HTTP Auth and cert > features too. > Let's start with UIWebView and see how things evolve. > ----- Original Message ----- > > 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
