190335 2018-10-07 04:46:34 -0700 [GTK] WebKitGTK should always propose the best favicon 2026-04-07 04:26:35 -0700 1 1 1 Unclassified WebKit WebKitGTK Other Unspecified Unspecified RESOLVED DUPLICATE 301086 https://bugs.webkit.org/show_bug.cgi?id=301086 P2 Normal --- 1 cedric.bellegarde webkit-unassigned aperez bugs-noreply cgarcia mcatanzaro oldest_to_newest 1466925 0 cedric.bellegarde 2018-10-07 04:46:34 -0700 Currently, it's impossible to get a clean favicon: - WebView fires "notify::favicon" many times in a page with all favicon sizes: sometimes it starts with a small, sometimes it ends with a small... - FaviconDatabase stores random sizes depending on same page reload. Happens with: https://www.archlinux.org/ I think WebKitGTK should first compute all available favicons and: - Fires only one "notify::favicon" with the best one - Stores in DB only the best one 1476848 1 cgarcia 2018-11-09 03:56:37 -0800 I see two problems here. One is deciding which is the the best one, and the other is that we don't know how how many icons the web site is going to provide. So, we could check on every icon received if it's better than the previous one and replace it, for example. We would still emit multiple notify events, though. 1476877 2 mcatanzaro 2018-11-09 06:55:57 -0800 IMO we should freeze notify when processing favicons and only unthaw once we're done. There's no need for client applications to be exposed to multiple favicon changes. 1476908 3 cgarcia 2018-11-09 08:11:59 -0800 Again, we don't know when we are done. 1477013 4 mcatanzaro 2018-11-09 11:33:16 -0800 Isn't it done at load-finished time? 1477497 5 cgarcia 2018-11-12 00:36:39 -0800 I don't think so. 2191995 6 aperez 2026-03-20 03:02:50 -0700 I think this will be fixed by bug #301086 where I am adding new API that will expose all the page icons, so then programs using the API can go through the list and choose the icon(s) which are better suited for their needs. 2197594 7 aperez 2026-04-07 04:26:35 -0700 (In reply to Adrian Perez from comment #6) > I think this will be fixed by bug #301086 where I am adding new API that > will expose all the page icons, so then programs using the API can go > through the list and choose the icon(s) which are better suited for their > needs. The new API from bug #301086 is now in “main” and it allows inspecting all the loaded icons for a page, which means applications can now more feasibly pick whichever icon is better for their needs. I think we can close this =) *** This bug has been marked as a duplicate of bug 301086 ***