Closed Bug 32087 Opened 25 years ago Closed 23 years ago

[RFE] favicon implementation (customizing bookmark icons)

Categories

(SeaMonkey :: UI Design, enhancement, P3)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: Jos.vandenOever, Assigned: hyatt)

References

(
URL
)

Details

Attachments

(1 file, 5 obsolete files)

Patch that supports <link> and is smarter about not refetching custom icons (either through <link> or favicon.ico).
32.51 KB, patch
andreww
: review+
hewitt
: superreview+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; N; WinNT4.0; en-US; m14)
BuildID:    2000031317

like IE5 mozilla shows icons in the location bar. Why not have this be a user
defined icon like is possible in ie5. and maybe also make the location bar a
list like object where you can choose previous locations

Reproducible: Always
Steps to Reproduce:
1. go to url
2.
3.
Things to bare in mind are:
 * This is a privacy issue -- it lets the site author know if you have 
   bookmarked the site. Thus this should be a pref if we implement it.
 * This should not assume that the icon has a particular name, e.g. favicon.ico.
   Much better would be to only check for the file if the web page includes
   a link to the icon, like this:
     <link rel="icon" href="..." type="image/png">
   This would allow the entire site to automatically be given an icon by using
   HTTP headers -- give the entire site a "Link:" HTTP header and then every
   page automatically has an icon.

