[Webkit-unassigned] [Bug 98885] New: [GTK] It should be possible to disable favicons in WebKit2 GTK+ API

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 10 04:39:56 PDT 2012


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

           Summary: [GTK] It should be possible to disable favicons in
                    WebKit2 GTK+ API
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: cgarcia at igalia.com
                CC: xan.lopez at gmail.com, gns at gnome.org,
                    msanchez at igalia.com, mrobinson at webkit.org


The current API always uses favicons unconditionally. The thing is that in WebKit2 it's not possible to close the icon database and open it again with a different patch, so we designed the API with that approach. However, I don't why is that limitation but it might change. So the idea was that when you call webkit_web_context_get_favicon_databse(), it's created automatically and, if the favicon database path hasn't been called the default one will be used. WebKitWebView always calls webkit_web_context_get_favicon_databse() to implement the favicon property, so we always end up with a favicon database. The idea was that if apps are not interested in favicons, thay can simply ignore the favicon property of the web view, but the thing is that favicons cause an overload and other side effects (like having one subresource more loaded) that could be avoided if the app is not interested in the favicons. 

So, I think we should switch to an API were the user has to explicitly enable the favicon database, but that would allow us to implement reopne if it's eventually supported. So I think we could do something like this:

We keep the methods to set/get the favicons directory path:

void webkit_web_context_set_favicon_database_directory()

When it receives NULL the default database path will be used. This creates the favicon database if needed and sets the path. If the database is open it does nothing.

gchar *webkit_web_context_get_favicon_database_directory()

Returns NULL unless webkit_web_context_set_favicon_database_directory has been called.

WebKitFaviconDatabase *webkit_web_context_get_favicon_database()

Creates the favicon database if it doesn't exist, but it doesn't set the path.

So, to enable the favicons, the user needs to call webkit_web_context_set_favicon_database_directory(). If it hans't been called, web view will use the database, that will return WEBKIT_FAVICON_DATABASE_ERROR_NOT_INITIALIZED every time it's asked for the favicon. This way the favicon database will never emit the favicon-changed signal and web view won't emit notify::favicon. In the worst case we have a WebKitFaviconDatabase object that does nothing but we don't need special case when the database is not open, and the web view code will be the same.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list