[webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

Michael Catanzaro mcatanzaro at igalia.com
Thu Jun 15 19:27:46 PDT 2017


On Thu, Jun 15, 2017 at 7:11 PM, Brady Eidson <beidson at apple.com> wrote:
> Hi all,
> 
> The IconDatabase in WebCore is the source of crashes, spins, and 
> complexity.

Yup. It's very unreliable for GTK. It's the source of 
difficult-to-understand memory leaks, difficult-to-reproduce crashes, 
and, more commonly, garbled or gibberish icons. I'm guessing a thread 
safety issue we haven't been able to figure out.

> Starting in on this task, I of course noticed GTK’s API has exposed 
> “WebKitFaviconDatabase”
> 
> Is that something that’s published API and that is used?
> If not, I can get rid of it right now

Yes it's published API, and yes we need to keep it working.

> If so, then I need a GTK maintainer to come up with a plan soon.
> 
> The icon load delegate mechanism is powerful enough to rebuild an 
> IconDatabase on top of, so if GTK needs to keep this API functional 
> they can do so - maintaining the actual IconDatabase code themselves 
> up in their API layer.

I haven't looked at this closely, but I strongly suspect we could 
reimplement the WebKitFaviconDatabase API on top of your icon load 
delegate mechanism like you suggest. It's probably going to be better 
for us in the long run anyway, because our current code is just not 
reliable.

> On Thu, Jun 15, 2017 at 7:27 PM, Maciej Stachowiak <mjs at apple.com> 
> wrote:
> This is slightly tangential, but a comment on the model: it doesn't 
> seem like there's a way for clients to check what range of icons are 
> available and only then choose which to load. Even though Safari may 
> not have needed this to move over, if you wanted to do something 
> rigorous like load the closest available size to what you need or 
> else a scalable format, there's no way to do that without potentially 
> loading icons you don't need. While Safari hasn't done this, it might 
> be useful if Safari's various places that display icons are ever made 
> more consistent and coherent.

Something like this could be useful for Epiphany, where I think we just 
want a couple specific icon sizes.

One issue we've noticed is there are many different nonstandard ways 
that websites use to find icons. [1] details many of these: the 
Microsoft way, the Apple way, the OpenGraph way... and even then the 
icons can be put in different places... is this the problem Brady's 
code is designed to solve?

Michael

[1] https://ctrl.blog/entry/gnome-web-app-icons



More information about the webkit-dev mailing list