Summary: | [GTK][WPE] webkit_cookie_manager_delete_all_cookies doesn't delete the cookies if called before a web process is running | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Debarshi Ray <rishi.is> | ||||||||||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||
Severity: | Normal | CC: | achristensen, andersca, annulen, beidson, berto, bugs-noreply, buildbot, cgarcia, gustavo, kling, koivisto, mcatanzaro, tpopela | ||||||||||||
Priority: | P2 | ||||||||||||||
Version: | Other | ||||||||||||||
Hardware: | All | ||||||||||||||
OS: | All | ||||||||||||||
See Also: | https://bugzilla.gnome.org/show_bug.cgi?id=781005 | ||||||||||||||
Attachments: |
|
Description
Debarshi Ray
2017-08-07 09:43:23 PDT
Created attachment 317425 [details]
Reproducer: webkit_cookie_manager_delete_all_cookies doesn't delete the cookies
Created attachment 317427 [details]
Attempted workaround using webkit_website_data_manager_clear
webkit_cookie_manager_delete_all_cookies() has never been sync, it has always sent an async message to the network process to delete the cookies. However, it's expected that a subsequent load always happens after the cookies has been deleted, because the load message is sent after the delete cookies ones. I don't know why this is not happening now with the data manager, though. (In reply to Carlos Garcia Campos from comment #3) > webkit_cookie_manager_delete_all_cookies() has never been sync, it has > always sent an async message to the network process to delete the cookies. > However, it's expected that a subsequent load always happens after the > cookies has been deleted, because the load message is sent after the delete > cookies ones. I don't know why this is not happening now with the data > manager, though. I see. Thanks for looking into it, Carlos. 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. Wow that's way too complicated.... Created attachment 318242 [details]
Patch
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API Comment on attachment 318242 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=318242&action=review > Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:1191 > - return &processPool.websiteDataStore().websiteDataStore() == this; > + return &processPool.websiteDataStore().websiteDataStore() == this || m_associatedProcessPools.contains(&processPool); This is the magic line that makes everything work, right? How does this avoid the network process being unnecessarily spawned? Comment on attachment 318242 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=318242&action=review We need a wk2 owner for this, Alex? >> Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.cpp:1191 >> + return &processPool.websiteDataStore().websiteDataStore() == this || m_associatedProcessPools.contains(&processPool); > > This is the magic line that makes everything work, right? How does this avoid the network process being unnecessarily spawned? It doesn't avoid the network process from being spawnede, it avoids that a new process pool with a default configuration is spawned to do nothing. This ensures that our process pool, already configured, is used and the network process with the right configuration is spawned only if needed, to do the right thing. Hm, I have another question about this. What about bug #169797? It looks like Brady already fixed this in a different way? Perhaps we just need to implement the unimplemented cookie storage functions in NetworkStorageSessionSoup.cpp? (In reply to Michael Catanzaro from comment #11) > Hm, I have another question about this. What about bug #169797? It looks > like Brady already fixed this in a different way? Perhaps we just need to > implement the unimplemented cookie storage functions in > NetworkStorageSessionSoup.cpp? I don't think that "workaround" would fix this issue, it seems to allow setting cookies while the network process hasn't been spawned yet, but not to delete them or any other operation. It doesn't avoid spawning a network process for nothing either. OK. I would ask Brady to do the owner review. Maybe he'll want to update the Mac to take this approach. Comment on attachment 318242 [details]
Patch
If a WebsiteDataStore is going to keep a set of "associated WebProcessPools" like this, then WebProcessPool itself has to do the association in its constructor and destructor. It's folly to mix API objects and IMPL objects like this.
(In reply to Brady Eidson from comment #14) > Comment on attachment 318242 [details] > Patch > > If a WebsiteDataStore is going to keep a set of "associated WebProcessPools" > like this, then WebProcessPool itself has to do the association in its > constructor and destructor. It's folly to mix API objects and IMPL objects > like this. We need to do better about this "web process pool vs website data store" thing in general. This patch is a wallpaper job for one specific API for one specific use case. Created attachment 319250 [details]
Updated patch
This patch moves the process pool tracking from the GLib API to the cross-platform code. This way WebProcessPool and WebPageProxy are the ones adding/removing associated process pools to WebsiteDataStore.
Brady, is this version OK with you? Hi Brady, we need to land a fix for this issue and you didn't like the last version of this patch... can you review the new version please? (In reply to Michael Catanzaro from comment #18) > Hi Brady, we need to land a fix for this issue and you didn't like the last > version of this patch... can you review the new version please? Sure, will look in a bit. Comment on attachment 319250 [details] Updated patch View in context: https://bugs.webkit.org/attachment.cgi?id=319250&action=review > Source/WebKit/ChangeLog:24 > + (API::ProcessPoolConfiguration::copy): Aslo copy the default WebsiteDataStore. Aslo > Source/WebKit/UIProcess/WebsiteData/WebsiteDataStore.h:183 > + Vector<WebProcessPool*> m_associatedProcessPools; This can probably be a Vector<std::reference_wrapper<WebProcessPool>> Comment on attachment 319250 [details] Updated patch View in context: https://bugs.webkit.org/attachment.cgi?id=319250&action=review > Source/WebKit/UIProcess/API/APIProcessPoolConfiguration.h:157 > + RefPtr<WebsiteDataStore> m_defaultWebsiteDataStore; It seems strange to have a member reference to the default website data store. Couldn't defaultWebsiteDataStore be a static method? Comment on attachment 319250 [details] Updated patch View in context: https://bugs.webkit.org/attachment.cgi?id=319250&action=review Note that this patch is obsoleted by https://trac.webkit.org/changeset/221834/webkit, and will need to be rethought. > Source/WebKit/UIProcess/API/APIProcessPoolConfiguration.h:68 > + WebsiteDataStore* defaultWebsiteDataStore() const { return m_defaultWebsiteDataStore.get(); } > + void setDefaultWebsiteDataStore(WebsiteDataStore& websiteDataStore) { m_defaultWebsiteDataStore = &websiteDataStore; } This name is problematic: "default website data store" is already an established concept in the APIWebsiteDataStore API. But also, please note that we need to move *away* from the concept of a process pool having a default datastore and this patch further cements the concept. I'm sorry if I didn't make this explicitly clear in my earlier comment a few weeks ago. It is a problem that we rely on a WebProcessPool having an implicit WebsiteDataStore. It should be a goal to move *away* from that, not further cement it. Is it just a naming issue? WebProcessPool has always a data store, at construction time it creates a legacy one or gets the default one (there's indeed a default one, I'm just allowing the api layer to set it up in my patch). Brady? (In reply to Carlos Garcia Campos from comment #24) > WebProcessPool has always a data store, at > construction time it creates a legacy one or gets the default one I agree that is what exists in the tree today. What I am saying is that this is a mistake and we need to move away from it. If you're insistent that you need to expose this as API, I'm giving you fair warning that future WebKit refactoring patches will break the API and it will be up to you to maintain support at that point up in your API layer. (In reply to Brady Eidson from comment #26) > (In reply to Carlos Garcia Campos from comment #24) > > WebProcessPool has always a data store, at > > construction time it creates a legacy one or gets the default one > > I agree that is what exists in the tree today. > > What I am saying is that this is a mistake and we need to move away from it. Ok, what should we do instead? > If you're insistent that you need to expose this as API, I'm giving you fair > warning that future WebKit refactoring patches will break the API and it > will be up to you to maintain support at that point up in your API layer. I'm not insistent to do this, I'm insistent to fix this bug. If this is not the right way, let's do it right, but I need to know what the right way is. I don't mind doing any refactorings needed. (In reply to Carlos Garcia Campos from comment #27) > (In reply to Brady Eidson from comment #26) > > (In reply to Carlos Garcia Campos from comment #24) > > > WebProcessPool has always a data store, at > > > construction time it creates a legacy one or gets the default one > > > > I agree that is what exists in the tree today. > > > > What I am saying is that this is a mistake and we need to move away from it. > > Ok, what should we do instead? It's already wrong in that web views created from one process pool already can have difference data stores from one another. Additionally, we'll soon be entering a world where one web view might use more than one data store. So, WebProcessPool should not have a data store member. Everything it does that uses the data store member should instead take a data store argument. With those principles in place, recompiling and fixing up call sites, etc etc. Created attachment 327054 [details] New patch In r221834, WebProcessPool::setPrimaryDataStore() was added and the default one is no longer created until the very last moment. Using WebProcessPool::setPrimaryDataStore() when creating the web context fixes this issue. Comment on attachment 327054 [details] New patch View in context: https://bugs.webkit.org/attachment.cgi?id=327054&action=review > Tools/TestWebKitAPI/Tests/WebKitGLib/TestCookieManager.cpp:313 > + // Changed signal is emittend for every deleted cookie, twice in this case. emitted Committed r225043: <https://trac.webkit.org/changeset/225043> Thanks for seeing this through, folks. Much appreciated. |