[Webkit-unassigned] [Bug 168230] [GTK] Update cookie manager API to properly work with ephemeral sessions

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Feb 13 18:08:07 PST 2017


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

--- Comment #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Comment on attachment 301345
  --> https://bugs.webkit.org/attachment.cgi?id=301345
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=301345&action=review

>> Source/WebCore/platform/network/soup/CookieJarSoup.cpp:217
>> +        deleteAllCookies(session);
> 
> Are you planning to fix this soon? I don't think we should proceed with these API changes if the API does not work properly. At least add a runtime warning using g_warning().

(Sad OK if you add the g_warning().)

> Source/WebKit2/UIProcess/API/gtk/WebKitCookieManager.cpp:115
> +    if (manager->priv->dataManager) {
> +        g_object_remove_weak_pointer(G_OBJECT(manager->priv->dataManager), reinterpret_cast<void**>(&manager->priv->dataManager));
> +
> +        auto sessionID = webkitWebsiteDataManagerGetDataStore(manager->priv->dataManager).websiteDataStore().sessionID();
> +        for (auto* processPool : webkitWebsiteDataManagerGetProcessPools(manager->priv->dataManager))
> +            processPool->supplement<WebCookieManagerProxy>()->stopObservingCookieChanges(sessionID);
> +
> +        manager->priv->dataManager = nullptr;
> +    }

Actually, I wonder if we should do this in ~_WebKitCookieManagerPrivate() instead of dispose. Because the object should technically be left in valid state after dispose, but all of the functions are going to hit criticals if priv->dataManager is null. Since we're not keeping a strong reference to it, it can't be involved in a reference cycle, so it should be safer to do in the destructor instead of dispose.

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


More information about the webkit-unassigned mailing list