Closed Bug 204393 Opened 22 years ago Closed 20 years ago

favicon.ico given undue preference over link rel="icon"

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: per.angstrom, Assigned: bugzilla)

References

(
URL
)

Details

(Keywords: fixed-aviary1.0)

Attachments

(2 files)

icon file - to be used as link icon
(deleted), image/png
Details
test page: links to the icon file, which should be displayed in address bar
(deleted), text/html
Details 
It seems that Phoenix/Firebird gives preference to "favicon.ico", even when a
web page explicitly designates another icon using the LINK element.

For an example, see <http://susning.nu/>. You will probably see an icon with an
A in the address bar. This is the site's "favicon.ico", although the page
specifies an S icon, using a link element:
<link rel="icon" href="http://aronsson.se/s_logo.png" type="img/png">.

How to reproduce:
1) Go to the URL.

Actual result:
The browser displays the "favicon.ico" icon (A) in the address bar. If you don't
have the site bookmarked, it will probably display the "favicon.ico" icon in the
tab title.

Expected result:
The browser should display the linked icon (S) in the address bar and in the tab
title.

This is 100 % reproducible for me. Seen in recent nightlies, both Windows
(20030504) and Linux (20030429).

See <http://www.mozillazine.org/forums/viewtopic.php?t=9823> for some more
information.
Attached image icon file - to be used as link icon (deleted) — 

    
    

    
  
The testcase I just created doesn't really demonstrate this bug very clearly, as
bugzilla.mozilla.org doesn't have a "favicon.ico". However, it demonstrates that
the browser will lose track of the addres bar icon when the user switches tabs.

    
    

    
  
Confirming.

    
    

    
  
Confirming for real :)

I'm seeing the 'S' icon in the tab and the 'A' icon in the address bar for
susning.nu, though the 'S' icon appears briefly in the address bar before
switching to 'A'. An odd side effect is that it messes up the site icons in the
address bar of other sites in other tabs depending on the order in which I cycle
through the tabs.

This may be a dupe of an existing bug - I seem to recall seeing a bug describing
something like this in the fall.
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
Ok, maybe not the fall, but January this year (it seemed longer ago - honest).

Possible dupe of bug 189847 ?

    
    

    
  
I don't know. Both are related, but this one seems to be about favicon.ico
getting preference over <link rel="icon">.

Both are valid bugs I think.

    
    

    
  
I wrote attachment 94708 [details] [diff] [review] to bug 113202, so I don't see this bug :-)

    
    

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

    
    

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

    
    

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

    
    

    
  
should the "S" icon show up at all since img/png isn't a correct MIME type?
(should be image/png)  We need a better test case.

    
    

    
  

*** This bug has been marked as a duplicate of 116801 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE

    
    

    
  
verified
Status: RESOLVED → VERIFIED

    
    

    
  
I'm considering reopening this bug, given that Firebird and Mozilla don't
exhibit the same behavior regarding the address bar icon: For the example site,
Mozilla displays the "S" icon whereas Firebird displays the "A" icon.

    
    

    
  
Reopening.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---

    
    

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

    
    

    
  
I downloaded the latest nightly this morning and it came up with the right icon
on my website but only at http://zfraction.home.comcast.net (see my duplicate
bug 220605 for old details if you want) however when I hit reload it didn't come
back but when I closed Firebird and opened my website again, it showed up again,
and again went away when I clicked reload. This has not worked at
http://susning.nu as far as I can tell. 
FYI for some reason the latest nightly of Firebird says it is version 0.6.1
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla
Firebird/0.6.1
so I am wondering what is going on there.

    
  
Blocks: 222104

    
    

    
  
Also happens on http://weblogs.mozillazine.org/asa/.  Asa's asterisk appears in
the tab and usually appears in the address bar, but if you switch to another tab
and back, the Mozillazine icon takes over in the address bar.

    
    

    
  
For anyone who's interested, see bug 222602 for a likely related problem.

    
    

    
  
Nominating for Firebird 0.8. This is not a showstopper, but it needs to be dealt
with sooner or later.
Flags: blocking0.8?

    
    

    
  
sooner or later != blocker nominee

there's probably a whole rewrite needed for favicons, so I'd expect this closer
to 1.0
Flags: blocking0.8? → blocking0.8-

    
    

    
  
I really hope for sooner than later because according to a poll on
www.mozillazine.org many more people were looking forward to Firebird 0.7 than
the next Mozilla release.

    
    

    
  
Another example: http://www.rpi.edu/~boberb/seti@rpi/

Notice the tab icon is the right one from the <link> tag, but the URL icon is
the favicon.ico

    
    

    
  