This may be a duplicate.
URL: http://www.favicon.com → http://www.favicon.com/
The problem with ms's implementation is that bookmarks/favourites are refreshed
and the icon only appears upon bookmarking.
The icon needn't be loaded only if the page were bookmarked. It can just show
always when the page is loaded and appear in the location bar drop down list
(which isn't there yet)
the icon can be stored in cache and only changed when the page is accessed by
the user. in this way there's no privacy issue.
I agree that implementation of the link feature is better and allows for system
independent icons by specifying the type of file. However most image formats
don't come in a package of 1 16x16 image and 1 32x32 image.

MS' implementation also means servers get hammered with random requests for 
non-existent copies of the file "favicon.ico"...

Anyway, wouldn't this count as an MS proprietary feature, and therefore one we 
aren't going to implement?

Gerv
If it's not desired to add an icon to a web page, then you might as well not put
an icon in the location bar. Is there a function to this icon? In Netscape 4.7
there's no icon in front of the location.
If a larger integration between the desktop and the internet is desired the way
windows, kde and gnome are persueing it, then an icon associeted with a document
is not a silly idea. So implementation of ONLY the <link icon= ... > feature
might be desirable.

We can add helpwanted and see if anyone picks this up but I doubt it.

Adding helpwanted to keyword adn assigning to nobody@mozilla.org
Assignee: cbegle → nobody
Keywords: helpwanted
marking this new, so that it gets out of the unconfirmed list. sorry for the spamm
Status: UNCONFIRMED → NEW
Ever confirmed: true
well, currently the modern skin has a 16x12 pixel bookmark icon, and the 
classic has a 16x16 in the location bar (but the bookmark icons in the sidebar 
are 16x15!)... so even if this were to be implemented (which would be a good 
idea...), the skins would have to be standardized in this respect.

i also modified the summary to be a bit more descriptive.
Summary: feature request: favicon implementation → feature request: favicon implementation (customizing bookmark icons)
*** Bug 51278 has been marked as a duplicate of this bug. ***
This is an interesting feature, and I agree, we should use the <LINK...> method. 
Just a question, since I don't read W3C specs, it's probably not in there, 
correct? And if it isn't, do they accept recommendations? Anyway, back to 
implementation, Hixie suggests the link tag, however I suggest dropping the 
'type' attribute (and have it act like a normal <IMG SRC> tag). Also, is there a 
more than a slim-to-none chance of Mozilla implementing .ico Windows icon files? 
I'm sure web developers would place the tag in there if that's all they had to 
do (not converting their favicon to an actual image).
<link rel="icon" type="image/png" href="/logo.png" />
<link rel="icon" type="image/svg-xml" href="/logo.svg" />
Mozilla could *suggest* to Web authors that if the icon is a bitmap it should be 
supplied as 16*16 or 32*32, but we wouldn't make it compulsory -- if it wasn't 
the right size for the current skin, it would be scaled.

A potential gotcha: let's say MS decides not to implement this ... but on every 
page of every MS-owned site (Hotmail, MSN, MSNBC, Slate, etc), they start putting
<link rel="icon" type="image/png" href="/bloody-huge-randomly-generated.png" />
just to slow Mozilla down. We'd probably want a hard limit on how many kilobytes 
of the icon we read before we said `ok, no more, you've had your little game'.

lol, Microsoft has a little credibility, they wouldn't do that (well, netscape 
engineers are weenies, so let me take that back ;). I don't think this is 
necessary, as the same thing could be done with a javascript detecting Mozilla 
and a document.write with a huge image, if they really have a bone to pick with 
Mozilla. So, in closing, I'd be happy x2 if this gets implemented. That's not 
something that I think warrants the time spent on it.
Interesting.  Glad to finally learn what all these requests for favicon.ico in
my web logs mean :-)

I think supporting the "magic name" favico.ico proprietary feature of MSIE would
be a very bad idea.  However, using the "link" tag would be very good.

About the "DoS" problem, I don't think this is a serious issue.  If someone
wants to make a web page inaccessible or useless or whatever, for a given
browser, he can always find a way.  What happens if I put a huge pr0n file named
favicon.ico for example?

mpt: Microsoft has already implemented this:

  <http://msdn.microsoft.com/workshop/Author/dhtml/howto/ShortcutIcon.asp>

Granted, we don't want Mozilla to automatically look for a "favicon.ico" file
automatically the way IE does, but it seems like wanton incompatibility not to
ape their LINK relationship names here.

The reasons for using rel="icon" instead of Microsoft's rel="shortcut icon" are 
several.
* Specifying a rel attribute consisting of more than one word implies that the
  current document has two equally valid relationships to the linked resource.
  Microsoft has made a mistake here.
* The icon would not be used just for shortcuts, but for bookmarks, the location
  bar, the `Top' icon on the Links Toolbar, Find in Bookmarks search results,
  etc.
* Most crucially, where link rel="shortcut icon" is currently used, it is saved
  as an .ico file, which Mozilla does not (and probably will not ever) recognize.
  So aping their shortcut names would just be a waste of time on both sides,
  because Mozilla doesn't recognize Windows's icon format, while IE doesn't
  recognize anything else.

> Specifying a rel attribute consisting of more than one word implies that the
> current document has two equally valid relationships to the linked resource.
> Microsoft has made a mistake here.

Says who? "alternate stylesheet" doesn't mean that.

> The icon would not be used just for shortcuts, but for bookmarks, the location
> bar, the `Top' icon on the Links Toolbar, Find in Bookmarks search results,
> etc.

What if we decide we want to give Web authors the capability to use different
icons for those display location? I imagine this is exactly the kind of
flexibility MS had in mind when they decided to use the "shortcut" modifier.

> Most crucially, where link rel="shortcut icon" is currently used, it is saved
> as an .ico file, which Mozilla does not (and probably will not ever)
> recognize.

That prediction strikes me as hasty. I doubt it would be very difficult to
support this format, and it would certainly add value to the browser. I perceive
a reasonable possibility that someone could decide to add it.

> So aping their shortcut names would just be a waste of time on both sides,
> because Mozilla doesn't recognize Windows's icon format, while IE doesn't
> recognize anything else.

IE should be smart enough to fail gracefully if it gets a file format it doesn't
recognize. So should Mozilla.

anyone here interested in owning this bug.  I'm trying to clear out nobody's bug
list.  nobody@mozilla.org is overburdened

Braden, "alternate" is only a modifier when applied to "stylesheet" - any other
time it means literally an alternate to the current resource.  Even that usage
may be suspect!  I got smacked about this in discussion on bug 2800 back in late
June.  Take a look at what Hixie and Tim Hill said in reply to my comment.

Also, mpt's latest comment sounds good to me, regarding places this icon could
be used and why it should be rel="icon" rather than "shortcut icon".  IMO the
author's HTML shouldn't be able to start changing parts of the UA interface
willy-nilly.  Using one icon consistently may be a nice convenience and even
useful, but if I saw 5 different widgets simultaneously change into 5 distinct
icons my response as a user would probably be, "Gaaah!  What just invaded my
machine!"

I don't think anyone has suggested this yet (IE does it), but this icon could
also be used when saving to the desktop as a file or link/shortcut.  In the case
of the Mac, perhaps "badged" onto the standard document icon, or however the OS
handles this sort of thing.

As far as what size image to use, anything should work as long as the author
knows it may be scaled, and scaled differently in different widgets and skins.
And as for image type, anything that Mozilla can render should work.  If someone
wants to add support of .ico files, more power to them, and to Mozilla.

Tim: I agree with you about "alternate". I think you have mistaken the context
of my comment. I was simply countering mpt's assertion that "Specifying a rel
attribute consisting of more than one word implies that the current document has
two equally valid relationships to the linked resource," which is simply
incorrect. It is a matter of fact that "alternate" can act as a modifier rather
than as a distinct relationship, and there is no reason that other relationship
type modifiers could not be introduced in the future.

Fact is, Microsoft has introduced "shortcut" as a modifier for "icon", and the
coupling of those two has a de facto standard meaning. I find mpt's objections
to the "shortcut" modifier wholly unconvincing. But I've already countered them
and no one has addressed those arguments.

You say that HTML authors shouldn't be able to arbitarily modify the client UI,
and I agree. Supposing Microsoft or someone introduced additional modifiers to
do that, supporting the "shortcut" modifier by no means implies that we would
have to support those hypothetical additional modifiers as well.

OTOH, you say, "this icon could also be used when saving to the desktop as a
file or link/shortcut." That's entirely possible. But suppose someone wanted to
use a different icon for that than they use for the bookmarks entry? Well, that
kind of situation is exactly what modifiers are for.

Braden, http://www.w3.org/TR/REC-html40/types.html#h-6.12 nowhere states or
implies that such a behavior for "alternate" links is required.  There _may_ be
room for that interpretation, but the counter argument, IMO, has more merit.
The description for the "alternate" type itself says that it "designates
substitute versions for the document in which the link occurs" and goes on to
explain how it can be used for alternate language/media versions of the same
page.  The only place you see "alternate" used as a modifier is in the
description for "stylesheet".  This seems to be the exception, not the rule.
"In the DTD, %LinkTypes refers to a space-separated list of link types."  So
multiple link types are permitted - how do you disambiguate modifiers from
multiple distinct types?  Is it a "shortcut" and an "icon" or is it a "shortcut
icon"?

IMO it was a mistake to use "alternate" as a modifier; "alt-stylesheet" or
similar should have been used instead.  And in this case, if you want different
types of icons, create a new link type:  icon, shortcut-icon, desktop-icon, etc.
 Modifiers only create ambiguity - the spec does not address them in any general
sense.  How do we know how they should be handled?

De facto standards are not a spec.  We can get the same functionality as MSIE by
just supporting the "icon" type.  IE uses the same icon in all the locations,
essentially ignoring any modification that "shortcut" might have done.  I agree
with mpt, MS basically bolluxed here.

Some more information about Microsoft's favicon.ico implementation:

According to <http://www.microsoft.com/TechNet/iis/mimeiis.asp> the MIME-Type
is 'image/x-icon' for all Windows-icons (ending: '.ico').

There is a severe security issue with invalid favicon.ico files at least in IE5:
<http://web.cip.com.br/flaviovs/sec/favicon/index.html>

You may find some more links on the topic at
<http://www.bjoernsworld.de/ie/favicon.html>
(website in German language, but most links to English pages)




Another information:

Something similar was allready part of the HTML 3.0 working draft.
<http://www.w3.org/MarkUp/html3/dochead.html#banners>

I think making Mozilla's icon implementation something betwheen Microsoft's
bookmark icon
<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon"> and this old
banner idea
<link rel="icon" href="img/big-banner.png" type="image/png"> might be a good idea.
Adding [RFE] to Summary.
Summary: feature request: favicon implementation (customizing bookmark icons) → [RFE] favicon implementation (customizing bookmark icons)
It seems concensus here and NG discussions on this issue is that LINK is the 
preferred way to implement this feature.  That way the file is only requested if 
the author specifies it to be.

Hixie: You made a comment that this could be specified in HTTP headers for an 
entire site.  This would be very convenient, since authors wouldn't have to 
remember to put the same LINK in every page.  However, I don't see that "Link" 
is a valid HTTP header, as you seem to suggest. I'm not very knowledgable about 
the protocol...does it allow arbitrary headers?  I've seen META tags that try to 
mimic headers, but not headers that try to mimic HTML.

Dan Nunn: I disagree on dropping the "type" attribute from the LINK.  It's not a 
required attribute, but can help if provided.  Note that the IMG tag is a rather 
broken implementation of including other media inline.  OBJECT is probably a 
better design.

I agree that putting some sort of size limitation on the image file is probably 
a good idea, if only to guard against newbies that don't understand bandwidth 
issues.  I think 5kB is reasonable; it's only supposed to be an icon after all. 
Regarding physical dimensions and justin's skin concerns, would it be possible 
to scale the image as appropriate to wherever it's being used?

If these icons are to be used for bookmarks, should the image files be stored 
somewhere other than the normal cache?  We don't want to have to refetch them 
every few days when they expire just to build the UI.  Perhaps when the bookmark 
is visited, the icon could be refreshed.  (The file may have changed, or the 
site may be pointing to a different file.)  I believe that's what Jos suggested.

I'm going to try to set up a build environment.  If I can get Moz to build, I 
might try giving this a shot.  An out-of-the-way non-critical bug like this 
seems a good place to start at.  I'm going to be moving soon though, so this may 
not be real soon.
tim: See bug 3248. The 'Link' header was present in RFC 2068 [1], and 
subsequently removed from later drafts due to lack of implementations. We now
implement it.

[1] http://www.cis.ohio-state.edu/htbin/rfc/rfc2068.html
Asa: Assign to me. I may eventually be able to add support for this.
-> boberb@rpi.edu
Assignee: nobody → boberb
Depends on: 18502
*** Bug 77429 has been marked as a duplicate of this bug. ***
Component: Browser-General → XP Apps: GUI Features
QA Contact: asa → sairuh
QA Contact: sairuh → claudius
adding alecf as he mentioned some interest in this bug.

Personally, I think this would be a great little feature to add. And supporting 
the favicon.ico spec shouldnt be considered as supporting microsoft's 
proprietary spec, but instead taking advantage of something that is already out 
there, is becomming more widely adopted, and shows that we are willing and able 
to integrate features from IE as they are for ours.

That's not to say we couldnt also offer an alternative in some other way, but 
not implementing it just to snub microsoft hurts us more than them and gives a 
little more incentive for folks to stay with IE...  
This part of favicon.com is sort of interesting... it might be a part of IE's 
spec that we might overlap:
-------------------------------------------------------------------------
FREQUENTLY ASKED QUESTION (PLEASE READ): I switched my favicon but my system 
continues to read the old one. 
Change the name of the favicon from the default favicon.ico to something else. 
Then add or update the link tag in the section of your html page:
<LINK REL="SHORTCUT ICON" HREF="http://www.favicon.com/favicon2.ico">
Remember, if you do not add this to your head tag, Internet Explorer will look 
for favicon.ico (all lowercase). 

-------------------------------------------------------



That sounds like a cache problem with IE. I have noticed that happens and we 
wouldn't want to imitate that.
Konqueror has the same caching problem btw.

Side note: Where do I go to request that bugzilla not send me mail when the CC
field changes?
bottom of a bugzilla page. edit *prefs*. *email settings*
uncheck each [ ] CC field changes box.

stay away from: When I'm the Bug Owner, email me: [ ] When I'm added to or 
removed from this capacity ;-)
*** Bug 82130 has been marked as a duplicate of this bug. ***
Bug 18502 only partially blocks this one. Reasoning is that favicons don't HAVE 
to be .ico files. Mozilla can support favicon for gifs, jpgs and pngs 
until .ico support is added to Mozilla (bug 18502). 

It would actually be ironic. Microsoft only would support it for .ico files, 
yet Mozilla would eventually support it for .ico, .gif, .jpg, .png, and any 
other image that Mozilla can read.
Target Milestone: --- → mozilla1.2
Just to recap a few things:

We should load the icon during page load, not during bookmarking. This removes
the privacy issue, and shows off the feature more. (It's hardly noticible in IE
due to the icon only being available post-bookmark).

We should NOT NOT NOT scale. You can't scale images when your working with 16x16
or 16x12 icons, it'll look like utter shit. It's hard enough to make anything
legible in 16x16 pixels, but if the browser is choping it down to 16x12 to fit
with the modern skin, you'll have nothing but a blob of colors. Skins need to
all go to 16x16, as does the bookmark sidebar, if we implement this.

Using the icon for the desktop is probably a whole seperate issue, considering
every platform has a differant format and size for desktop icon's we'd have to
convert to. Most likely more trouble then it's worth, unless we implement a
rel="gnome-icon", etc, and have the webmaster do the scaling and converting.

Will using rel=icon for our implementation allow us to understand rel="shortcut
icon"? If mpt is correct in his interpretation of a two word rel meaning two
seperate relationships, we should be able to grok the second relationship
seperatly, and ignore the first, non? That would be quite nice, as we'd be
compatible with the thousands of pages out there already.
Jeremy:
    Yep, icons should be used whenever referenced in the page, not just when
bookmarking.
    After reading about the problems that icon designers are having with MacOS
X, I think I agree that icons should not be scaled, but standardized.  Scaling a
photorealistic icons may sound like a good idea but it's probably not so good in
practice.  OTOH we could scale them but simply tell designers that if they want
the icons to look good, the standard is 16x16 (or whatever).  Five years from
now the Mozilla browser may want a different standard icon size, maybe 100x100
when we're all using those super-hi-res displays.
    If we introduce more rel types, I suggest we make them as general as
possible, i.e., "desktop-icon" rather than "gnome-icon".
    From 12.2 of the HTML 4.01 spec: The value of this attribute is a
space-separated list of link types.  I believe Mozilla is handling this
correctly, so we should be fine.
*** Bug 100540 has been marked as a duplicate of this bug. ***
Why does everybody here talk about M$ and bookmarks.
Why don't do it just like Konqueror has it.
When going to a webpage Konqueror always shows the icon in front of the url.
I didn't try bookmarks, but I guess bookmarks also have icons in front of them.
Why is this dependant on Bug #18502 ?
I just wanted to add that .ico files has one important feature: They are
multi-image files, so that they contain many versions of the icon, from which
the browser selects the proper one. This is a reason for: 1) Implement .ico
files in mozilla 2) Look some similar solution with .mng files.
I have to disagree with Jeremy on scaling.  Scaling of 12x12 to 16x16 or 32x32
to 16x16 can look just fine with a half-decent algorithm.  Using an expensive
algorithm is even plausible given the size limit we're talking about.

I mention this because if the icon is going to be the same for the desktop icon
(which might be 128x128), the bookmarks icon (at 16x16) and perhaps the icon in
the corner of the Window Manager's window (maybe 32x32) then either scaling or
multi-sized files need to be considered.

For the non-Microsoft developers here, .ico files actually support multiple
internal sizes.  This has been a standard feature for a long time and was used
extensively in help files to size up an image if the user upped their font
sizes, etc.

Specifying which file to use for different sizes is out of the question if we're
only going to support one file in the first place, but scaling down and up to
the correct sizes is going to have to be standard.  Who's going to be the first
to argue that icons will always be 16x16 in Mozilla skins??  We only need 640k
to run a PC, remember ...
*** Bug 104886 has been marked as a duplicate of this bug. ***
Depends on: 106328
I'm taking this.  I'm working on an ICO decoder now.
Assignee: netdemonz → hyatt
Status: NEW → ASSIGNED
Target Milestone: mozilla1.2 → mozilla0.9.6
As Guardian of the Accept: header, your accept changes are bogus. You've put
image/x-icon in there with no q value, so it has the default q of 1.0, and
image/bmp with the same q as */*, meaning you might as well not have it at all.

Given that there's approximately zero cases in which we'd prefer BMP to some
other format, there is no gain to be had here, as they can be incorporated into
*/*. Making this change would bloat every GET request we make by 31 bytes. We
are already getting complaints that our GETs are too big. Please leave the
Accept: header as it is now.

Also, just a reminder: if any of the files with the MPL on are completely new
and not derivatives, could they be tri-licensed, please?

Gerv
Drat. Wrong bug.

Gerv

    
    

    
  
I still maintain that asking for files we haven't been given URLs for is bad -
hammering every server we visit for favicon.ico is really rude.

Why do we need to? If we respect <link rel="icon">, and websites see that if
they bother to add that they can get tab and URL bar icons in Netscape 6.x (as
opposed to well-hidden bookmark icons in IE), they'll all do things the _right_
way (which IE also supports) without us having to adopt the broken IE behaviour.

I doubt I'm going to win this one, but I am right :-)

Gerv

    
    

    
  
Gerv, even IE isn't broken that bad. It only requests favicon.ico when you
bookmark the site. The only other way it gets a custom icon I know of is with a
<link>. At the least we should only request the file then. But preferably we
should only request it based on <link>. Aside from being dumb and rude, adding
an extra GET to every site load is a perf problem too.

I also don't like the idea of hardcoding 'favicon.ico' as special. This is
avoided when you only follow <link>s, since the filename can be anything you want.

Eventually HTML editors will allow each page to have its own icon and insert the
<link> for users. Why go backwards to a less controllable (for the browser and
for web site authors) method.
Keywords: helpwanted

    
    

    
  
It would be a good idea to set a max size for the icon to say 16x16. Try
freshmeat.net and see what wonders it will do to your window with this patch 
applied.

Prefs control for this needs to be implemented to turn this off due to a bit of
overhead.

It would be quite simple to add this to the bookmarks menu now with the right
caching work shouldnt it?

Overall patch is quite good.

    
    

    
  
> Gerv, even IE isn't broken that bad. It only requests favicon.ico when you
> bookmark the site.

Konqueror in KDE requests favicon.ico for every site.  It does a HEAD so this
operation isn't too expensive.

IMO.  It isn't ideal but I think we should just be pragmatic on this issue.  I
think that intellectually Gerv is correct but any alternative would need to be
pushed forward and we would be at least 1 year away from seeing a clean
implementation of this.

The issue I think is that content developers are NOT going to want to rewrite
all of their pages to add a <link> to the icon.

Copying a file and putting it into /favicon.ico (similar to the way they deploy
robots.txt) is very easy to implement and doesn't require a lot of work.

Until we have a way to do this with RDF or something "clean" we will have to
support the favicon.ico hack.

    
    

    
  
Yes, pragmatically, we want to support the feature in such a way that custom 
icons are actually seen, and that means fetching favicon.ico from the root of a 
site.  If you only honor the <link> method (something i also want to support), 
then the feature becomes largely useless, since nobody uses the <link> method, 
even though IE supports it.

I can add a pref to turn this off for those who don't want favicons.


    
    

    
  
Comment on attachment 56382 [details] [diff] [review]
Add favicon support to the URL bar and tabbrowser.

Looked it over. Looks fine to me.  It would be nice to find a way to update other skin developers so they can add this capability.

r=andreww

        Attachment #56382 -
        Flags: review+

    
    

    
  
Andrews, see ancillary bug 108403, XUL images don't scale.  With that bug 
fixed, the larger icons will scale down to 16x16.


    
    

    
  
Couple of points, relating to this line (and some others):

+    if (aURI && aURI.schemeIs && aURI.schemeIs("http"))

if you're looking for a method called |schemeIs| defined in aURI, your check 
here will give a js warning.. prefer |"schemeIs" in aURI|.

Also, what about https? (on this line, and some others)


    
    

    
  
(fix those, and sr=ben@netscape.com, with mac testing, of course) 

    
    

    
  


  

    
    

    
  
'burtonator' wrote:

| Konqueror in KDE requests favicon.ico for every site.  

One more reason to not like it ...

| It does a HEAD so this operation isn't too expensive.

It is SPAM nevertheless!
 
| IMO.  It isn't ideal but I think we should just be pragmatic on this issue.  I
| think that intellectually Gerv is correct but any alternative would need to be
| pushed forward and we would be at least 1 year away from seeing a clean
| implementation of this.
| 
| The issue I think is that content developers are NOT going to want to rewrite
| all of their pages to add a <link> to the icon.

You think ...

I think they will _love_ to do one simple search and replace run over their
site, if they are interested in that feature and if documentation about
Mozilla's implementation exists (==> Evangelism).

But they will shurely _hate_ Mozilla if it floods their logfiles with 404
messages for each visit of each site.

I can't see any delay for implementation _inside_ Mozilla. There is only the
link method (if there was one by the webservers http-configuration this was a
fine solution as well). 
If full web author's support for a new feature needs some months, that is not a
problem.
 
| Copying a file and putting it into /favicon.ico (similar to the way they 
| deploy robots.txt) is very easy to implement and doesn't require a lot of
| work.

If you think that every webmaster _has_to_ have a file called favicon.ico in his
root directory, write a proposal for a new RfC and make this an new standard.

Before this is ready each browser that is looking for odd files on a webserver
without having been told so, has to be considdered broken.

Mozilla is comitted to standards, not to M$-de-facto-monopolism!
 
| Until we have a way to do this with RDF or something "clean" we will have to
| support the favicon.ico hack.

WE DON'T HAVE TO!

That Microsoft is doing things wrong for years is never a valid argument to do
the same!
What about some MIME-type-guessing? What about smarttags?


    
    

    
  
What about the icon in the task manager like KDE or GNOME panels? Any progress on that part? Also, Michael, what are the other reasons not to like Konqueror? This is a little bit offtopic, but Konqueror performs quite well for me.

    
    

    
  
> Yes, pragmatically, we want to support the feature in such a way that custom
> icons are actually seen, and that means fetching favicon.ico from the root of
> a site.  If you only honor the <link> method (something i also want to
> support), then the feature becomes largely useless, since nobody uses the
> <link> method, even though IE supports it.

I think there's a very good chance that Mozilla/NS6/Beonex will get very popular 
very soon. If Mozilla only supports <link>, webmasters will start using <link> 
when Mozilla gets popular. So we might as well do it the right way.

    
    

    
  
Whoa there. favicon.ico is, in the final analysis, eye candy. There is
absolutely no reason we should be smacking around web servers for the sake of
following an ill-designed MS "feature", especially when there's a way for web
designers to activate it both here and in IE.

    
    

    
  
I'm with the group who's opposed to having Mozilla look for "favicon.ico"
unbidden (i.e., in the absence of explicit reference, as in a LINK element). 
What's the point of there being alternative browsers if they all jump over one
another in a race to scrupulously imitate all features, misfeatures, and bugs of
the most popular current browser?

    
    

    
  
> | Konqueror in KDE requests favicon.ico for every site.  
>
> One more reason to not like it ...

Don't be insulting.  Diversity of opinion is a good thing and just helps everyone.

> | all of their pages to add a <link> to the icon.
>
> You think ...

Yes... do you :)

> I think they will _love_ to do one simple search and replace run over their
> site, if they are interested in that feature and if documentation about
> Mozilla's implementation exists (==> Evangelism).

Really?  What if they don't have one site?  What if they have a site like yahoo
where it is generated from a DB and they have to pay someone $150 an hour to
come in and rework all their code tos support this small piece of functionality.

Instead they just run 

scp favicon.ico root@mysite.com:/home/httpd/

> But they will shurely _hate_ Mozilla if it floods their logfiles with 404
> messages for each visit of each site.

No... they can probably implement <link> if they want.  This way they will get
their favicon and no 404.

This is the pragmatic approach I was talking about.

Balance is a good thing..

> I can't see any delay for implementation _inside_ Mozilla. There is only the
> link method (if there was one by the webservers http-configuration this was a
> fine solution as well). 
> If full web author's support for a new feature needs some months, that is not a
> problem.

Yes it *is* a problem.

> | Copying a file and putting it into /favicon.ico (similar to the way they 
> | deploy robots.txt) is very easy to implement and doesn't require a lot of
> | work.

> If you think that every webmaster _has_to_ have a file called favicon.ico in his
> root directory, write a proposal for a new RfC and make this an new standard.

It is already a standard.  It is called a defacto standard.  We already have 70%
of the browser that implement this.

> Before this is ready each browser that is looking for odd files on a webserver
> without having been told so, has to be considdered broken.

Your opinion...

> Mozilla is comitted to standards, not to M$-de-facto-monopolism!

Keep an open mind here.  I don't like MS either but this isn't about MS vs
Mozilla.  This is about implementing a technical solution that helps customers
and pushes Mozilla forward.
  
> | Until we have a way to do this with RDF or something "clean" we will have to
> | support the favicon.ico hack.

> WE DON'T HAVE TO!

> That Microsoft is doing things wrong for years is never a valid argument to do
> the same!  What about some MIME-type-guessing? What about smarttags?

Did I say that those were acceptable approaches?  I did not!

The favicon.ico approach is not that bad of a hack.  If users don't want the
spam they can implement <link>

So what is the problem here?  I think you should really keep an open mind. 
Balance is good.

peace...

Kevin

    
    

    
  
Please take this discussion to netscape.public.mozilla.general

I have started a thread 'favicon' at
news://news.mozilla.org:119/3BE5AD97.60007@lemnet.com

    
    

    
  
Surely the sensible thing to do is as follows:

hyatt said he'd put the objectionable behaviour behind a pref. So, we start with
the pref off, and all those who don't like this behaviour put their money where
their mouth is and head out to evangelise topsites which have favicons. If some
percentage (say 80% of the top100 which have favicons) implement <link> before
the next Netscape release, Netscape leaves the pref off. Otherwise they flip it on.

Dave - would you sign up for that? It's seems the majority opinion is against
auto-request, but we should give them some time to do the evangelism they think
is the necessary replacement.

Gerv

    
    

    
  
This war needs to stop right now, take this discussion to the newsgroup 
and no more konq vs. moz fights here! Discuss that in alt.fan.mozilla or 
something like that... If you keep this up, you are running the risk of having 
your bugzilla accounts pulled!

    
    

    
  
A page author should not have to add an arcane piece of HTML to prevent their 
servers from being hosed, just so somebody can see a tiny little graphic that 
serves no useful purpose. It's ridiculous.

    
    

    
  
I feel this needs to be briefly reiterated, since everyone seems to think we're
implementing IE's behaviour.

IE *DOES NOT* request /favicon.ico every time it goes it a site. It *ONLY*
requests it when a user bookmarks the site (hence the name. Otherwise they would
have called it spam-me-with-lots-of-404s-for-this-icon.ico). Additionally, a
<link> tag in an individual document will force a load immediatly, and override
the default /favicon.ico path.

To respond to hyatt:
> we want to support the feature in such a way that custom icons are
> actually seen. ... If you only honor the <link> method ... then the feature
> becomes largely useless

Do you consider it largely useless in IE, then? The truth is, many sites out
there DO now use the <link> method, because that's the ONLY WAY you get it to
display in IE, unless the user bookmarks a page.

Check it in with just honoring <link>, and if you must, have it fetch the icon
when you bookmark as well. Have someone fix up mozilla.org, netscape.com,
cnn.com, and aol.com with the <link>. Everyone will quickly notice
Mozilla/Netscape6 support URL icons, and can add support on their own page.

The other issue here that hasn't been discussed is caching. From what I can
tell, the current patch doesn't actually save these icons anywhere. IE caches
the icons seperatly, but at least with IE5, it had a lot of issues. Even
deleting the bookmark and rebookmarking didn't fetch a new icon. Mozilla needs a
seperate URL icon cache, which will require some thought.

    
    

    
  
zach: this is not a Moz/Konq/IE flamewar, it's a legitimate discussion of the
best way to implement a feature. And if I get in trouble for pulling people's
Bugzilla accounts, I don't think it's threat you can make :-)

Gerv

    
    

    
  
Since there seems to be a split as to loading favicon.ico as the default
behaviour, why don't we just make it an option?  That way, the people that would
like to see it could enable it, and other could just leave it until they
bookmark the site (or if the site has a <link> for it).

    
    

    
  
Ok, here's the additional work regarding favicons that I'm going to do before 
any sort of landing occurs.

(1) Have a little cache of "missed" favicons.  I'll remember the last 10 missed 
sites.  That way as you're browsing around on a site, I'll only spam the site 
for its /favicon.ico once.
(2) Improve the XUL <image> tag to have a capability to continue to show its 
old image until its new image is available.  This will stop the "blinking" 
effect in the URL bar and tabs as you browse through sites that don't have 
a /favicon.ico.
(3) Get support for both <link rel="icon"> and <link rel="shortcut icon"> 
working in the tabs and url bar.


    
  

        Attachment #56382 -
        Attachment is obsolete: true

    
  

        Attachment #56469 -
        Attachment is obsolete: true

    
    

    
  


  

    
  

        Attachment #56533 -
        Attachment is obsolete: true

    
    

    
  
Ok, ready for a new r/sr to actually land this thing.  I've added a pref that 
defaults the whole feature to off for now.

    
    

    
  
Disregard the change to the accept header pref in all.js.  That isn't part of 
the patch.


    
  

        Attachment #56536 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Ready to land. (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
I don't believe this should be checked in.  We should not probe every website 
for favicon.ico.  This always asumes that a website's root is / whereas many 
websites arn't going to be this way.  If I go to 
http://www.mozilla.org/projects/, that shouldn't fetch the favicon from 
http://www.mozilla.org/favicon.ico, it should fetch it from 
http://www.mozilla.org/projects/favicon.ico.
We all know that checking in new features that are turned off by default 
eventually get turned on by flipping a pref.  Adding this without it being on 
is just adding additional bloat to our app which we don't need.  Websites that 
host lots of users are going to get very angry when all the hits to their user 
sites attempt to load /favicon.ico from their root for no apparent reason.

Lets get this right before we turn this on.  We should only fetch this icon if 
the document has a <link> element in it.

People will claim that fetching the icon only for sites that are bookmarked is 
a privacy violation...  then lets not do that (unless the site bookmarked has a 
<link> element.

There are a lot of people against this patch landing, and I think we should 
carefully review the implementation of this "feature" before landing anything 
for it (since we all know it will just end up turned on and broken).

    
  

        Attachment #56542 -
        Flags: needs-work+

    
    

    
  
We should probably move this argument to the newsgroups to figure out the 
proper behavior.  I feel very strongly that auto-fetching /favicon.ico is the 
wrong behavior.  People that run websites are going to get angry with this file 
being requested automatically.  While I believe that auto-fetching is probably 
what the user might want, it is certainly not what websites want (unless they 
explicitly ask for it (using <link>), and we don't want to piss off websites 
or, worst case, they'll start blocking our browser all together (more than the 
ones that already block us for other reasons...).

    
    

    
  
How about creating a variant of this patch that only uses <link>. There seems 
to be more agreement that pages using <link> to specify an icon is a legitimate 
use. That patch could be safely reviewed and landed, and would stop the "custom 
site/bookmark icon" gap. 

The favicon.ico debate could the be extracted into a separate issue of 
providing IE compatibility, if you will. 

    
    

    
  
>Websites that host lots of users are going to get very angry when all the hits 
>to their user sites attempt to load /favicon.ico from their root for no apparent 
>reason.

A more insidious problem happened to a friend. He got space on an ISP for his
site, and the ISP had it's logo at /favicon.ico. Friend could only get rid of it
by adding <LINK> to all of his pages. Switched since then.

    
    

    
  
Stuart, I have no intention of turning on the pref in Mozilla if it is the will
of the community that it stay off.  

As for bloat arguments, the part about fetching /favicon.ico is insignificant
code bloat.  Nearly all of the patch is just devoted to supporting custom icons
at all (code that would be used by the <link> mechanism as well).  

Whether or not to fetch /favicon.ico is one pref, and a couple of lines of JS,
and I am completely willing to leave it turned off.  For advanced users who
would like the capability in Mozilla, however, it should be possible to turn it on.


    
    

    
  
David Hyatt:
> (3) Get support for both <link rel="icon"> and <link rel="shortcut icon"> 
> working in the tabs and url bar.

Isn't "icon" part of "shortcut icon"? If it is so, do you need to look for both
or is it enough to look for "icon"?

    
    

    
  
Love your work Dave.  The bug's 25 votes speak for themselves.

My only suggestion would be to split the pref:

   [ ] Show custom icons in URL bar and bookmarks

   When a web page has no icon specified:
       (o) do nothing
       ( ) request favicon.ico

That way, people who are queasy about implementing de facto standards & causing
404s can use the feature with a clear conscience.

    
    

    
  
hyatt: the "rel" attribute is a space separated list of words. You can totally
ignore the word "shortcut", and just look for "icon". The following should all
result in the relevant <link> element being used as the icon:

   <link rel="shortcut icon" href="...">
   <link rel="icon" href="...">
   <link rel="icon next" href="...">
   <link rel="my icon is lovely" href="...">
   <link rel="next icon" href="...">

(Indeed, the last one should also end up being used in the link toolbar as the
link for the "next" button. This works already.)

Can't wait for this to be checked in, btw! :-D

    
    

    
  
Ewww. Hixie, for performance, I'd rather not have to search for a substring on
each link to figure out if it has an icon.


    
    

    
  
I ran some tests against a current build, the same current build plus the 
pending patch above, and then with the patch and the pref turning this on.
I ran my standard page loading test, which has all of the content hosted on 
the same server. For this page load test, there is no significant (read none)
difference in page load performance. The favicon.ico is GET once, upon the 
first visit to that server, and is not GET again.

I also did some tests for window open time, and there may be between a 1 and 2% 
cost to new window time, although I'm not sure I really trust that test yet (I 
think I do, but I don't want to start putting to fine a point on how 
representative it is of real end user experience). However, it does fit with 
the fact that features have costs.

I do note that the cacheing of the favicon.ico is not working correctly in a 
few circumstances. 
 1) The first time you open a second tab (type Ctrl-t), the /favicon.ico for 
    the URL of the first tab is GET again.
 2) If you "leave" a site (e.g., follow an external link), with either a
    browser window, or with a tab, and then come back to that previous
    page/site, then /favicon.ico is requested again. The same thing
    occurs when you switch tabs A->B->A, then A/favicon.ico is refetched.
 3) The cacheing of /favicon.ico is per window, so that if window A is pointed
    to foo.bar.com, then if window B tries to load foo.bar.com/bax,     
    /favicon.ico is fetched again
 4) Similarly, the cacheing is per tab, so that if a second tab opens site A, 
    /favicon.ico is fetched again. But, even worse, reloading one tab at site
    A can cause the other tabs to want to check for /favicon.ico (e.g., I was 
    seeing up to three GET's when reloading while 3 tabs were pointed at the 
    same server).

    
    

    
  
John, the next patch should address those problems.  It uses VALIDATE_NEVER in 
order to avoid refetching favicons.  This next patch also adds full support for 
the <link rel="...icon..."> form in the tabs and in the url bar.


    
    

    
  
Also, before playing with this new patch, you're well-advised to pick up the 
patch in 108318.  There were a couple of bugs in the ICO decoder still that 
would cause favicons to display incorrectly.


    
  

        Attachment #56542 -
        Attachment is obsolete: true

    
    

    
  
Comments on the patch:
   Why call them Internet Explorer Favourites Icons? If we're going to Embrace
   and Extend this Microsoft Innovation, we should do it right... and that
   means changing the name. :-)

   You have a lot of code that does things similar to this:
     t.setAttribute("image", uri.scheme + "://" + uri.host + "/favicon.ico");
   If the URI is:
      http://foo:8000/bar/index.html
   ...surely the favicon should be 
      http://foo:8000/favicon.ico
   ...and not
      http://foo:80/favicon.ico
   ...which I think is what your patch does. (benc, bbaetz: comments?)
   (What does IE do for this?)

   Finally, you check for the icon by doing:
      if (event.target.rel.indexOf("icon") == -1)
   ...but surely that will also catch:
      <link rel="lexicon" href="a-humougous-multimegabyte-file.html">
   You should look for strings matching the following regexp:
      \bicon\b          (\b is regexp for "word boundary")
   Another solution would be to have the events trigger once for each word in 
   the rel attribute (and have another event trigger once for each word in the 
   rev attribute) and do the splitting at the C++ level (assuming that is 
   quicker than a regexp search at the Javascript level).

   Finally one small note -- you discard the "type" attribute of the <link>
   element. That's ok (it's only advisory and HTTP headers should override it)
   but I would recommend putting a comment there to that effect, e.g.:
      // XXX type attribute discarded
   ...near the call to onLinkIconAvailable in the onLinkAdded method.


> Ewww. Hixie, for performance, I'd rather not have to search for a substring 
> on each link to figure out if it has an icon.

Don't shoot the messenger, I am merely telling you what the spec says. :-)

    
    

    
  
Please don't make an automatic request for favicon.ico under any circumstance. 
If it's hidden behind a pref I can be a good netizen and not spam others, but
what about everyone else using Mozilla (and IE) that continues to spam me with
these requests?  It gives me half a mind to put some bloody huge favicon.ico on
my server just to annoy you all.  :S  :P

If there exists a mechanism for specifying which resource to request, it should
be used instead of relying on a "magic name".  That's just bad design.  And in
this case, there are privacy concerns as well.

Regarding the substring search for each <link>, I'm surprised this parsing isn't
done once when the page is loaded, and all the relationships stored somewhere
that you could look up.  If every bit of <link> functionality has to do its own
parsing, that's a waste.

    
    

    
  
Tim: we are going to support <link rel="icon">, so yes, we support the "good
netizen" behaviour. Secondly, the pref will not be a hidden pref. Thirdly, if
I read the patch correctly, the pref will default to "off". Finally, why is this
a privacy concern?

Hyatt: Tim makes a very good point... we should have a single place to parse
<link> elements instead of duplicating the parsing code in three places (the
stylesheet loader, the icon handler, and the link toolbar).

    
    

    
  
It's the same old privacy concern, if we duplicate IE's behavior of looking for
"favicon.ico" when a user bookmarks the site.  Obviously access logs tell us
what a user looks at.  The extra request upon bookmarking tells us how the user
is using the info, which isn't really any of our business.

If we have this behavior, even if it is off by default, people can turn it on
and spam me with requests for a resource I never claimed to have.  Sometimes
I'll have a dead link that will 404, and that's my fault.  Sometimes a user will
typo a URL and 404, and that's just life.  But I look at a browser intentionally
making a request for something the user didn't explicitly ask for and the author
never indicated was there to be a bug, not a feature.

Hixie: hopefully the Link: header you told me about will also be supported here,
so that authors won't have to modify every page with a <link> tag.  Then, I
think, the primary argument to use the "favicon.ico by default" behavior would
go away.

    
    

    
  
Let me just comment that after reading this bug, I rushed to add the <link> to
my own pages. IE's method of requesting favicon.ico when you bookmark is
annoying, but Mozilla looking for it on every visit would be maddening.

I am glad this will be off by default, but still... yarg :(

I think the pref name should be something like

user_pref("browser.chrome.enable_shameful_evil_favicon_hack_behavior", true);


    
    

    
  
Sorry for the spam... But it's amazing that people are rushing
to implement a misfeature (even if disabled) just to be compatible
with a MSIE misfeature!

I can't use sites beacuse of "document.all" and I was told that it
was better this way and all the blah-blah, and I agree with that.
As somebody pointed before me, this feature bothers server admins not
users. Every user will likely enable it, and IMO requesting non-existant
files from servers is more broken than document.all. Or, if not,
please let somebody implement "document.all" with a pref that
defaults to off. If you don't agree with doing this
then leave this misfeature out of mozilla.


    
    

    
  
I can see that folks are not taking Stuart's advice and moving personal 
comments about the bug off into a newsgroup.  Since there has been so 
many comments in the negative I wanted to post a comment in the 
positive.

I believe this feature can become  something better than microsoft's 
original intention. Having these icons show up in the bookmarks list, in 
the tabs view and other places can really help users locate and assocate 
that icon with that site and more easily find bookmarks, etc.

I believe that via prefs a middle ground can be reached so that folks who 
wish to refrain from asking for the icon by default can be happy and know 
that this is the default behavior for mozilla.  However I believe that users 
should be allowed the choice to turn this on - and even have the sort of 
granular control of  say only fetching it if it's from a link tag or however.

I imagine that folks who are the most opposed to this have not actually 
seen it in action.  When you have a list of bookmarks a mile long - as I can 
bet most folks do - having these icons allow you to locate your desired 
bookmark very quickly.  And I also notice that when I use the "tab 
browsing" feature that it is often difficult to distinguish between tabs 
without constantly rereading the titles.  This would be  a big step toward 
alleviating that.

I belive that this is something that users will find quite useful and helpful.  
And with the preferences set up properly, can also be server-friendly.  




    
    

    
  
Hixie, good call on my dropping the port.  Trivial to fix.


    
    

    
  
Comment on attachment 56703 [details] [diff] [review]
Patch that supports <link> and is smarter about not refetching custom icons (either through <link> or favicon.ico).

sr=hewitt, but fix the port thing

        Attachment #56703 -
        Flags: superreview+

    
    

    
  
Comment on attachment 56703 [details] [diff] [review]
Patch that supports <link> and is smarter about not refetching custom icons (either through <link> or favicon.ico).

r=andreww on new patch.

        Attachment #56703 -
        Flags: review+

    
    

    
  
The pref in the current patch is called "Show Internet Explorer Favorites Icons
where available". When checked, it activated both the <link> and the /favicon.ico.
 But users do not understand the consequences of enabling this pref (namely rude
requests to the servers), because you deliberately didn't tell them.

I believe that the /favicon.ico request should be guarded by a non-UI pref,
default off. IF you really want to offer a UI pref, it should be possible to
activate <link> without /favicon.ico, and the wording for the latter must make
the consequences clear. (Yes, it will be hard to explain to the user, that's
part of the reason why there should be no UI to activate this.)

In general, I see no valid reason to implement /favicon.ico at all, and I
strongly oppose its including in Mozilla. <link> is not rude and by far
superiour. As pointed out before, we require page authors to follow good
standards at other places, too, with possible costs for our users. I do think
that standards are worth those costs, esp. in this case.

(Sorry for adding my comments here, but with 2 exceptions, the discussion on the
newsgroup has been ignored by the other developers.)

    
    

    
  
No.  <link> is always supported.  There is no pref for it.

The pref in the UI is specifically for /favicon.ico (hence the use of the term
"IE Favorites").



    
    

    
  
"Show Internet Explorer Favorites Icons where available"

Needs to be changed. You don't see IE calling JS "Netscape Javascript", do you?
 A novice user isn't going to have any more idea what it is, what IE icons are,
or why they're in mozilla/netscape. The context help can explain "it's the cute
little thing right in front of the web address you're at."

Link, Site, Web or URL Icon is fine with me. We certainly can't call it
"Internet Explorer Favorites", though.

The code also needs a little more consistancy. You call it favicon in CSS and in
a comment, the pref is called 'site_icons', and the function calls it LinkIcon.
Oh, and the variable is favicon.

Ideally, once this is found to work and have negligable perf impact, we don't
need a user-visable pref for it at all, do we? Who does't like cute little icons?!

And I agree with Ben, /favicon.ico should be a seperate, hidden pref if it
REALLY must be checked in now, and defaulted to off. I think the people who
argue for '/favicon.ico' would be surprised how many sites out there already
have the <link rel=icon>... remember! it's the ONLY way to show the icon to the
90% of your traffic that uses IE, visits the page, but doesn't bookmark it.

    
    

    
  
Yes I think that's an important clarification - the pref is to turn on/off the 
aspect that folks have been expressing an issue with (the fetching 
/favicon.ico) otherwise the code does the right thing and looks for the <link 
> attribute.  I agree that the wording of that pref could be made clearer 
somehow. I'll volunteer to file a bug on that and ask someone in docs 
(Ian?) to go in and help find the right wording.

    
    

    
  
LinkIcon is not inconsistent.  I use "LinkIcon" to denote an icon found using
the <link> element.


    
    

    
  
I will change the pref name to be favicons instead of site_icons.


    
    

    
  
Er, that's going in the wrong direction, actually :) We need to get away from
that word. Yes, I do hate this bugs summary line :) There's nothing special
about IE, other then it was the first browser to implement this type of thing.
Favorites is the name of it's bookmark equivilent. Not only is it a misnomer on
IE, since it can appear in other places, it's even more out of place in Moz and
NS, as there are no "favorites". Thankfully, the link rel value is generic
enough that we don't have to use IE's branded name *anywhere*, so let's not.

    
    

    
  
No, this is the right word.  This pref is specifically for whether or not to
fetch favicon.ico.  It is not about the <link> implementation.


    
    

    
  
> No.  <link> is always supported.  There is no pref for it.

Oh, ic. There should be. I don't necessarily want companies determine how the
icons on my browser UI and bookmarks look like.

> Who does't like cute little icons?!

Me. You can also call them corporate graffiti.

> I agree that the wording of that pref could be made clearer somehow.

How about "Blatantly spam servers with invalid requests to get more icons"?

    
    

    
  
Fixed.  I am opening a separate bug for the support of custom icons in 
bookmarks and on the personal toolbar.

Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
I believe that you should not have ignored the concerns of many people, incl
developers.

I filed bug 108823 and bug 108825.

    
    

    
  
great work, hyatt.  this feature rocks.

    
    

    
  
With this new preference turned on, using a CVS build on RH7.1 from about 
12 hours ago, I find that going to slate.msn.com in a tab causes a segv. I'm 
rebuilding now with current CVS and will put a gdb backtrace in a new bugreport, 
but I thought a headsup would be in order


    
    

    
  
anthony@interlink: did you get a new build and reproduce that crash?

I can't reproduce this, but I do see the a request for 
slate.msn.com/favicon.ico returns a 'HTTP/1.1 302 Object moved' and 
then a 'HTTP/1.1 200 OK'. (C'mon MSN, that's an error code not a 
"OK Not Found"). Maybe we have some problem when we pass this 'OK' but
bogus to the icon decoder.



    
    

    
  
> uri.scheme + "://" + uri.host + "/favicon.ico"

What happened to uri.resolve("/favicon.ico") ?

    
  
No longer depends on: 106328

    
  
Blocks: 106328

    
    

    
  
Please do not ever add the UI for this pref. If some people who are "web
knowledgable" want to destroy the internet by spamming the servers then they
know what they are doing wrong and let them. But please do not make it so the
average user can do such a thing. We have the ability to right a wrong done by
Microsoft by making this feature a standard only when the <LINK> tag is added -
and be HEROS :-) Let's not botch it up please. Eventually, hopefully we will be
able to remove that code and people won't notice.

    
    

    
  
"destroy the internet"! That's awesome. Please don't tell bin Laden about this
secret way to bring down our information society.

    
    

    
  
It is too late. Favicons of allah have been installed. Make your time.

    
    

    
  
To dispel some myths. The Al-Quaida's favorite favicons (aggresively searched
favicon.ico files at server root directory) are defaulted to "true" on the trunk
and "false" on 0.9.6 branch. The good guys' favicons (the ones using <link
rel="icon">) are swithed on by default on both the trunk and the branch.

I believe this is correct and needs no change. The trunk is for testing and test
them we do. Most people use the milestone releases anyway. 

Concerning removing the code, I am against it. OK, there is no standard about
theis but thge majority of the most visited websites has them anyway. We may
(and probably should) evangelise towards using <link rel="icon"> favicons but
this also is no standard, so our moral standing is rather shaky. Anyway, the
server load of reading one icon (usually about 2-3 kB) per session is minimal.
It can be decreased further (if one hates the favicon.ico idea) by creating an
empty file called favicon.ico.

    
    

    
  
> defaulted to "true" on the trunk and "false" on 0.9.6 branch.
[...}
> I believe this is correct and needs no change. The trunk is for testing and test
> them we do. Most people use the milestone releases anyway.

I think you misinterpreted the intention. It's more coincidence. See bug 109843.

    
    

    
  
FYI: netscape.com and netcenter.com have favicon.ico's but don't have the icon
links.

    
    

    
  
The favicons netscape.center and netcenter.com show are the icon any site
powered by Netscape httpd server. Check www.dilbert.com or www.unitedmedia.com
for other examples. If you used Netscape 4.* you would see the name "Location"
to the left of the URL bar change to "Netsite" when the sites are viewed.

    
    

    
  
Those comments belong in bug 110296 which is about evangelism for <link rel="icon">

From now on, if you find sites to evangalize, use that bug please :-)

    
    

    
  
It seems that in 0.9.7 it is requesting favicon.ico even when there is no <LINK>
in the page.

    
    

    
  
jks@akula.com: Yes. Thanks to the brains at Microsoft, we have to do it this way
as most people don't use the <link> method. Hopefully people will switch over.
That is what the evangelism bug is for.

I noticed that IE does the same thing on dilbert.com and unitedmedia.com

http://www.favicon.com/ Didn't waste any time in mentioning Mozilla.

    
    

    
  
1) http://bugzilla.mozilla.org/show_bug.cgi?id=32087 does indeed mention mozilla.
2) I thought the consensus was *not* to do this.  I was unaware of the whole
debate going on in bug 109843


    
    

    
  
1) I don't know what you are talking about. I said "http://www.favicon.com/
Didn't waste any time in mentioning Mozilla."

2) Please take this argument to the newsgroups. If you want to get rid of
favicon in place of link, then get sites to implement this method. Bug 109843 is
for that. Chances of getting the favicon search reversed is minimal. 

    
    

    
  
*SIGH* I meant bug 110296.

    
    

    
  
> Chances of getting the favicon search reversed is minimal. 

No.


    
    

    
  
> > Chances of getting the favicon search reversed is minimal. 
> 
> No.

Why not? What are the chances?

    
    

    
  
Please discuss this elsewhere. I just wanted to make sure that the situation is
understood correctly.

    
    

    
  
I request that favicon in bookmarks be readded to the current builds. 1.0+  :)
Product: Core → Mozilla Application Suite

    
  
Component: XP Apps: GUI Features → UI Design

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: