530249 - Pages that supply multiple favicons in multiple LINK elements have inconsistent site icon display

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Location Bar & Autocomplete, defect)

Description

[Chris Lawson (gone)]

Inspired by the mysteriously changing Google Reader favicons...

STR:

1) Visit http://ballcocknuts.com/ .
2) Click on "Google Reader-like test page".
3) Observe favicon in location bar and/or on tab.
4) Reload page, continuing to observe favicons.
5) Go back and then forward, continuing to observe favicons.
6) Reload just for kicks, still observing favicons.

ER: Be bored silly because everything looks the same.

AR: Be fascinated by the changing favicons.

I haven't quite figured out the logic for what's shown when, but there are three favicons specified in four different <LINK> elements on that testcase page, and we manage to cycle through all three of them at one point or another. There's a 16x16px href'd favicon.ico version that contains only the number 1, a 32x32 href'd PNG that contains only the number 3, and a 64x64 href'd PNG that contains only the number 6.

Minefield and Safari 4 both only ever show the 16x16 version.

cc'ing hendy, since he fixed bug 463725 which may be somewhat related, and smfr, since he wrote most of the rest of our favicon code.

Comment 1

[Chris Lawson (gone)]

I'm not clear from reading through the code whether a "favicon with multiple
members" is strictly a .ico file that has multiple sizes in one file, or if
we're somehow compositing multiple linked favicons into one NSImage with
several representations.

However, I think the solution here is probably to define a hierarchy for
multiple favicon definitions. Both Safari and Minefield seem to prefer
<URI/favicon.ico> over anything else, and that makes sense to me, but beyond
that (say, the testcase above but without the favicon.ico <link>s) maybe we
want to fall back on the logic we used in bug 463725:

if (a 16x16 version exists)
  use it

else if (any versions larger-than-16x16 exist)
  scale the smallest of those down to 16x16 and use it

else if (only smaller exists)
  ignore it
  [and possibly fall back on siteroot.tld/favicon.ico]

If it turns out the above is terribly complicated for some reason, it might be
easier just to use the first <link rel="icon"> or <link rel="shortcut icon"> we
come across and ignore subsequent icons.

Philippe, since you've cc'd yourself here...do you know if there's anything like a "standard" out there for how site authors are supposed to handle this, or expect this to be handled? For instance, why would Google bother providing 32x32 and 64x64 PNG images if browsers are simply going to ignore them and use the favicon.ico file anyway?

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

See also bug 299270.

favicon.ico should be the last resort, not the first (otherwise why even bother specifying <link> icons at all as an author, and instead as a browser let all of the pages on shared servers on the internet have the site icon of the root of the server :P). For multiple <link>s, I think that logic dictates we should use the last <link>ed icon, just as subsequent style sheets override each other (and only if there's none, fetch favicon.ico).

However, if we're going to rewrite the logic, we need to take all of the related bugs into account (e.g. bug 299270, bug 487733, bug 425878, bug 398924, bug 467370, bug 414272, and bug 487733).

Comment 3

[philippe (part-time)]

As far as 'standards' go in this case, this part of the HTML5 draft -6.12.3.7 Link type "icon"- is probably the way to go:
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#rel-icon

[quote]
If there are multiple equally appropriate icons, user agents must use the last one declared in tree order.
[/quote]

The various 'sizes' icons specified by Google is something introduced by the iPhone, iirc. (I had never seen it actually used).

For Camino, if you're given the choice, prefer the 32x32 icon if available, otherwise take the last on in the list.

The section on the link element maybe helpful (4.2.4 The link element):
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-link-element

Comment 4

[philippe (part-time)]

(In reply to comment #3)

> 
> For Camino, if you're given the choice, prefer the 32x32 icon if available,
> otherwise take the last on in the list.

s/32x32/16x16 I guess...

Also, if you're doing any heuristics, the 'shortcut' value in the rel attribute can be ignored, but 'icon' is valid.
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#linkTypes

Comment 5

[philippe (part-time)]

I've uploaded some more testcases along with results in various browsers.
http://dev.l-c-n.com/camino/b530249-favicons/

Summary: slightly messy, but in general browsers display the last listed icon. The 'sizes' attribute is not implemented/ignored.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

If you make a testcase that involves sub-resource loads (bug 434266, but automated rather than manually triggered), could we have continually rotating site icons? :P

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

hicksdesign triggers this now:

<!-- Large favicon for Opera Speed Dial -->
<link rel="icon" type="image/png" href="/icon-195px.png">

<!-- Favicon -->
<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" />

We end up showing a scaled-down-to-16px "1-bit" copy of the 195px Speed Dial icon in the location bar, the tab bar, the bookmark bar, and the bookmarks manager *but* the color 16px favicon.ico in the History menu and the History manager :P  (And, once visiting the History manager, you can sometimes trigger the location bar/tab bar/bookmark bar icon to change from "1-bit" to color :P )

It sounds like we need to implement icon selection along the lines of what philippe and I suggested in comment 2 et seq.

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

It doesn't look like we have anything set up to deal specifically with the case of a site with multiple <link> icons, but in theory whichever <link rel="shortcut icon"> / <link rel="icon"> last triggers BrowserWrapper's |onFoundShortcutIcon:| should be the one used.  You'd think that'd always be the last icon <link> in a page :P but maybe Gecko handles different rel-types in different order.

I have a feeling this bug is going to be major surgery on the site icon infrastructure, but we'd need some good logging to tell.  My partial logging patch and additional suggested methods over in bug 299270 comment 16 probably will be good enough to get you started…

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Daring Fireball triggers this now, too; we end up cycling through:

1) /favicon.ico (automatic load)
2) <link rel="icon" type="image/png" href="/graphics/favicon.png" /> (32x32)
3) <link rel="shortcut icon" href="/favicon.ico" />

and show one or the other.

(In reply to comment #8)
> I have a feeling this bug is going to be major surgery on the site icon
> infrastructure, but we'd need some good logging to tell.

Being, roughly, setting up a dictionary of known icons for a site on load and indicating which one is preferred after examining all choices, then always using that until the dictionary expires.

So the flow would be something like:

Initial load (if !dictionary):
1) /favicon.ico (if present)
2) each <link rel="shortcut icon"> / <link rel="icon">, in order
3) <set up the dictionary from 1 and all the items in 2>
4) Best fit from dictionary

Subsequent loads (if dictionary):
1) Best fit from dictionary
2) Compare all icon URLs to those in the dictionary
3) If any URLs have changed, expire the dictionary and re-determine best fit
4) New best fit

We'd probably want to expire the dictionary after a certain amount of time, too, so we don't retain a mass of dictionaries for sites you never re-visit.