Summary: | WKWebViewConfiguration should provide public API to enable private browsing | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eugene But <eugenebut> | ||||
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | andersca, ap, bdakin, dieter, sam, stuartmorgan | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | iPhone / iPad | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Eugene But
2015-01-07 13:24:23 PST
Radar ID: 17238307 Created attachment 244524 [details]
Patch
Comment on attachment 244524 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=244524&action=review Sorry, meant to r-! The name _privateBrowsingEnabled is not good. > Tools/MiniBrowser/mac/AppDelegate.m:-106 > - privateConfiguraton._websiteDataStore = [_WKWebsiteDataStore nonPersistentDataStore]; Why is the removed? Comment on attachment 244524 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=244524&action=review >> Tools/MiniBrowser/mac/AppDelegate.m:-106 >> - privateConfiguraton._websiteDataStore = [_WKWebsiteDataStore nonPersistentDataStore]; > > Why is the removed? privateConfiguraton._privateBrowsingEnabled = YES; code will substitute internal data store with nonPersistentDataStore. So this change should have no functional effect. >>> The name _privateBrowsingEnabled is not good.
The name follows the same patten as [WKWebViewConfiguration _featureCounterEnabled]. Please let me know if you don't like presence of leading underscore or using "privateBrowsing" term? Would appreciate if you can suggest a name which is better from your perspective.
Instead of using a property, I think the direction we will be going is exposing WKWebsiteDataStore as API and allowing setting a non persistent data store on the configuration. Thank you for reply. In case if there already exists a private API which solves the problem, would it be useful to submit a patch which makes that API public? (In reply to comment #7) > Thank you for reply. In case if there already exists a private API which > solves the problem, would it be useful to submit a patch which makes that > API public? No, we will make it public when we feel it is ready from prime time. No need for a patch. This has been done now. |