Mike: Couldn't this be done without a total rewrite of the favicon code? I
understand it'd be a hack, but if its a minor hack, then why wait until 1.0 when
its all going to be rewritten anyway? I looked at
http://www.rpi.edu/~boberb/seti@rpi/ in Mozilla Seamonkey and it appears
correctly (unless its open without tabs and you open a new tab). If it looks
right in Seamonkey, couldn't we just do whatever Seamonkey does?

    
    

    
  
because there's no use doing something which is going to be rewritten before
final, unless its a major usability/crasher issue

    
    

    
  
Mike Connor, can you post here an exact URL to that part of code (web-wrapped
from CVS)? I am eager to estimate whether the hack is going to be truly minor.
Though I've no CVS access or even CVS installed, I am probably going to write a
piece of code right here.

And, anyway, bug 204393 --> my votes. Extremely worth voting for, the most
annoying favicon bug IMHO.

    
    

    
  
I have found an HTML work-around.
I put a second link tag in the head.
it now looks something like:

<link href=png-icon.png rel=icon etc.>
<link href=stylesheet etc.>
<link href=png-icon.png rel=icon>

(my page even passes w3c validation still, but it is not how it should work, so
this still needs to be fixed.)

for more spacifics, look at the source of my index page at
http://zfraction.home.comcast.net

    
    

    
  
Doesn't work for me, Zack. I mean, when I enter your site for the first time,
the website icon is "Z", but when I hit any link, then "Back", it's already
Netscape "N" logo on the same page.

I guess bogon emission is too strong here.

    
    

    
  
