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: