I asked Carlos Garcia to enable WebKitFaviconDatabase by default in the new API, since web browsers want favicons. But I think this was a mistake, because WebKitFaviconDatabase does not do anything useful unless your application has code to use it.
I've thought about this, because favicon database now can be null, which maybe it's not the best approach either. You might want to disable favicon loads, but still get favicons from the database, for anything in the browser UI (bookmarks, etc.). So, I can think of different options here: 1.- Leave things as they are but simply change the default value to disabled. 2.- Disable favicon loads per WebView, for example using a new setting, but favicon database can still be used to query favicons. 3.- Disable favicon loads per request, by adding a new signal that would expose IconLoadingClient::getLoadDecisionForIcon(). In this case, favicons database can always be used too. The signal is similar to accept-certificate, where you are supposed to just return TRUE or FALSE. I think we can keep it synchronous too. In case of 2 and 3 if the database is not used by the app and the setting disabled or signal unhandled or returning FALSE, the database is not even created.
I'd prefer 1. > You might want to disable favicon loads, but still get favicons from the database, for anything in the browser UI (bookmarks, etc.). Why?
(In reply to Michael Catanzaro from comment #2) > I'd prefer 1. > > > You might want to disable favicon loads, but still get favicons from the database, for anything in the browser UI (bookmarks, etc.). > > Why? For anything in the browser UI like bookmarks, history, etc. But I guess in the end apps either want favicons for everything or nothing, so maybe 1. is indeed the simplest solution.
Pull request: https://github.com/WebKit/WebKit/pull/9678
Committed 259888@main (ac3878ed7421): <https://commits.webkit.org/259888@main> Reviewed commits have been landed. Closing PR #9678 and removing active labels.