Bug 190335 - [GTK] WebKitGTK should always propose the best favicon
Summary: [GTK] WebKitGTK should always propose the best favicon
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-07 04:46 PDT by Cédric Bellegarde
Modified: 2018-11-12 00:36 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cédric Bellegarde 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
Comment 1 Carlos Garcia Campos 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.
Comment 2 Michael Catanzaro 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.
Comment 3 Carlos Garcia Campos 2018-11-09 08:11:59 PST
Again, we don't know when we are done.
Comment 4 Michael Catanzaro 2018-11-09 11:33:16 PST
Isn't it done at load-finished time?
Comment 5 Carlos Garcia Campos 2018-11-12 00:36:39 PST
I don't think so.