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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Aug 15 17:37:10 PDT 2011


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





--- Comment #15 from Rachel Blum <groby at chromium.org>  2011-08-15 17:37:10 PST ---
> 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.

That won't work, unfortunately - the icon type is a bitmask (so you can e.g. get both FavIcon and TouchIcon in one go). That means a varying number of icons are default icons, followed by non-default ones. Since that's an API change, it might break other WebKit users.

I don't disagree that a second API is confounding - but in light of the fact that the old API is brittle *and* that we need backwards compatibility, it seemed best to pick an API that is completely invisible to clients relying on the old API.

> need to study it further to answer your question well

I'll try to give a summary:

Document::setIconURL is extended to keep a list of all icons encountered, in addition to the 3 "default" ones it tracks. (The number of default icons is hard-coded to ICON_COUNT)

IconController::urlsForTypes returns that list of all icons if you pass in AnyIcon. Otherwise, it keeps the old behavior. Combining AnyIcon with the other types as operation does not really make sense, but it probably should result in the same behavior as if only AnyIcon was passed in.

IconController::appendToIconURLs is modified to retrieve the list of all icons kept on the Document if you pass in setIconURL

---- End of summary ---

You are right, there is more code in that patch to actually pass lists of sizes along with IconURLs. That's completely orthogonal to the changes above, so you can probably ignore it. (And if you think the above approach is better, I'll probably try to land that first, and sizes support in a second bug)

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



More information about the webkit-unassigned mailing list