[webkit-gtk] New cookies API

Michael Catanzaro mcatanzaro at igalia.com
Thu Feb 9 07:20:21 PST 2017

On Thu, 2017-02-09 at 14:04 +0100, Carlos Garcia Campos wrote:
> So, I think we can deprecate the cookie manager and make the website
> data manager handle the cookies.

I've long been annoyed by the inconsistency between our cookie manager
API and our website data API, so we should definitely do something.
Would be nice to sneak it in for 2.16.

On Thu, 2017-02-09 at 14:04 +0100, Carlos Garcia Campos wrote:
> My first idea was to add everything to the website data manager, but
> we
> might add more cookies API in the future, like the possibility to
> retrieve not only the host with the cookies but also the cookies
> themselves, or to add a particular cookie or a set of them. There's a
> WIP patch in bug #140191 that adds that new API to mac. So, maybe
> it's
> better to have a separate class associated to the website data
> manager.

I would like for Epiphany's cookies dialog to be able to display the
contents of the cookies. Even if it is technical information, it's just
text so it's easy, and it seems to be expected functionality of a
cookies dialog. I don't know if API to add cookies would be useful for
any application, though, and I don't think we should add it unless an
application is planning to use it. It seems mainly useful for
debugging, which sounds like a web inspector feature.

On Thu, 2017-02-09 at 14:04 +0100, Carlos Garcia Campos wrote:
> On the other hand, it could be weird that the API to get the domains
> with cookies, delete and clear cookies is in website data manager and
> any additional api is in a different object. So, I don't know what to
> do.

I would first make WebKitWebsiteDataManager work for cookies the same
as it does for other data, so we have feature parity. Sounds like
that's already implemented internally.

Next, instead of deprecating WebKitCookieManager, I would make it a
property of WebKitWebsiteDataManager so it's still available as a sort
of extension to the WebKitWebsiteDataManager. That seems like the path
of least resistance for both maintaining the existing cookies API, and
for extending WebKitWebsiteDataManager for type-specific information in
the future. I don't think it's weird so long as we maintain the
distinction that WebKitWebsiteDataManager is for operations that are
available for all data types and work the same for all data types (list
domains and delete), and WebKitCookieManager is just for cookie-
specific operations.

Then make webkit_web_context_get_cookie_manager() return the
WebKitCookieManager of its WebKitWebsiteDataManager.

And the webkit_cookie_manager_get_domains_with_cookies,
webkit_cookie_manager_delete_all_cookies() functions could be
deprecated in favor of the WebKitWebsiteDataManager functions.

Note: if webkit_cookie_manager_set_persistent_storage() is not called
then it should default to a location under the base data dir of the
WebKitWebsiteDataManager (for non-ephemeral sessions)!


More information about the webkit-gtk mailing list