Using a link tag to specify a favicon different from /favicon.ico fails to render in the address bar. At least, it does so for a multi-icon set (containing 1, 4, 8, and 32-bit icons). Safari favors the 4-bit icon in the multi-res set. Ideally, Webkit would favor the 32-bit icon. Bug present in latest nightly as of this report.
I think the bug here isn't that we fail to respect the linked icon, or that we "prefer the 4-bit version" -
I believe the bug here is that we grab frame 0 from the image - or the first indexed icon from the icon set - and its the wrong one!
I think we have a radar for this but it's been low priority as we haven't seen this reported in the wild yet.
Lemme see if I can find the radar and/or file one.
I will bump this up a notch on the priority list.
But a warning! The algorithm won't be "choose the deepest icon" - it will be "choose the deepest icon of the correct size or, if none is found, choose the deepest icon of the incorrect size" as that is what we did in the previous WebIconDatabase
Sorry bout the double post - no clue how that happened... lame!
*** Bug 12002 has been marked as a duplicate of this bug. ***
(In reply to comment #5)
> *** Bug 12002 has been marked as a duplicate of this bug. ***
Interesting note from Bug 12002 Comment #0:
Code in WebKit/DOM/WebDOMOperations.m for DOMHTMLLinkElement leads me to
believe that this icon is expected to be loaded (or was loaded at one time)
since saving a WebArchive uses this code path and will try to save the icon to
the WebArchive file (and fail).
It's too bad Bug 11882 hasn't landed yet, or you could write a webarchive test for this.
Both of the issues in this report (sorry about that) appear to be resolved; work as expected for me in both Safari 3 and today's Webkit on Leopard.
Marking as RESOLVED/FIXED per Comment #7 and Radar.