NEW190335
[GTK] WebKitGTK should always propose the best favicon 
https://bugs.webkit.org/show_bug.cgi?id=190335
Summary [GTK] WebKitGTK should always propose the best favicon
Cédric Bellegarde
Reported 2018-10-07 04:46:34 PDT
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
Attachments
Add attachment proposed patch, testcase, etc.
Carlos Garcia Campos
Comment 1 2018-11-09 03:56:37 PST
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.
Michael Catanzaro
Comment 2 2018-11-09 06:55:57 PST
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.
Carlos Garcia Campos
Comment 3 2018-11-09 08:11:59 PST
Again, we don't know when we are done.
Michael Catanzaro
Comment 4 2018-11-09 11:33:16 PST
Isn't it done at load-finished time?
Carlos Garcia Campos
Comment 5 2018-11-12 00:36:39 PST
I don't think so.
Adrian Perez
Comment 6 2026-03-20 03:02:50 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.