GNOME Bugzilla – Bug 116678
Favicon support
Last modified: 2005-08-31 20:08:39 UTC
I'm sorry if this is an old debate, but I'm finding Epiphany's favicon support rather disappointing after using Mozilla Firebird for some time now. Google.com (Google!), CNN.com, News.com, NBC.com, Fox.com, CBS.com, ABC.com, Blogger.com, Gentoo.org are just a few examples of sites that have favicons and Mozilla Firebird displays them, but Epiphany simply doesn't. Are you guys really that concerned about the impact of Epiphany having on server load? I'm assuming the extra server check for a favicon.ico file is the issue, which I don't understand considering that Epiphany's market share is completely negligble and doesn't promise to change in the near future while Internet Explorer, a browser that has a good chunk of that share, doesn't seem to be very likely to give up on favicon.ico server checks. While in hind site it doesn't look like MS really cared to plan favicons very well, it seems obvious that the damage has been done and some pride needs to be swallowed (not to sound overly harsh...). I've explained this in a separate bug report, but I think favicon support in a browser is extremely helpful when it comes to useability, especially with tabbed browsing support. In a row of plain text tabs, websites are a lot easier to pick out when they have unique icons to separate and identify them. Same with favicons in the titlebar and taskbar for people who have multiple Epiphany windows open. After using Firebird for so long, which seems to load a unique favicon for just about every site out there, I'm finding it rather cumbersome to use Epiphany. And this may be a separate problem, but these sites didn't load any favicon (in titlebar, next to location bar, or tab) until I actually switched to a different tab and then back to theirs or used the back/forward buttons or just refreshed the page: Altavista.com, Linux.com, RedHat.com, Mandrake.com, Foxnews.com If this should go into a separate bug report, please don't hesitate to say so. I'll be more than willing to file another one.
Heh this debate has been done 200 times during galeon development. If we want to go through it again for epiphany, it should probably happen on the mailing lists.
marco, whats the issue here? From a ui perspective i definately agree but...
Basically: - Some people are very sensitive to the problem, probably because they have to read server logs - Some people believe IE spec sucks and it should not be followed. And not following it seem like a good idea to make people use the right spec.
If reading server logs is a problem, can't those people use a tool to parse out the favicons from them? I'd imagine the number of people benefiting from more complete favicon support in Epiphany (read: all Epiphany users) would be more important in this case than the people getting too many favicon requests in their server logs (read: the few server log reading people annoyed by favicon requests who actually get an Epiphany user to view the website they're monitoring.) I really don't think Epiphany has the clout to make people use the right spec just by supporting only the proper favicon spec. The only thing I see happening is developers continuing to use favicons without the LINK tags in their website code because MSIE will still use them while Epiphany users suffer from now seeing all those extra favicons. In my bug report I already gave a list of some major websites (Google!) whose favicons Epiphany is refusing to support. (None of them, as far as I recalll, have a LINK tag for their favicons.) ICO files are a pain in the butt. I think the safest way to make developers switch to the proper spec at this point would be to just support that spec which allows them to use PNG and GIF files for their favicons, along with their own filenaming schemes (MSIE forces people to use "favicon.ico" files an only favicon.ico files). I really think this is a situation where you guys just need to swallow your pride. The Mozilla Gecko developers have already added support for a lot of MSIE's quirks in rendering pages to make that rendering engine more useable. From my experience with Mozilla Firebird, a majority of the major websites out there do have favicons, but unfortunately Epiphany doesn't take advantage of because it's doing things the right way (which I respect, but, again, it isn't likely to effect web developers and just ends up hurting Epiphany users).
And if Epiphany just wants to do things the right way, ignoring current browser market share, in the hopes that Epiphany might eventually be a popular browser some day (sorry if this sounds too harsh... no harm intended), then wouldn't a more reasonable approach be to support MSIE's spec now while it's the dominating browser and web developers are catering to it (and support the proper spec in the mean time so web developers have the option to do it properly, which you already do), deprecate the MSIE spec (by saying this is not the proper way to do it in favicon documentation), and then eventually abandon support for the MSIE spec once Epiphany is more popular? Or maybe this should be the collective policy for all MSIE-alternative browsers out there.
NOTABUG. Justification in this mailing list thread: http://mail.gnome.org/archives/epiphany-list/2003-December/msg00053.html
All of the arguments I've seen in this matter /favicon.ico behavior seem to be from a web server's point of view... Could this possibly by looked at from a user's point of view? In epiphany, favicons play a much greater role than with other browsers, since they're used to identify windows as well as tabs. The more favicons that can be acquired, the more visual distinction there can be between tabs and windows, and sites that use the meta tags properly still seem to be a very small minority. Epiphany's icon behavior as is is very polite, and I don't think following the de facto standard rather than the de jure one will cause a lot of harm.
And it's not like Epiphany is not showing the icon for some rare websites. It's not displaying them for *Google*, one of the websites Epiphany is probably most often used for. Server administrators could easily take care of 404 logs by fishing out requests for favicons if they're so concerned. Some other sites since I originally made this post that have favicons Firefox supports, but Epiphany doesn't: http://www.nytimes.com http://www.cbsnews.com http://www.washingtonpost.com http://www.cnn.com http://www.reuters.com http://www.apple.com http://www.kottke.org http://dot.kde.org (Hey...) Just browsing through the most commonly visited websites makes Epiphany's icon support look buggy. It's great that Epiphany supports the standard of using meta tags, but if the Mozilla project chose to only support the standards, they wouldn't get to where they are today. You have to support what's out there AND the standards. Give web developers the choice of doing the right thing without making users suffer if they don't. And if anything, can't Epiphany check if there's a metatag for the favicon and make sure it doesn't do a regular request if the tag is there? Maybe we could have a compromise with a gconf key for enabling full favicon support that's disabled by default? *Please*. The unpleasantness of this bug is enough to have made me switch over to Firefox since I originally posted this bug, which although its GTK/GNOME support has gotten better and better, I still would prefer using a full-fledged GNOME application.
chpe, how do you want to move forward on this?
targeting at 1.6 after irc discussion.
Target Milestone: 1.6 -> 1.8
"Maybe we could have a compromise with a gconf key for enabling full favicon support that's disabled by default? *Please*." Very good idea IMHO. I think the "bad way" has to be implemented.
Fixed in cvs.
You can now install the "favicon" extension from Epiphany Extensions to get this behaviour.
*** Bug 314982 has been marked as a duplicate of this bug. ***