Regression intruduced by bug 32087: Impossible to disable the feature. Just like colors in webpages, I might not want to see the icon's of websites.
You can't label something as a regression that is a new feature.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
> You can't label something as a regression that is a new feature. I can, if I (arguably) like the old behaviour better than the old one and I have no chance to revert the old one.
Someone call the waaaahmbulance.
I think we should be able to disable the support of the <title> tag too -- when visiting a site you might not want to show the site name in the title bar. Similarly we should be able to disable the showing of the site's URL in the location bar. </sarcasm>
At least icon files should not be loaded (even if linked inside the page) if image loading is disabled in the user prefs ("[x] Do not load any images").
Why has this discussion become so juvenile? I think this request is a valid one. I don't like the current behavior because I don't want information on what I bookmark finding its way to people that would abuse this information. It also makes no sense to spam servers with requests that are non-standard and often futile, especially when an alternate, standard-compliant method already solves the problem.
Hyatt's patch from bug #32087 does _not_ load the icon on bookmarking, it loads the icon each time a site is entered. Bookmarking does not trigger any speccial action, because everything has allready happened on page load. Unfortunately Hyatt used the M$ terminology in a puzzeling way. The original goal was implementing <link rel="icon" ...>. This is what is referenced in Hyatt's code as 'LinkIcon'. The advantage of this implementation is that it is (as a usefull side effect) downwards compatible with existing sites with M$ notation <link rel="shortcut icon" ...>. Additionally (some say: "unfortunately") Hyatt implemented an algorithm for searching a file called /favicon.ico if no <link rel="... icon" ...> is found in a web page's code (bug #108825 is about the question what kind of pref UI this should have). He called this kind of icon grabbing behaviour 'favicon' in his code (eg. 'RootIcon' might have been much clearer), whereas Mozilla's behaviour on fetchin such an icons is kompletely different from IE's. But Norton (if I don't have understood anything wrong): on bookmarking will happen nothing special at all. I hope the feature (no matter in what detailed form) will be included in tomorrow's nightlies, that everybody can check this out on their own.
Spam: Adding opinions to the status whiteboard is not nice.
So, if I read all comments, correctly, there should be two prefs for that feature, as it is two features in reality: one pref should turn on/off parsing site icons altogether (it seems some do not want to have such a pref at all - but if we have prefs to show/hide other <link> elements in our UI, and we do have that for "site navigation bar", then we also should have a pref for this <link> content) default value for that pref should be "on" in Mozilla the second pref should turn on/off requesting /favicon.ico (This pref should only take effect if the first pref is turned on) default value for this should be "off" in Mozilla, so that we don't spam servers - Mozilla is a nice lizard, and should not stop over others who don't want to use special site icons at all... (OK, this is a personal opinion) other distributors like Netscape can still default this to "on" if they want! The first of those prefs should also be in UI, from what ppl tell here (and what I do think), we can still argue if the second should be hidden or shown in UI as well... (IMO, it doesn't have to be in UI) I'm not someone who can tell which way we go or implement this but I want us to solve in a satisfying way - so is this a possible solution for all?
I believe it's a reasonable request to be able to turn it off alltogether - but my question would be whether having it off totally aught to be the default for moz. I agree that just like you can turn off downloading images, it'd be possible somehow to not d/l icons, but our default _is_ to download images(from a site), and the same thing (fetching icons via <link> or whatever) seems to make sense in this context as well.
This bug should probably be marked fixed and a separate opened on the /favicon.ico issue. There's a pref under Edit->Preferences->Appearance which disables site icons and it's currently off by default. The pref to tweak is: user_pref("browser.chrome.site_icons", true);
seawood, it appears the pref we have now in there does not disable the feature completely, but does only disable fetching /favicon.ico if there is no <link rel="icon"> tag. The text of the pref is highly misleading though...
See my post to n.p.m.general. Plan of attack is this: (1) The UI stays the same. (2) The pref in the UI, site_icons, will be changed to apply to both <link> icons and favicons. If you turn it off, neither will load. If you turn it on, <link>s will load. Its default value will be on. (3) A new pref (not present in the UI) called favicons, will apply only to favicons. Only if the site_icons pref is enabled and favicons is also enabled will Mozilla check for /favicon.ico. This pref will default to off. Sound reasonable?
If we can't convince you to remove that piece of code completely, a hidden pref defaulting to off for /favicon.ico files is IMO OK. But please: Be more precise in the way you name the thing! Icons referenced in the link element are not "site icons" but "page icons" because they are only applied to each single HTML page and to nothing else on the same site and even their filename is completely free. Icons found by a blind lookup for the resource /favicon.ico should not be called "favicon" either. They _are_ "site icons" but i guess "site root icon" (or for the hidden pref "SiteRootIcon" was a better choice. Please avoid the word "favicon" whereever possible (except for the filename)! Most people connect it to IE's lame concept of "Bookmark Icon" and communication is very hard if you have to explain that Mozilla loads the Icons at a different time and (partly) for a different purpose. We do it different and thus we should name the whole thing different! I am convinced that last day's discussions would have been a lot easier and less aggressive if we had used a precice name for bug #32087. "Favicon" comes from "favourite's icon" and is an artificial M$ word for using icons for nothing but bookmarking (and afterwards). We do much better! Let's express this by a fresh name! Greeting, Michi P.S.: I've been doing some tests with build 2001110708. The feature is ultracool, especially in tabbed browsing! I am in a hurry to fix all my sites.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Build 2001110803 Are these recent changes having the effect of only getting 2 or 3 site icons showing up when browsing today, as compared to just about every site showing icons with yesterday's build. Just some examples that showed yesterday(11-7) vs. not showing today(11-8): Google Deja Altivista Tucows Excite Hotmail Msn Etc, etc, etc: Just wondering. Don't kill me, but I actually kind of like this feature.
Umm...Nevermind...I see clearly now...must've been asleep before
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.