Closed
Bug 108825
Opened 23 years ago
Closed 23 years ago
"Show Site Icons where available" is highly misleading
Categories
(SeaMonkey :: UI Design, defect)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: BenB, Assigned: hyatt)
Details
The UI pref introduced by bug 32087, "Show Internet Explorer Favorites Icons
where available", is highly misleading.
What it enables is that the browser requests <http://webserver:port/favicon.ico>
for *each* pageload (from a new site) (not just bookmarking, as in MSIE). In
many cases, the URL will be invalid, leaving a 404 in the site's error log. Many
website admins understandably hate this rude behaviour, which one might call abuse.
"Blatantly spam servers with invalid requests to get more icons" would be a more
fitting wording.
I suggest to remove the UI pref altogether, or better yet remove even the code
for it.
Comment 1•23 years ago
|
||
I agree. Remove the support for this in the UI and the code. The <link>
technique is far superior (and not rude).
Comment 2•23 years ago
|
||
I would instead suggest checking for the domain/IP of the site and check for a
favicon only if it's not been checked before. This could be achieved by keeping
a little list, and setting a preference for expiration of the items in the list.
In any case, this new functionnality should be kept, because as frivolous as it
seems, it's another little step in evangelism ('look ma, i too can keep favicons
now'); and every step counts.
Comment 3•23 years ago
|
||
The fishing for an unreferenced /favicon.ico file is a great burdon for
evangelisation:
"Look, once Mozilla tried to do things better, but now they gave up and mimic
the most ruthless features of Internet Explorer. Why should we webmasters
support them if they don't respect our servers and spamm our logs?".
The cool feature is:
"I just add one line of code to my main template and my pages display my Icon
immediately after it is loaded. Now this is a cool feature, whereas IE's
bookmark icon was rather useless because only few people ever saw it."
Comment 4•23 years ago
|
||
IMO, we shouldn't mention the name "Internet Explorer" in a feature that is
either applicable for a lot of browsers or, as some people (not me) think, obsolete.
If we will support two prefs, as I just supposed in bug 108823, the first pref
turning the whole feature on or off, shouldn't cause any bad spamming of reqests
at all.
This can go with a text like "Show special icons for sites that provide them"
Only the second one, turning reqests of /favicon.ico on/off, will spam servers -
at least servers of people who don't want special icons for their sites.
If that is shown in UI, it should have a text like "Request a default icon from
the server if the site doesn't specify a special site icon"
Comment 5•23 years ago
|
||
Please, consider using the term "page icon" instead of "site icon". The icon is
tied to a specific page, not to a whole site. A site could have an icon for each
page, for instance a set of visually related icons for the different areas of
the site.
Comment 6•23 years ago
|
||
The version of the patch that was checked in changed "Internet Explorer
Favorites Icons" to "Site Icons". Updating summary.
The pref should be moved under Debug for now, and called "Aggressively retrieve
site icons". Give us a chance to evang. some major sites to add a simple <link>
before this is so easily user accessible.
Summary: "Show Internet Explorer Favorites Icons where available" is highly misleading → "Show Site Icons where available" is highly misleading
This pref should indeed be completely removed. There are some things that are
sufficiently wrong-headed that they just shouldn't be doable in Mozilla (without
modifying the source code). Arbitrarily requesting a file from a Web server like
this is just bad manners, plain and simple. That Mozilla is behaving badly just
to support some *eye candy* is really wrong.
Updated•23 years ago
|
QA Contact: sairuh → claudius
Comment 8•23 years ago
|
||
hehe :)
This reminds me of the pref that enables the <blink> tag
Assignee | ||
Comment 9•23 years ago
|
||
So this bug is INVALID now that the pref no longer applies to favicons.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 10•23 years ago
|
||
No, it's fixed.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Reporter | ||
Comment 11•23 years ago
|
||
... if anything.
And, if a bug was valid when it was filed, it cannot get "invalid" afterwards.
Marking FIXED.
If anyone wants to have the backend pref removed altogether *and* he thinks he
can make a case for that, feel free to reopen.
As for myself, although I don't like the backend pref existing, I can live with
it, as long as no distributor turns it on by default.
Ben
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 13•23 years ago
|
||
> ------- Additional Comment #9 From David Hyatt 2001-11-08 23:49 -------
>
> So this bug is INVALID now that the pref no longer applies to favicons.
Well, since the favicon pref is enabled by default now, and according to
comments in bug 110069 there will *never* be a gui pref specificly for favicons,
effectively, for all users who dont know how to edit their prefs.js files, this
misleading pref caption once again applies to favicons.
Reporter | ||
Comment 14•23 years ago
|
||
Reopening. Hyatt silently turned on the favicon request again, which "regresses"
this bug.
Assignee | ||
Comment 15•23 years ago
|
||
This pref is in no way misleading. It does exactly what it sets out to do.
When checked, custom icon support is enabled. When unchecked, no custom icons
will be shown of any kind.
This bug is FIXED.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 16•23 years ago
|
||
Read the initial description again. The state complained about exists again.
This is not fixed. REOPENing.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 17•23 years ago
|
||
Ben, this bug is dead; let's not play this game. There's no problem with the
pref itself. From a user perspective, all is well. If you have an issue with
what we're doing under the covers then fine, file a new bug in the proper format
or start a newsgroup thread.
DO NOT REOPEN THIS BUG
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 18•23 years ago
|
||
VERIFIED Fixed. I'm serious. The next comment should cite a different well
written bug report or newsgroup thread.
Status: RESOLVED → VERIFIED
Comment 19•23 years ago
|
||
Uh? Sorry to interrupt, but as I see it, the bug is still there.
"Show site icons when available" looks like a passive feature, which
will quietly and nicely avoid hiding some information mozilla already has.
This is not what is happening. The pref (although it shouldn't be there)
should be named something like "Aggresively probe all visited sites in search
for a site icon".
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•