(In reply to comment #29)
> Doesn't work for me, Zack. I mean, when I enter your site for the first time,
> the website icon is "Z", but when I hit any link, then "Back", it's already
> Netscape "N" logo on the same page.
> 
> I guess bogon emission is too strong here.
I just noticed that I forgot to mention that it requires a refresh after you
visit the page.




    
    

    
  
I recently found this comment in a discussion forum on how to enable favicons
for your site (translated from Swedish):

[blockqoute]
Mozilla-based browsers (Netscape, Firefox, etc.) automatically look for a file
called "favicon.ico" in the root directory. You can't just call it anything or
put it anywhere you like.
[/blockqoute]

So it looks like people have started relying on the buggy behavior. I find it
quite funny that "favicon.ico" is being associated with Mozilla-based browsers,
when it actually was introduced by Internet Explorer.

    
    

    
  
Should it even be requesting /favicon.ico? If there's a standard for specifying
what the icon is, why request /favicon.ico from every site when most don't
provide one? This seems like a wasteful behavior that causes lots of 404s, and I
agree with the last poster that Firefox is perpetuating Microsoft brain damage here.

    
    

    
  
Aaron: You'll have to search the prior bugzilla entries for info about that
kinda thing that was discussed a looooong time ago. The original intention,
iirc, was to do some major evangelism and eventually remove the old way of doing
it when sites converted. The problem is that IE never changed, and our favicon
sniffing code was a lot better so it didn't create the mess IE does. Also, it
was agreed its not too difficult to implement filters for web logs. People also
agreed its best not giving web developers another method to have to do things.
So the intention was to give them both options, but things obviously went wrong
with that as shown by this bug. The other issue is that it was too much work for
some people, it seems, to remember to put that at the top of their pages. They
feel its much simpler to just plop in a favicon.ico. I'd tend to agree unless
you run a content management system like HTML::Mason.

    
    

    
  
there isn't a standard, this is an MS extension to HTML that we co-opted.  Most
sites just dump the favicon in the root directory and be done with it, which
makes this relatively low-priority since few sites actually use this.

    
    

    
  
The reason I see this bug as important (and voted for it) is that if my site's 
URL is www.hosting-provider.com/mysite/, Firefox will display the hosting 
provider's favicon rather than mine. And I can't even override it with link 
rel="icon".

    
    

    
  
blocking1.0 ?
Flags: blocking1.0?

    
    

    
  
I'd like to iterate my support for this being fixed prior to 1.0. 1.0 releases
get more attention than others, and if this isn't fixed by 1.0, people might
consider this behavior a permanent fixture.

    
    

    
  
unless the favicons code that does this lives in /browser or /toolkit, this 
will have to be a low-risk fix or it won't make 1.0.  Did we actually fork 
this?  I doubt it.

This is largely a cosmetic issue that affects a small number of sites, I don't 
think this is critical at all, but a fix would be nice.

    
    

    
  
A majority of people running sites will not agree this is merely a cosmetic
issue, especially when an executive asks the web developer why on Firefox their
company logo doesn't appear on the URL bar. Also, cosmetic issues are the most
noticeable for users.

1.0 should be held back anyway. I believe when you release a major version
number, it should be something of high quality. Firefox is not ready to draw a
lot of attention if it has "cosmetic" issues like this one that could affect how
people design sites in the future. If Firefox had half the market, not fixing
this could cause site administrators to totally agandon favicons. Let's be the
tortouse, not the hare.

    
    

    
  
By the way, with many other projects like Linux, and Gnome currently unstable
(i.e. Linux 2.4 -> 2.6 and selinux), this might not be the best time to release
a new version number as the issues of other projects branching and making major
changes might detract from Firefox 1.0 getting the attention it deserves. I'm
all for fixing bugs like this and holding back the release until later this
year. I just don't see a need to jump right into 1.0.

    
    

    
  
Surely this *is* a low-risk fix, though?

As far as I can tell, from this bug and the related bug 222602, the browser is
getting the correct page icon, but is then drawing over the top of it with
whatever it finds (or doesn't find) at root.

While I know next to nothing about the underlying code, surely it's just a
matter of not searching for, or drawing, a root favicon if it's already found a
suitable one defined by the page?

Maybe it's a lot more complex than it sounds (to an ignorant like me ;), but I
thought it'd be a safe and simple fix.

    
    

    
  
I think the reason they consider it high risk is that since it'd be done on
every page, it could have the potential if written incorrectly for breaking the
browser on every page. I consider that very unlikely because such a thing would
be picked up almost immediately. Its just a matter as I see it, of doing in the
location textbox what is done within the tab.

    
    

    
  
(In reply to comment #38) 
> unless the favicons code that does this lives in /browser or /toolkit, this  
> will have to be a low-risk fix or it won't make 1.0.  Did we actually fork  
> this?  I doubt it. 
 
Mike, 
 
We must have forked it else we wouldn't be getting different behaviour from 
Mozilla (see comment #15). Here's another test case: 
Take a look at http://www.jamesnet.ca/ with Mozilla and with Firefox. Firefox 
shows my poorly converted (black-background) .ico in the url bar and the 
original transparent background .png in the tab bar. Mozilla (and Konqueror 
too) show the .png in both locations. 
 
We may even have some code we can use since the tab bar icons are correct 
whilst the url bar is not...? Or raid Mozilla for the proper code? 
 
Firefox also bookmarks with favicon.ico in preference to <link rel="icon"...>, 
which may or may not be correct/desirable. Konq uses rel, Mozilla doesn't seem 
to use them at all. 

    
    

    
  
First, I seriously doubt that a company with executives would be hosting on
another site so the favicons conflict.  If you can find a company site that has
a domain where this issue exists, please post a link.  Otherwise, you're looking
primarily sites hosted below the domain level (i.e. not even a subdomain like
bugzilla.mozilla.org) where this will really make a difference.  

If you have a top-level site where you have this problem, that's a poor
implementation by the site maintainer.

Second, Firefox will ship this summer, the decision has been made and if you
want to fight that out, this isn't the place.

    
    

    
  
Mike, I agree that this bug should NOT block 1.0. But you seem to be saying 
that if a "company" site were involved, perhaps it should? I'm afraid I don't 
follow this logic at all.

    
    

    
  
if this broke standard implementations for major sites, it would :)  but, it
doesn't.  but I was trying to point out that the argument that a company logo
wouldn't be shown is an invalid example since that becomes a web architecture
issue for the site.

    
    

    
  
What if you had something like this (hypothetical example):

www.adobe.com has one icon... the adobe logo.
www.adobe.com/acrobat has a different adobe acrobat logo.

People who see this behavior in 1.0 will believe that ignoring the <link> tag is
our policy. This might not seem like a big issue, but the whole "embrace and
improve" paradigm is shattered and thrown out the window if this is not fixed.
It was our intention when implementing the favicon code that we do not do the
same annoying behavior that Microsoft does to the chagrin of many a webmaster,
and should we follow their lead by not fixing it? As for this being cosmetic, I
disagree. This is more on the lines of how we render web content as its not
truly part of our AI. Regardless of whether its not a "standard" on the w3c
site, its a de-facto standard. What's worse is we don't even have consistant
behavior with Seamonkey (which has other favicon issues, but at least shows the
right icon in the URL bar).

Mike: Beyond it being forked code, you also said in comment #22 that there is a
whole rewrite probably needed for favicons for 1.0. Perhaps there is a rewrite
necessary, perhaps there isn't, but at least could we deal with the few most
noticeable and pervasive issues with favicons such as this one? It seems that
what Firefox does right, Mozilla does wrong and vice-versa, so you if we combine
the strengths of the two forked favicon codebases, won't we get something that
works properly?
Status: REOPENED → NEW

    
    

    
  
favicons being lost on shutdown is a much bigger issue.  So is improperly
assigning icons to incorrect bookmarks.  This is at best third in that list, and
there's much bigger fish to fry aside from favicons.

a) there isn't a de facto standard for what takes precedence.  In the links I
found on MSDN (i.e.
http://msdn.microsoft.com/workshop/author/dhtml/howto/shortcuticon.asp) the link
rel method is an alternative, not a preferred method.

b) sure, in that hypthetical instance, this bug has merit.  I'm not saying it
doesn't, but I doubt anyone active will make this a priority before 1.0.  I can
count off the actually active Fx hackers on one hand, and unless its low-hanging
fruit with other things, this probably won't happen.

If you feel this strongly about it, ,"we're accepting patches" is still valid.

    
    

    
  
> there isn't a de facto standard for what takes precedence.

I'd disagree. Microsoft's behavior with favicons is so broken they don't factor
into any de-facto standard. With the link http://www.jamesnet.ca/:
Konqueror 3.2.1-15 prefers the <link> over the favicon
Ephiphany 1.1.12 prefers <link> over favicon
Mozilla 1.6 prefers <link> over favicon

You are correct that Internet Explorer prefers the favicon.ico over the <link>
but  we already know that even though IE introduced favicons, their behavior is
broken,  as they do 3 major things wrong:
1) They don't show it until you bookmark the site (and sometimes not even then)
2) They always search for favicon.ico when you bookmark the site, which is a
privacy issue
3) They use <link rel="shortcut icon"> which has a space and spaces aren't
allowed in rel unless it seperates two words

