New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 423444 link

Starred by 164 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
Pri: 2
Type: Bug

Blocked on:
issue 390660
issue 450311
issue 450362

issue 136610
issue 420630
issue 468179
issue 468258
issue 525262

Sign in to add a comment

Use WKWebView on iOS 9+

Project Member Reported by, Oct 14 2014

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.

 Issue 412906  has been merged into this issue.
Issue 382663 has been merged into this issue.
Relevant Radars filed for the more significant limitations:
- Lack of cookie management (rdar://17486250, rdar://18180302)
- Lack of protocol handling (rdar://17177376)
- Missing request bodies (rdar://18399639)
- File upload issues (rdar://18350812)
- Limited SSL cert handling (rdar://18494626, rdar://18517043)

Comment 4 Deleted

I think this is the perfect time to create a separate beta version specifically for testing new features such as this. WKWebView support is already late, don't make us wait into next year please.
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.

Comment 8 by, Nov 17 2014

If possible (I'm not familiar with how secret are those submissions) please post updates to reported rdars in this bug (especially if they're fixed/wontfixed).

Comment 9 Deleted

Blockedon: chromium:390660
Blocking: chromium:420630
Blockedon: chromium:450311
Blockedon: chromium:450362
Was wondering if there have been any updates to address the limitations of WKWebView. Is it safe to assume that Chrome for iOS will not be using WKWebView for the foreseeable future?
iOS 8.1 did not address any of the API limitations described above.
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.
Labels: Hotlist-WKWebView
Blocking: chromium:468258

Comment 19 Deleted

Comment 20 Deleted

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.
WKWebView currently has no API related to configuring storage limits or requesting increases in storage.
Labels: hotlist-ios-fixit
Labels: hotlist-ios-fixit-stuartmorgan
Labels: -hotlist-ios-fixit-stuartmorgan
Labels: hotlist-ios-fixit-msarda
Labels: hotlist-ios-fixit-done
Status: Assigned

Comment 28 by, May 25 2015

Did iOS 8.3 make any difference in the list of issues?

Comment 29 Deleted

> Did iOS 8.3 make any difference in the list of issues?


Comment 31 Deleted

Comment 32 Deleted

Comment 33 Deleted

Comment 34 Deleted

Apple has recently released WKWebsiteDataStore, does it resolve anything?
WKWebsiteDataStore appears to make it possible to delete cookies, so it addresses part of one bullet of comment 3 (which is itself not an exhaustive list of issues)

Comment 37 by Deleted ...@, Jun 18 2015

The implementation of WKWebsiteDataStore is not completed yet. We can expect more changes to it in the up coming betas
Not sure if this on the radar for this bug, but it seems to be a rather crippling experience.  Please see  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.

Comment 40 Deleted

Blocking: chromium:525262
Blocking: chromium:136610
Would it be possible to do some kind of hybrid between UIWebView and WKWebView? Somehow make requests via UIWebView and process them via WKWebView?
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)
Blocking: chromium:468179
We're currently running a small experiment with WKWebView in version 47, which will give us more quantitative data about how WKWebView compares to UIWebView in actual use.

Comment 49 by, Dec 3 2015

Great news :)
Firefox on iOS is crashing on window.openDatabase() due to WKWebView
"SecurityError: DOM Exception 18: An attempt was made to break through the security policy of the user agent."
Re #50 -- FWIW, we're in contact with the Chromium folks, including Stuart, and we're sharing solutions wherever we can.

Comment 52 by, Jan 3 2016

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.
Labels: -hotlist-ios-fixit -hotlist-ios-fixit-msarda -hotlist-ios-fixit-done
Summary: Use WKWebView on iOS 9+ (was: Use WKWebView on iOS 8+)
Updating the title; several blocking regressions (e.g., inability to continue past SSL warnings) were only addressed in iOS 9, so we don't consider WKWebView on iOS 8 viable for Chrome.
Labels: M-48
Status: Fixed
As announced here:
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 (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.

Comment 56 by, Mar 9 2016

Labels: -Hotlist-WKWebView Hotlist-WkWebView
Hey Stuart, I'm wondering how you guys got past the issues presented by WKWebView being sandboxed and the protocol handlers no longer working.

Comment 57 by, Mar 9 2016

Why the label change? The official name is WKWebView, not WkWebView.
(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 (<>) because they could not be implemented without access to the network requests issued by WKWebViews.

Comment 59 by, Mar 9 2016

Thanks for the reply Stuart! I was hoping you'd found some clever work-around but the answer I was interested in sadly is that you removed the features that depended on access to the network requests.

Sign in to add a comment