Bug 140201

Summary: Provide public API to control persistent data in WKWebView
Product: WebKit Reporter: Eugene But <eugenebut>
Component: WebKit2Assignee: Nobody <webkit-unassigned>
Status: REOPENED ---    
Severity: Normal CC: ap, dieter, krzysztof.modras, m.goleb+bugzilla, mjs, rniwa, stefan, stuartmorgan
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: iPhone / iPad   
OS: All   

Description Eugene But 2015-01-07 13:51:09 PST
Chrome for iOS allows for multiple profiles, which require separating all persistent storage and state between the different profiles. This includes things HTML5 localStorage and visited links, which WKWebView doesn't appear to provide any API for.

The functionality appears to exist; WKWebViewConfigurationPrivate.h has both _setVisitedLinkProvider: and _setWebsiteDataStore:, which sound like exactly what is needed to implement these features correctly.

As it is, Chrome for iOS can only implement a partial profile separation, which leads to some amount of bleed of data and state between profiles, when, e.g., a site uses localStorage.

Steps to Reproduce:
1. Try to implement multiple profiles in a WKWebView-based browser
2. See state bleed between profiles
Comment 1 Eugene But 2015-01-07 16:02:47 PST
Radar ID: 17580422
Comment 3 Eugene But 2019-11-19 08:31:11 PST
As of iOS13, WKWebsiteDataStore supports multiple non-persistent data stores, but only one persistent data store. Desktop and Android Chrome supports multiple persistent profiles, which is important use case for enterprise. iOS 13 has a nice multi window feature, and it would be great to allow a separate persistent profile in each window.
Comment 4 Maciej Stachowiak 2020-01-06 21:27:15 PST
Comment 5 Stefan Arentz 2020-01-07 18:52:44 PST
To be more concrete: our request is to be able to create multiple persistent WKWebsiteDataStore instances, given a root path or profile name.

All the infrastructure for this seems to be available through the two classes that WKWebsiteDataStore delegates work to:


The configuration maintains many paths to the various databases and cache directories. I think it is fine for that being an internal implementation detail, as long as we can construct a WKWebsiteDataStore with either a root path or profile name.