Issue 423444:
Use WKWebView on iOS 9+

Issue description

This is a meta-bug to track using the new WKWebView instead of UIWebView on iOS 8+. This would have several advantages we're aware of:
- Faster JS (modern engine rather than the older engine UIWebView is still restricted to use)
- Crash isolation (renderer crashes wouldn't bring down the whole app, better matching Chrome on other platforms)
- Support for IndexedDB (support for which was *not* added to UIWebView even in iOS 8)
Unfortunately, despite the advantages of WKWebView, it has some significant technical limitations that UIWebView does not, which means we can’t simply drop it in as a replacement. A partial list of regressions relative to UIWebView that we’re currently aware of:
- There is no cookie management API, which means there is no obvious way to clear/manage cookies
- Protocol handlers no longer work, which breaks several very important features
- POST bodies are missing from delegate callbacks, which breaks certain aspects of form handling
We’re still actively investigating WKWebView, looking for possible alternate approaches, and providing feedback to Apple about issues. We certainly hope to use WKWebView in the future, but there’s currently no way of knowing if or when that will be possible.

It's not a question of testing, it's a question of fundamental limitations in WKWebView as explained above. It doesn't make sense to describe it as "late", since the summary above is very clear that we don't have a timeline for switching due to those limitations.
It would have been great if WKWebView had been an unambiguous improvement over UIWebView so that switching was just a case of doing the technical work to adopt the new APIs, but that's unfortunately not the reality of what Apple provided in iOS 8.

Chrome on iPad runs like crap because of UIWebview. The version for the iPhone is not so bad maybe because a lot sites have mobile versions which are optimize for mobile browsers. However, chrome for iPad typically run full websites which tend lag and have scrolling issues. Putting WKWebView should be a priority for the iPad despite the limitations because the current chrome has serious performance issues.

If WKWebView solves problems like Safari's arbitrary 50MB size limit on websql data, then using it would be an opportunity for Chrome to become a superior browser to Safari. My company produces an app that saves lots of data in websql and we would love to be able to recommend Chrome over Safari if it could get us out from under the 50MB data size limitation in Safari.

Not sure if this on the radar for this bug, but it seems to be a rather crippling experience. Please see crbug.com/451383 for details.
Basically interaction with an input field inside an iframe is crippled.

We are keenly aware of all the differences that have come up in bugs between UIWebView and WKWebView.
The problem here is not a lack of awareness on our part, it's that some aspects of WKWebView on iOS 8 are also crippling.

We are running into a number of issues on Chrome iOS that are not present in iOS Safari including:
- xhr upload progress callback is not fired.
- file picking fails randomly on iOS 9.
- "cloud" images (from new iOS 9 photo picker) fail to upload.
- clipboard API doesn't work.
- transition animation issues.
- general responsiveness.
I wonder when it will get to the point that the pros of being on WKWebView outweigh the cons. For now, we are just going to message our users that they will have a better experience with Safari. But as I have been using chrome iOS personally, I find that kind of sad.

Could you file new specific bugs about each of those things (except the general responsiveness, since I think we have a good handle on the UIWebView/WKWebView differences there) with repro cases/steps?
We're actively tracking UIWebView/WKWebView differences, precisely because of the tipping point you're referring to. We have an experimental version of the web layer based on WKWebView under active development, and I like to have our team test to see whether those are all due to UIWebView vs WKWebView (as opposed to something Safari-specific)

Hey - is there an ETA or expected version number using WKWebView? This has been going on for over a year and it'd be interesting for developers to know if it's a good idea to spend time fixing UIWebView specific bugs that don't happen in WKWebView.

As announced here:
http://blog.chromium.org/2016/01/a-faster-more-stable-chrome-on-ios.html
version 48 switches to WKWebView.
Worth noting is that for some users the switch to WKWebView may not happen on the first launch of M48 (due to on-disk state related to the previous shutdown). This is particularly true if the browser is currently in incognito mode.
- You can check which web view you are using with https://jsfiddle.net/j4vkwjj2/1/ (which checks for the presence of IndexedDB support)
- If you are running version 48 but see that you are using UIWebView, you can accelerate the change-over by ensuring that you are not in incognito mode, then terminating the Chrome process by double-tapping the home button and swiping up on the Chrome snapshot.

(The label case change seems to be a side-effect of the bug system migration.)
There's no single answer to the issue of protocol handlers no longer working. In some cases (e.g., WebUI) we were able to implement completely different approaches. In others (e.g., cert handling, cookie clearing) iOS 9 added APIs that enabled at least some of what we needed. And unfortunately a number of features had to be removed (<https://support.google.com/chrome/answer/6323113>) because they could not be implemented without access to the network requests issued by WKWebViews.