[Webkit-unassigned] [Bug 167414] [GTK] Icon Database should be in private browsing mode for ephemeral web views

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #3)
> Comment on attachment 299687 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=299687&action=review
> 
> Exactly the sort of thing I was worried about with allowing a per-view
> ephemeral setting... will there be more?

This is not because we allow per-webview ephemeral setting, but because the icon database works only with the legacy private browsing setting.

> > Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:785
> > +        // We notify the context here to ensure it's called only once. Ideally we should
> > +        // call this in finalize, not dispose, but finalize is used internally and we don't
> > +        // have access to the instance pointer from the private struct destructor.
> > +        webkitWebContextWebViewDestroyed(webView->priv->context.get(), webView);
> 
> I don't understand this. Of course you can move the call to
> webkitWebContextWebViewDestroyed finalize? Why not? What do you mean it's
> used internally?

Finalize is defined by WEBKIT_DEFINE_TYPE. So when we want to do something on finalize we use the private instance constructor, but that approach doesn't work when you also need access to the pointer of the object instance.

> > Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestWebKitFaviconDatabase.cpp:163
> > +static void testPrivateBrowsing(FaviconDatabaseTest* test)
> 
> Shouldn't you add a test for an ephemeral web context as well?

It's the same thing, as I said this is not happening because of per-webview setting. An ephemeral context simply creates ephemeral web views.

> > Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestWebKitFaviconDatabase.cpp:173
> > +    // An ephemeral web view should nto write to the database.
> 
> nto -> not

Oops.

-- 
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/20170125/477e325a/attachment.html>