So we decided to embrace and improve, and there was a regression when the code
was from Seamonkey was forked Firefox.

Also, there was an incentive in the way we had decided to do it way back when
this was done, and that incentive was that sites would no longer get the
favicon.ico queries from Mozilla when they use the correct <link> method in
their HTML. IE having something on the order of 97% of the users might make this
moot, and site admins probably just filter out those requests. We also hoped
that Microsoft would follow our lead, but its obvious they don't care enough to
fix broken behavior.

> If you feel this strongly about it, ,"we're accepting patches" is still valid.

I'll start working on one after my final this Monday.

    
    

    
  
I forgot to mention Opera 7 in the list that favors <link> over favicon.ico

    
    

    
  
-ing will take patch
Flags: blocking1.0? → blocking1.0-

    
    

    
  
From: Erik Perrohe  codeslinger at compsalot dot com

More Info/Other Broken Scenario  
FireFox 0.8

When regressing this bug be sure to test the effect of Back/Forward in addition
to Refresh.

Problem: Opening a page for the very first time, will properly display the
specified icon in the url box.

But doing a Back and then Forward will cause the specified icon to disappear(be
overdrawn).  If you watch closly you can see the correct icon being drawen and
then being replaced with the wrong icon.


1) On a site WithOut a favicon in the root folder
2) In a subdirectory of that site  e.g.  www.test.com/trythis/mypage.htm
3) Create a web page as follows

<html>
<head>
<title>Show Me an Icon</title>
<link rel="shortcut icon" href="favicon3.ico">
</head>
<body>
Display an Icon for this page
</body>
</html>

Result: The first time that the page is viewed the icon is displayed correctly
subsequent viewing of the page causes the icon to disappear.

It did not matter what name the icon was given.  But changing the name of the
icon does cause it to reappear (until the next page reload).

    
    

    
  
Yeah, that phenomenon was reported in the related bug 222602 (see especially bug
222602 comment 4). Hopefully the fix for this bug will fix both.

    
    

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

    
    

    
  
Just a note that this issue still haven't been resolved in 0.9 version.

    
    

    
  
This is the same with Firefox 0.9 on our http://www.czilla.cz/ site

Sometimes you can observe http://www.czilla.cz/favicon.ico and sometimes (after
page reload) http://www.czilla.cz/images/mozilla-16.png

From the Apache access log it seems, that the requests to the /favicon.ico are
mainly from Firefox, IE or Netscape, but almost none from the native Mozilla.

    
    

    
  
Favicons have had a low priority (deliberately so, I think) up until now. From
what I understand, the handling of them is going to be heavily rewritten before
1.0 or soon after.

So there really don't need to be any more reports, thanks :) If you're having
the same problem, feel free to vote for this bug, though.

    
    

    
  
