[Webkit-unassigned] [Bug 65564] Support for multiple <link rel="icon"> favicon elements.

Mon Aug 15 17:06:04 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=65564

--- Comment #14 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2011-08-15 17:06:04 PST ---
> IconController::urlsForTypes is hard-coded to support exactly three icon types: FavIcon, TouchIcon, TouchPrecomposedIcon. It does not (even though it looks that way) support multiple icons beyond "one of each" for those three. 

I would expect it to be able to return multiple entries for each type.  The first entry of any given type should probably be the preferred, default icon.

> The patch in bug #37674 originally added support for a fourth type, "AnyIcon", which could be used to return a list of all icons. I split that out to keep sizes support separate from multi-icon support, and based on comment #1 here I picked a different approach. That might well have been wrong :)

Comment #1 doesn't seem to take into account the fact that favicon loading in Chromium is done by Chromium and not WebKit.  Chromium just gets the URL of the favicon, and then Chromium loads it externally to WebKit.  (We use webkit_glue::ImageResourceFetcher.)  It might make sense for WebKit to fetch it, but in reality, the favicons are just needed by the browser UI.  That's why we pushed all of the loading responsibility onto the embedder of WebKit.

> If you think the original approach in #37674 would've been better (it's the second patch, if you want to take a look), I'm happy to resurrect that.

I'm not sure.  That patch seems to have a lot to do with tracking icon sizes too.  I need to study it further to answer your question well.

It just seems fairly confusing to add a redundant sounding API for getting favicon information.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.