Although Firefox is a great browser that protects users from pop-ups, spyware and should replace IE it does have a big issue.
favicon.ico
Firefox by default wont find favicon.ico by reading a HTML/XHTML document and looking for a <link rel> pointing towards it, instead it will play a guessing game and think that its located in the same folder as the document being requested. The result? My error log files are getting too fucking built up with firefox browsers crawling for a file that isnt there. Now at first thats not a big problem, but when my weekly log files show 250,000 requests average, the 404 error requests for favicon.ico are a bit too much, especially when im checking logs for REAL errors.
So, here is my solution.
The result? Not a significant reduction with user interaction, but it saves site admins like me having to cull out favicon 404 errors. I should not have to have an ico file in EVERY FOLDER, or clean out my error logs constantly as a result of letting firefox users view my sites.
Anyone got thoughts about this? If I get around to it, I may just suggest this to Mozilla or someone who cares.
> Firefox by default wont find favicon.ico by reading a HTML/XHTML document and looking for a <link rel> pointing towards it
Are you sure? I was under the impression that if you have a <link> tag to the favicon, this would be used an no other accesses made. Furthermore, I know the favicon is quite aggressively cached, so that if you change your favicon, it's very hard to get Firefox to reload it - shift-reload won't help, for instance. A cache clear might be required before it reads the new one.
I've heard a lot more complaints about IE looking for favicon files, on the other hand.
Of course, I haven't done any real tests of any of this. Anyone else have some hard information?
>>1
signed. I'm disgusted that the Firefox devs copied IE's behavior and will GET /favicon.ico without being told there is one. I had 1516 requests for favicon.ico on my rinky dink little site by Firefox users last month and I neither have one nor specify anything in <link>. I would expect Firefox will honor a different file if one is specified, but that's no excuse for making an unwarranted request if one isn't.
I rather hate the favicon implementation as a whole.
For the user, how to disable favicons:
about:config
browser.chrome.favicons -> false
For the webmaster:
put a favicon.ico in the / directory and your logs will be clean
For the one behind the stupid idea (not the icon, the seeking instead of using only LINK REL= HREF=):
MS + IE
icons are cached yes, and on bookmarks the icon imagedata itself is part of the URL. Export your bookmarks and look at the "ICONDATA" value. This doesnt solve the problem, it just reduces it somewhat. Firefox also complies to "no-cache" meta tags, which can also be a problem for this issue.
>put a favicon.ico in the / directory and your logs will be clean
INCORRECT~!
Take a look at this line from my error log:
[Sun Jan 30 06:41:57 2005] [error] [client 65.214.#.#] File does not exist: /srv/http/4-ch.net/www/politics/favicon.ico
The browser was trying to reach http://4-ch.net/politics/favicon.ico (404) and not http://4-ch.net/favicon.ico (200). It was also identified as Firefox 1.0, on Windows 2000.
I SHOULD NOT have to shove a single file into every bloody folder just to prevent a browser that shouldn't be doing something from bloating my error logs. That's nearly 60 copies of the same file I have to have.
That does seem like some sort of bug, as there is no reason for this behaviour. It's not copying IE, since IE only looks at the site root, and nobody would be expecting a browser to find a favicon in any old directory.
This appears to be the Bugzilla entry for this, which kind of seems to be filled with zealots and other hotheads, which isn't exactly helping.
> In any case, I've redirected /favicon.ico on the main site to
www.mozilla.com/favicon.ico, as it won't have the negative effect I was afraid it would (I was assuming all those 39,000 /favicon.ico hits I got yesterday would be directed; fortunately, this bug doesn't cause re-tries if Firefox gets the icon).
I'm Anonymous and I approve this solution.
> use a range or set of icons that change depending on what MIME type the content in that tab is
Most of them will be html or xhtml, though. Hmm... for those, you could do something like: use the domain name as a seed to pick a colour. (either choose from a fairly large set of different-coloured icons, or tint a generic icon)
So all pages on a specific domain should have the same coloured icon, and will be more or less distinguishable from whatever else you're viewing. If a site doesn't want to be mud-brown or pink or whatever they can always make a custom one.
I figured that using them by the mime type would be better because it allows users to see what kind of file is open on the specific tab they want to see. Making it use dynamic or random colours could be something as an added bonus. I dont see any gain from using it by default.
>>10
Part of the argument for aggressively using favicons seems to be that they enable the user to easily identify which tabs belong to which website. It was based on that idea.
Mime types could be useful, but I still think people will be viewing more html documents than anything else.
But if the HTML documents have their favicon.ico's linked in them, there is no problem. Browsers should not be attempting to request something without a link inside a document pointing it that way, or unless the user requested it.
Look, its 1 line of code:
<link rel="shortcut icon" href="http://the.url.to/favicon.ico" />This is really two separate issues. Or three, depending on how you count.
First, a bug: Firefox digs around for a favicon even if one is supplied in a <link> tag. That's obviously wrong, but is simple to fix.
Second, an opinion: loading a favicon if none is specified. Some people seem to oppose this on principle, but that seems unnecessarily dogmatic. It may not be in any official standards, but it is a de facto standard, so you might as well do it, because the users benefit.
Third, a bad behabiour: Firefox keeps requesting the favicon on each page hit if one doesn't exist. This is obviously a side effect of the cache implementation: a 404 is not cached. This makes sense for normal pages, but the favicon handling should be changed to rememeber 404s and not keep re-requesting.
An aside; the .ico format sucks. If you're going to use a favicon, use one in a normal image format please.
Nobody said the part after the . has to be an extension
favicon.ico.png with MultiViews = :q:
...what?
No, just favicon.png (or .jpeg or .gif)...
I think using .ico is fine. It's a format that isnt bloated, and for a 16x16 image, serves the purpose well. I think if any other format would be used, GIF would be 2nd place.
Why would you select GIF over PNG?
.png
Obviously to have ANIMATED favicos, like on http://rei-ayanami.net/
.mng
Does anything support mng yet?
>>17: But it's a bitmap format with no compression, and, if I recall correctly, it limits you to only sixteen or so colors...
>>18: Often I'm able to make a smaller GIF than a PNG out of the same image. It might be because PNG is cramming in more metadata, or maybe The GIMP's PNG compressor just sucks.
>>20: That wasn't animated in Safari, but when I tried in Firefox... Good gravy, that's one for the feature request (un-request?) pile.
>>22: I believe Moz used to, but the feature was removed. So, no, no major browser currently does.