It should be similar to the WebKit1 cookieStorageAcceptPolicy/setCookieStorageAcceptPolicy. <rdar://problem/8750856>
It doesn't have to be a preference. It should probably be done on the WKCookieManager instead.
Created attachment 86784 [details] Patch (Part 1) - Getting and setting the policy in WebKit2
Comment on attachment 86784 [details] Patch (Part 1) - Getting and setting the policy in WebKit2 I’m not sure WebCore should be involved so much here. It’s right to have WebKit2 send the cookie acceptance policy from the UI to the Web process, but I’m not sure we need the platform layer inside WebCore involved in communicating this to the networking code in a platform-independent way. It seems to me that WebKit2 code can directly call setHTTPCookieAcceptPolicyOnAllCookieStorages for the CFNetwork case and we need not introduce this concept for all the other networking layers unless there really is a cross-platform need for this.
(In reply to comment #3) > (From update of attachment 86784 [details]) > I’m not sure WebCore should be involved so much here. It’s right to have WebKit2 send the cookie acceptance policy from the UI to the Web process, but I’m not sure we need the platform layer inside WebCore involved in communicating this to the networking code in a platform-independent way. > > It seems to me that WebKit2 code can directly call setHTTPCookieAcceptPolicyOnAllCookieStorages for the CFNetwork case and we need not introduce this concept for all the other networking layers unless there really is a cross-platform need for this. The reason I went with getting and setting the policy in WebCore is that we get the list of hostnames in WebCore that have cookies associated with them and delete cookies associated with specific hostnames in WebCore (necessary for other platforms that still use WebKit1 API). Another minor point is this approach allows for WebCore to keep whether or not Private Browsing is enabled a detail that the WebCookieManager doesn't need to know about. However, I do not have very strong feelings on this and could be persuaded that keeping as much of it as possible in the WebKit2 layer is the best way to go. One question that I am not quite sure about - as other ports adopt WebKit2, won't they need to introduce this concept for their networking layers anyways since they will have to implement this API?
Comment on attachment 86784 [details] Patch (Part 1) - Getting and setting the policy in WebKit2 I am going to take another pass at this that avoids having to give separate implementations for all of the different platforms when the only implementations that will really be used are the CFNetwork and Mac ones.
Created attachment 86947 [details] Patch (Part 1) - Getting and setting the policy in WebKit2 (Take 2)
Comment on attachment 86947 [details] Patch (Part 1) - Getting and setting the policy in WebKit2 (Take 2) Per discussion with Anders on IRC, it would be better to have more of this done entirely in WebKit2 (instead of doing the actual setting and getting in WebCore). I will rework it and send out another patch.
Created attachment 86955 [details] Patch (Part 1) - Getting and setting the policy in WebKit2 (Take 3)
Comment on attachment 86955 [details] Patch (Part 1) - Getting and setting the policy in WebKit2 (Take 3) Committed with a Mac build fix in http://trac.webkit.org/changeset/81980
Created attachment 86978 [details] Patch (Part 2) - Make it possible to specify the initial policy on Windows
Comment on attachment 86978 [details] Patch (Part 2) - Make it possible to specify the initial policy on Windows Committed in http://trac.webkit.org/changeset/81997