[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