Closed Bug 108823 Opened 23 years ago Closed 23 years ago

Can't disable site icons

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: BenB, Assigned: hyatt)

Details

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.
Keywords: regression
You can't label something as a regression that is a new feature.
Keywords: regression
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>
Whiteboard: WONTFIX?
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.
Similarily, let's remove the features "Use my fonts only" and "use my colors
only". While we're at it, let's force JavaScript on the users. And allow sites
to disable the toolbar, menu and context menu, so that the user can't control
the app anymore. No, wait, we already do the latter.

Ian, I don't think, this argumentation leds anywhere.
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.
Whiteboard: WONTFIX?
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...
QA Contact: sairuh → claudius
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.
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 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
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.