Bug 190335
| Summary: | [GTK] WebKitGTK should always propose the best favicon | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Cédric Bellegarde <cedric.bellegarde> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bugs-noreply, cgarcia, mcatanzaro |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Cédric Bellegarde
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
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
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
Again, we don't know when we are done.
Michael Catanzaro
Isn't it done at load-finished time?
Carlos Garcia Campos
I don't think so.