Brian 'netdragon' Bober Reporter
	Description • 23 years ago

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.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 23 years ago

To hyatt.

	Dean Tessman
	Comment 2 • 23 years ago

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.

	Aleksey Nogin
	Comment 3 • 23 years ago

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

	James Paige
	Comment 4 • 22 years ago

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.

	Aleksey Nogin
	Comment 5 • 22 years ago

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

	James Paige
	Comment 6 • 22 years ago

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>

	Brian 'netdragon' Bober Reporter
	Comment 7 • 22 years ago

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

	Brian 'netdragon' Bober Reporter
	Comment 8 • 22 years ago

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)

	Brian 'netdragon' Bober Reporter
	Comment 9 • 21 years ago

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>

	Michael Hendy (Hendikins)
	Comment 10 • 21 years ago

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

	Hadrien Nilsson
	Comment 11 • 21 years ago

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

	Michael Newton
	Comment 12 • 20 years ago

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

	Brian 'netdragon' Bober Reporter
	Comment 13 • 20 years ago

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?

	Michael Newton
	Comment 14 • 20 years ago

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

	[:Aleksej]
	Comment 15 • 16 years ago

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.

	Marcelo Bastos
	Comment 16 • 13 years ago

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.

	Philip Chee
	Comment 17 • 13 years ago

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