[Webkit-unassigned] [Bug 175265] [GTK] webkit_cookie_manager_delete_all_cookies doesn't delete the cookies before returning

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Aug 10 03:46:11 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=175265

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |achristensen at apple.com,
                   |                            |beidson at apple.com

--- Comment #5 from Carlos Garcia Campos <cgarcia at igalia.com> ---
The problem is that we are not deleting the cookies at all. This is what happens:

1- We create our WebKitWebContext that creates its WebProcessPool
2- We set a persistent cookies storage so a new network process is spawned for the process pool.
3- We ask the website data store to delete all cookies, but since website data store is a web process observer and we haven't spwaned any web process yet, it creates a new WebProcessPool with the default configuration (no persistent cookies) and sends the message to delete the cookies there.
4- The network process of the second process pool does nothing because it doesn't have cookies at all.

I don't know why website data store only uses process pools that already have a web process launched, Brady, Alex, any idea?

I know Apple fixed this by adding WebsiteDataStore::processPoolForCookieStorageOperations() that doesn't create a process pool if there isn't one with a web process launched, and returns nullptr in that case. Then the website data store saves the pending cookie operations, so that when the new process pool is created from the website data store, the pending cookies are sent to the newly created network process as parameters of the message AddWebsiteDataStore. We could try something similar, but I still don't understand why we want to create a secondary network process when we already have one running that is configured.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170810/13c57f19/attachment.html>


More information about the webkit-unassigned mailing list