Wayne: Excellent to hear because fixing them for 1.0 will probably have the 
highest visibility to people writing sites about favicons.

What I wonder, though, is if within our current timeframe if a total rewrite is 
necessary. Hell, the whole browser code could be rewritten, but there really 
isn't time. Isn't it more prudent just to fix the main issues, especially the 
ones that block our evangalism of <link>?

    
    

    
  
One of the Mozilla staff would have to answer that, but I think it's simply that
any temporary fix would seem a waste when the code is going to be rewritten
anyway. While a temp fix would be nice, there aren't many coders working on
Firefox, so it's understandable if they give it a low priority. Maybe that would
change if 1.0 approaches and they don't have time for a full rewrite. Who knows?


    
    

    
  
The realistic part of me says a rewrite wouldn't make it by 1.0

    
    

    
  
Patch went in on aviary for bug 174265 that should fix this -- favicon.ico is
now always being checked last.
Status: NEW → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → FIXED

    
    

    
  
It does not matter WHEN it is checked; if favicon.ico is still given undue
preference over link rel="icon", this bug should remain open.

    
    

    
  
However (I've just read the patch for bug 174265), additional
(theBrowser.mFavIconURL == null) check will hopefully take undue preference off
/favicon.ico, in favour of <link rel="icon">.

Thank you :-)

    
    

    
  
(In reply to comment #62)
> It does not matter WHEN it is checked; if favicon.ico is still given undue
> preference over link rel="icon", this bug should remain open.


Per?

    
    

    
  
(in reply to comment 64)

Comment 62 is made obsolete by comment 63. Do not take it into account, ok?

    
    

    
  
The fix in bug 174265 still has not landed on trunk. Use the fixed-aviary1.0
keyword for such cases.
Status: RESOLVED → REOPENED
Depends on: 174265
Keywords: fixed-aviary1.0
Resolution: FIXED → ---

    
    

    
  
Should be fixed on both branch and trunk.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED

    
    

    
  
Can Per confirm this? Or what does it take to validate the confirmed status?

    
    

    
  
Confirmed fixed on Mac OS X, 20040730 Firefox/0.9.1+ trunk nightly :)

    
    

    
  
I don't think its completely sorted yet.  I'm using Mozilla/5.0 (X11; U; Linux i686; 
en-US; rv:1.7) Gecko/20040809 Firefox/0.9.3 which I'm guessing should have the 
fix discussed above. 
 
The web server's (non existent) favicon still takes precedence over page favicon 
when I do the following: 
 
(i) visit a page with a favicon on the web server; e.g. 
http://bigred.homelinux.org/go/      favicon appears - all ok so far 
(ii) visit another page on same server that has no favicon; 
http://bigred.homelinux.org/index.html 
(iii) now go back to previous page http://bigred.homelinux.org/go/ - no favicon 
anymore :-( 

    
    

    
  
I can't reproduce your problem, but I'm using a trunk nightly not a branch
build. I'm also not using Linux (tested on Mac OS X and Windows XP, though).

I wonder if someone else using either the 0.9.3 release or Linux, or both, could
confirm this problem still exists.

Are you using any browser extensions, or any themes other than the default? If
so, try disabling them first and see if that fixes it.

    
    

    
  
For the Debian Linux version: Extentions shows nothing loaded, and Theme is
Firefox (default) 2.0 Gerich and Horlander.

I've replicate this behaviour under windows 98 and XP, using:

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

and

Mozilla/5.0 (Windows; U; WindowsNT; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

In both cases the only Extention was one that installs default 'DOM Inspector
1.0' and Theme was 'Firefox (default) 2.0 ...'

I've found another site where I can see this behaviour:
www.bbc.co.uk/radio4/progs/listenagain.shtml - shows radio 4 icon
www.bbc.co.uk/radio4 - no favicon
www.bcc.co.uk/radio4/progs/listenagain.shtml - above favicon disappears

note that restarting firefox reset it so you can repeat the above,
also I'm only talking about the favicon in the address bar.

    
    

    
  
just tried the latest nightly trunk build
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040813 Firefox/0.9.1+
it all works okay with this version.

    
    

    
  
I can also confirm that it's fixed on recent branch nightlies (I just tried
20040813, Mac OS X). I tried the 0.9.3 official release (20040803) that you
used, and it was bugged for me, too, but it's fixed subsequent to that.

    
    

    
  
Re comment #70: I can't reproduce that problem.

Re comment #68: As far as I can see, the bug is fixed. Thanks to everyone who
contributed!

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Firefox/0.9.1+

    
    

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

    
    

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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: