Bug 140201 - Provide public API to control persistent data in WKWebView
Summary: Provide public API to control persistent data in WKWebView
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: iPhone / iPad All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-01-07 13:51 PST by Eugene But
Modified: 2019-11-19 08:31 PST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.