Mozilla looks for favicon even if <link> exists.

RESOLVED WORKSFORME

Status

SeaMonkey
UI Design
RESOLVED WORKSFORME
16 years ago
6 years ago

People

(Reporter: Brian 'netdragon' Bober, Assigned: Samir Gehani)

Tracking

(Blocks: 1 bug, {helpwanted})

Trunk
Future
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 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.
To hyatt.
Assignee: asa → hyatt
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

16 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.
Keywords: mozilla0.9.8

Updated

16 years ago
Blocks: 120352

Comment 3

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

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 4

15 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.

Comment 5

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

Comment 6

15 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>
(Reporter)

Comment 7

15 years ago
Removing "mozilla1.8" keyword and replacing with "helpwanted". Modifying 
component to XP APPS.
Assignee: hyatt → sgehani
Status: ASSIGNED → NEW
Component: Browser-General → XP Apps
Keywords: mozilla0.9.8 → helpwanted
QA Contact: doron → paw
(Reporter)

Comment 8

15 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)
(Reporter)

Comment 9

15 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>
*** Bug 204393 has been marked as a duplicate of this bug. ***

Comment 11

14 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
Product: Core → Mozilla Application Suite

Comment 12

13 years ago
I think this has been fixed, hasn't it?
(Reporter)

Comment 13

13 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?

Comment 14

13 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

Comment 15

10 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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME

Comment 16

6 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.

Comment 17

6 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.
You need to log in before you can comment on or make changes to this bug.