[Webkit-unassigned] [Bug 217034] [GTK] Stop using the default website data store for the inspector

[bugzilla-daemon at webkit.org]

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

--- Comment #3 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #2)
> Comment on attachment 409829 [details]
> Patch
> 
> Questions:
> 
>  *Each inspector is 1:1 associated with a web view. Why doesn't the
> inspector use that view's data store?

The inspector doesn't use the same process pool as the web view, so it uses its own network process. If the web view is ephemeral we still want to save inspector settings. We have always saved the inspector settings globally, and not per application.

>  * Why is it better to create a custom data store using default paths than
> to just use the default data store?

Using the default data store is problematic for GLib API, we end up writing stuff globally, instead of per application, which is not desired in most of the cases. We can't probably change the default locations of website data store, for backwards compatibility reasons, note that these paths are versioned too, not the same as the default ones. After this patch users will lose the inspector settings.

>  * Why does GTK need this but not WPE?

WPE doesn't have WebInspectorProxy, because only the remote inspector is supported in WPE.

>  * Don't applications use the default data store *by default*? What's wrong
> with this?

No, applications use a WebKitWebsiteDataManager that creates a website data store with the default session ID, which is different. The GLib API doesn't use the default data store, but there are places like the inspector where it's created internally.

>  * If GTK port should never use the default data store, shouldn't we have an
> ASSERT to ensure it doesn't get created?

That's the plan, but I need to fix the cases where it's used first. I caught this thanks to the assert I added in patch atached to bug #216041

-- 
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/20200928/2392dcc5/attachment.htm>