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.
Created attachment 122439 [details] test page: links to the icon file, which should be displayed in address bar
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 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.
*** 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
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
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.
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.
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.
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".
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
Last Resolved: 15 years ago → 14 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
Resolution: FIXED → ---
Should be fixed on both branch and trunk.
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago → 14 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.