To reproduce: 1) Make a new directory in your web server with no favicon 2) Test that it has no favicon in mozilla 3) If it works, add <link rel="shortcut icon" href="link.ico"> (don't use favicon.ico) to web page 4) Test in IE - Bookmark, restart IE 5) If it works then clear your error logs 6) Go to page in mozilla 7) Make sure the icon changed to the one in your <link> in the URL bar 8) check your logs Expected result: No favicon.ico error in logs Real results: Mozilla looked for favicon.ico and didn't find it If someone already has a shortcut icon in their page, Mozilla shouldn't look for favicon.ico. This adds extra stuff to logs and also could be an incentive for sites to use the <link> method.

To hyatt.

Nominating for 0.9.8. This is a bug that we should fix quickly, because one of our claims is that we handle site icon support much better (and less-annoyingly) than IE does.

*** Bug 111901 has been marked as a duplicate of this bug. ***

This has been fixed for quite a while, hasn't it? Mozilla is no longer requesting favicons at all from sites that don't specify an icon in a <link> tag.

It's hidden-pref controlled, so the bug is likely to still be there...

ah, yes. you are absolutely right. When the pref user_pref("browser.chrome.favicons", true); is enabled in prefs.js then Mozilla will request a favicon.ico file even for pages that specificly specify some other icon file with a <link>

Removing "mozilla1.8" keyword and replacing with "helpwanted". Modifying component to XP APPS.

http://lxr.mozilla.org/mozilla1.0/source/xpfe/components/bookmarks/src/nsBookma rksService.cpp#3572 I think this is where it should be modified. (I used Mozilla 1.0 tree since the code won't change in this tree)

This could be an incentive for people to use <link> as a way to clean up their logs if we didn't also perform the aggressive search when <link> exists - bug 110296 is evangelism for <link>

*** Bug 204393 has been marked as a duplicate of this bug. ***

I discovered 404 errors in my logs for favicon.ico though I have this line in my pages : <link rel="icon" type="image/png" href="bookmark-icon.png" /> using Firefox 0.8

I think this has been fixed, hasn't it?

Michael: What gives you the indication this was fixed? Do you have a bug # that indicates it was fixed and have you tested on a recent version of Apache?

Here's what Ethereal said to me when I looked at bonsai with 1.8a6. It came up in conversation on another favicon bug; someone mentioned that it was fixed and sure enough it seems to be. Source Destination Info x.x.x.x 207.126.111.200 GET /cvsqueryform.cgi? HTTP/1.1 207.126.111.200 x.x.x.x HTTP/1.1 200 OK x.x.x.x 207.126.111.200 GET /mozilla-16.png HTTP/1.1 207.126.111.200 x.x.x.x HTTP/1.1 200 OK x.x.x.x 140.211.166.201 GET /images/mozilla-banner.gif HTTP/1.1 140.211.166.201 x.x.x.x HTTP/1.1 200 OK Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050111

Seems to work for me with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.15) Gecko/20080620 SeaMonkey/1.1.10 Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.2pre) Gecko/2008070501 SeaMonkey/2.0a1pre Resolving WFM.

Can this bug be reopened? I notice this behavior in Wikia, for instance -- if browser.chrome.favicons is set to "true," Seamonkey will override the custom site icon with the generic Wikia "W" favicon.ico.

Marcelo Please file a new bug. And does this also happen with Firefox? Also please move discussion to mozilla.dev.apps.seamonkey if possible.