Bug 222999 – Need to rationalize preference like settings on the WKWebViewConfiguration that use the WebPreferences infrastructure

• Status: NEW
• Component: WebKit2

[Sam Weinig]

There is an issue with all the preference like settings on the WKWebViewConfiguration that use the WebPreferences infrastructure to communicate their state. The issue stems from the configuration values updating the value of the shared WebPreferences object, when their intention was really only to affect the one WKWebView they were being used with. As an example:

    WKWebViewConfiguration *configurationA = [[WKWebViewConfiguration alloc] init];
    configuration._colorFilterEnabled = NO;

    WKWebView *webViewA = [[WKWebView alloc] initWithFrame:NSMakeRect(0, 0, 100, 100) configuration:configuration];
    
    // At this point, color filter is disable for webViewA.
    
    WKWebViewConfiguration *configurationCopy = webViewA.configuration;
    configurationCopy._colorFilterEnabled = YES;

    WKWebView *webViewB = [[WKWebView alloc] initWithFrame:NSMakeRect(0, 0, 100, 100) configuration:configurationCopy];

    // At this point, color filter is now enabled for webViewA and webViewB.

I think we need to stop updating the shared preferences entirely from [WKWebView _setupPageConfiguration:] and treat each configuration value as immutable for that WKWebView. This will require a bit of reworking.

[Sam Weinig]

There are really two problems here.

1) Configuration values can contaminate shared preferences.
2) The semantics of preferences that are exposed both as a configuration property and preferences property are unclear.

Not sure if they can be fixed independently yet.

[Sam Weinig]

Created attachment 422769 [details]
Analysis of the calls in _setupPageConfiguration:

[Radar WebKit Bug Importer]

<rdar://problem/75499036>