Closed Bug 109843 Opened 23 years ago Closed 23 years ago

Turn on aggressive favicon.ico search by default

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.7

People

(Reporter: hyatt, Assigned: hyatt)

References

(
URL
)

Details

Attachments

(1 file)

Turn the pref on. Also fix the hang when non-ICO files are sent to the ICO decoder.
(deleted), patch
bryner
: review+
bugs
: superreview+
Details | Diff | Splinter Review 
Turn it on.  It's ready for testing.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
Comment on attachment 57571 [details] [diff] [review]
Turn the pref on.  Also fix the hang when non-ICO files are sent to the ICO decoder.

sr=ben@netscape.com
Attachment #57571 - Flags: superreview+
Comment on attachment 57571 [details] [diff] [review]
Turn the pref on.  Also fix the hang when non-ICO files are sent to the ICO decoder.

r=bryner
Attachment #57571 - Flags: review+
Comment on attachment 57571 [details] [diff] [review]
Turn the pref on.  Also fix the hang when non-ICO files are sent to the ICO decoder.

r=glazman
that's a perf/footprint improvement, check it in :-)
Comment on attachment 57571 [details] [diff] [review]
Turn the pref on.  Also fix the hang when non-ICO files are sent to the ICO decoder.

sr=hewitt
r=jaggles
a=gerv (hahaha)
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
OS: Windows 2000 → All
Hardware: PC → All
Is this safe for the 0.9.6 branch?
I don't want to check it in on the branch.

Sorry to enter so late in the game, but didn't we want to avoid bombarding
servers with requests to "/favicon.ico"?
Ack!
Um, we do not yet have a GUI to let people this back off again, do we? 
Question for Hyatt: Is this just being turned on temporaraly, so people can test
it, or is this intended as the permanent default?

If this is just on temporaraly for testing, then I totally understand why you
WONTFIXed bug 110069 ... otherwise, I am still confused...
What's the specific issue remaining?  Personally I'm greatly
distressed that the 'wrong way' /favicon.ico server-spam is
now apparently on by default in addition to the 'right way'
<link> mechanism, but that probably needs a separate bug filed.

Ok, hyatt or hewitt, say something.  Should there be a UI for the pref now?

The consensus among mozilla.org staff is that it's ok for this pref to be on by
default, at least until we get a storm of protests from webmasters (we may not).
 It wasn't kosher of hewitt to self-sr= and then sass off Gerv, but we'll let
that pass.  The favicon feature is popular enough, even though many hate it and
it's a de-facto M$ standard whose HTTP request frequency we are raising probably
a lot, that we believe it should be on for now.

Given that, I personally think there should be a UI pref.

/be
Hyatt, we (on severals bug, in the newsgroup) agreed that this stays off. Don't
turn this on again silently (without newsgroup discussion) afterwards.

Please back out the change. Please wanting to test this can turn this on. If you
want broader testing, create a Debug Prefs UI for it.
Blocks: 108825
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
> The consensus among mozilla.org staff is that it's ok for this pref to be on by
> default


Brendan, this has been discussed extensively on several bugs and on the
newsgroup and the outcome was that this stays off. If you overrule this outcome,
please post to the relavent thread with your rationale and let us this this
(again :-( ) please.

Needless to say that I am unhappy about your decision. Such rude and egoistic
behaviour has no place in open-source.
No longer blocks: 108825
No longer blocks: 104864
*** Bug 110168 has been marked as a duplicate of this bug. ***
BenB: I'm familiar with the arguments.  There is no egoism (egotism, even) here,
and staff would prefer not to have to render a Solomonic decision, but people
cannot agree on the proper default.  Your ire is matched by others of exactly
the opposite opinion.  What else can be done than to break the tie and cut the
child in half?

/be
for the record, there is a patch in bug 110069 that implements a GUI pref
-> XP Apps: GUI Features per the other favicon bugs.

The discussionhere is presently academic as the aggresive favicon.ico search was
broken today. See bug 110202.
Component: Browser-General → XP Apps: GUI Features
Brendan, please let's discuss this on the newsgroup .general, thread "favicon"
(started 2001-11-04).
The module owners/peers for navigator have reached consensus that this pref
should be enabled by default.  There is an exposed pref in the GUI for disabling
custom icons, and this single pref is considered sufficient.

Resolving as FIXED.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Mozilla as a nice open source browser should *never* agressively spam servers
with any requests, esp. not for such an ugly unconfigurable thingy that M$
created!!!

If any of our distributors (esp. Netscape) wants to do that, they can enable the
pref in their builds by default - but, again, we *never* should to this!

I know people who may abandon their support for Mozilla because of such tactics...
> If any of our Netscape wants to do that, they can enable the
> pref in their builds by default

No.

> I know people who may abandon their support for Mozilla because of such
> tactics...
me too.

Hyatt, I don't care about module owners, when we (incl. yourself) agreed on the
newsgroups that this will not be turned on. And we agreed on that solution,
because many people were against this solution.

Who is the mpdule owner anyway? This is XP Apps. The owner listed on
<http://www.mozilla.org/owners.html> is hopelessly outdated (Don Melton). Despot
lists mcafee and pinkerton as owner, peers are claudius, danm, erik, radha,
ramiro, saari, scc, sdagley. I see none of them approving this change.

The fact that nobody said anything in the same newsgroup thread about this
change is telling...
I'm sorry to have to say this, but as a webmaster, I am now forced to consider 
blocking Mozilla from my sites.

As a Mozilla user and soon-to-be-contributer, this is of course not something 
that I want to do, but on the other hand I don't want my servers to get spammed 
either.
> > If any of our Netscape wants to do that, they can enable the
> > pref in their builds by default
> 
> No.

I'm afraid they already have. This pref is on in all-ns.js.

Gerv



So is there any way to detect and block visitors who have this enabled from my
servers? Or do I just need to try to block all Mozilla-based browsers?
Oh, I think that this talk of banning Mozilla is a bit
over-the-top.  Did people start to ban IE when it
started with similar (though less-) obnoxious
network behaviour?

I'll settle for just gnashing my teeth and muttering
to myself while repeatedly clenching and unclenching
my fists.

It's a question of cost-effectiveness. IE does a relatively small amount of harm
per visitor and accounts for almost 90% of my visitors. Mozilla accounts for
just under 1.5% and generates far more spurious requests for a given number of
visitors.
I agree with the criticism.  This is a disaster.  What right-thinking person
would make such a waste of bandwidth the default behaviour?  If it must exist at
all, the default should be to turn it off.  I speak not only as a user, who
dislikes seeing the icons in the browser in the first place, but also as
somebody with their own Web site who finds turning this on to be simply nothing
other than rude.  Is somebody going to file a counter-bug against this?
> I'm sorry to have to say this, but as a webmaster, I am now forced to consider 
> blocking Mozilla from my sites.

   Excuse the newbie question but how would you go about doing this?  (Under
Apache.)  I might consider blocking also - I'll have to think about it.  If I do
block, I'd throw up a page saying it was blocked because of Mozilla's impolite
behaviour.  (I'd hate to do so, however, because I use Mozilla and support it in
every other way.)
gmiller: quantify "far more spurious requests for a given number of visitors" --
show us the numbers.

Recall that (modulo bugs being fixed now) the favicon is cached if found, and
its lack cached if not found, persistently and with never-expire.

/be
I dont like this anymore than the rest of you, but I think promoting <link
rel="icon"> usage ( bug 110296 ) is a far more productive way of dealing with
this than blocking mozilla and ranting in anger (although I really like the
"repeated clenching and unclenching of fists." idea)

And Greg, in answer to your question, I think the best way to stop Mozilla (and
IE) from spamming your server for favicons is to bite the bullet and add a valid
<link rel="shortcut icon"> tag to all your pages (tedious yes, but thats what I
am working on myself.)
Please attach evidence of increased inconvenience to you as a webmaster in 
this bug report.
How about actually creating a favicon.ico that displays something rude? <grin>
Adding a link to generate even more bandwidth usage is not a real solution.

In any event, I'm sorry for spamming this bug. I've learned in the past how
futile it is to debate changes in Mozilla. Arguing against this is just
irritating people for no good reason.
> Arguing against this is just irritating people for no good reason.

On the contrary, sometimes being irritating is the best way of getting
attention.  However, I, too, will stop arguing here.

Hmmm what should a webmaster post, error_log output, or webalizer output for the
number of 404s that went up when IE implemented favicon.ico as a default turned
on? I can probably produce these, Ben, if you like, for a site that does around
1.5M PVPD.

This is so completely broken. We shouldn't be banging servers for favicon.ico
unless the user says he wants to be rude by selecting the pref. It should be
something like:

[ ] Be utterly rude and bang all servers for favicon.ico when I load any page

I really think that - if nobody has the sense to revert this - a poll should be
run on mozilla.org to select the behaviour. If we lose, _then_ we shut up.
I'd like to see that you've been financially disadvantaged by this feature 
because so many viewers with Mozilla have visited your site that the extra 
bandwidth has caused you to have to expand. 
I would like to see the page. It probably has no graphics and very short text
files if a query for an icon and the 404 answer make any difference. Yet it must
be very popular if it is bandwidth constrained. Dying of curiosity about what
kind of a page this could be ;-)
Brendan, Ben Goodger,
it is clear, from the code alone, that this change will cause more bandwidth for
servers and that Mozilla will ask for the URL more often than MSIE. Bookmarking
is clearly done less often than requesting the first page on a server. If there
is no /favicon.ico, this request will end up in the error log. I see no need to
prove any of that.

I will add my reasoning against /favicon.ico to the newsgroup thread "favicon"
in .general.
>The consensus among mozilla.org staff is that it's ok for this pref to be on by
>default, at least until we get a storm of protests from webmasters (we may not).

OK Brendan, why don't you define for us what "storm of protests" means?  I may
be missing something here, but in all the discussions we have had on this issue
I can't recall a single webmaster actually wanting automatic favicons enabled. 
From what I can see in every bug and every newsgroup thread on this subject, we
get dozes of posts from webmasters asking, wishing, or demanding that this be
turned off.

Just how many people have to complain before it is considered adequate to
justify disabling favicons?  If you are really interested in knowing where
people stand someone should file a bug to turn this off completely and see how
many votes it gets.

Oh and just for the record, you can add me to the list of angry webmasters who
think this feature should never have been enabled in mozilla to begin with.

Take it to m.general, please.

/be
It would be really interesting to get some hard numbers on this. Just looking 
at the current logs will not really say anything since very few people browse 
with a mozilla with this pref turned on. So we need to come up with some way to 
approximate the number of 404s per (for example) month in the event of a 
browser with, say, 30% marketshare using the current configuration.

Since the absence of a /favicon.ico is cached the number of 404-ing requests 
will be much lower then the numbers of pagehits. Brendan says that the absense 
is cached "persistently and with never-expire", does that mean that mozilla 
won't request /favicon.ico again unless the user manually clears the cache? In 
that case the number of 404s will be approximatly equal to the number of "new 
users" every month * 30%.

If it's not possible to extract the number of new users from the logs i think 
that the number of new IP-addresses * 1.5 is a good enough estimation. There 
are probably more then 1.5 user per IP on average, but all users probably don't 
visit the site. If someone have a better number then 1.5, please speak up, my 
guess is very uneducated.

However it seems a bit wrong to me that a resource is cached "forever". What if 
a site want to start supporting /favicon.ico? Will only new users see the new 
icon? IMHO a resource should be reloaded at least sometime so that if the 
resource appears/changes we will eventually catch it. 

So say that we reload every 2 weeks. That means every user will 
reload /favicon.ico once every 14th day, which means that the number of 404s 
will be "number of destict users during 14-days" * 0.3 * 30/14.

So, we've got: 

Hits = newUsersPerMonth * 0.3                 if we cache indefenetly

Hits = distinctUsersPerXDays * 0.3 * 30/X     if we refetch every X days

Where IP-addresses * 1.5 could approximate number of users. IMHO the right 
thing would be to use the second formula with X ~= 14.

So it would be great if someone with access to the logs to a rather heavily 
used site could run these formulas and compare that to the number of "normal" 
404s.

I'll post this to n.p.m.general too.
> However it seems a bit wrong to me that a resource is cached "forever".

It's not. I used local proxy to check this. It seems /favicon.ico is checked
once per session with cache set both to "automatic" and "every time".

If this is not the expected behavior, a new bug should be filed.

> > However it seems a bit wrong to me that a resource is cached "forever".
>
> It's not. 

It is cached until it is evicted from the cache.

> I used local proxy to check this. It seems /favicon.ico is checked
> once per session with cache set both to "automatic" and "every time".
> 
> If this is not the expected behavior, a new bug should be filed.

I just did this test, running through a proxy that was hard coded to 
whine about '/favicon.ico' requests. I delete the cache directory in 
a profile, started/shutdown, restarted, visited 10 different sites/servers
and 2nd level pages on those sites, then shutdown/restarted and visited 
those same sites again. 

With two caveats[1], I only made a request for /favicon.ico on the initial
contact with each server (the designed behaviour). I did not request 
/favicon.ico from the same server more than once, and on the second restart, 
I made no /favicon.ico requests at all.

[1] Caveats:
 i) er, well, the first time I tried this with my opt. build, I should have 
    run regxpcom (or deleted component.reg) because I had _no_ disk cache, 
    due to (I assume) interface changes that I hadn't picked up.
ii) er, two, I did ping bugzilla.mozilla.org three times on the first visit.
    If I can reproduce this behaviour, I will file a bug.

p.s., with a couple of quick hacks, you too can have a favicon-whining 
      proxy server :-] Just get the perl source from 
        http://www.stonehenge.com/merlyn/WebTechniques/col34.listing.txt
Summary: Turn on favicon pref → Turn on aggressive favicon.ico search by default
Jonas, Greg, Jason: I'm hardly an Apache expert, but from reading the docs, the 
short-term solution would appear to be putting the following in httpd.conf:

BrowserMatchNoCase "Gecko/" mozilla
BrowserMatchNoCase "Gecko/199" mozilla199ymmdd
BrowserMatchNoCase "Gecko/200" mozilla200ymmdd
BrowserMatchNoCase "Gecko/20010" mozilla20010mdd
BrowserMatchNoCase "Gecko/200110" mozilla200110dd
BrowserMatchNoCase "rv:0.9.6)" mozilla096
<FilesMatch *> 
Order Deny,Allow 
Deny from env=mozilla
Allow from env=mozilla199ymmdd
Allow from env=mozilla2000mmdd
Allow from env=mozilla20010mdd
Allow from env=mozilla200110dd
Allow from env=mozilla096
</FilesMatch>

This will incorrectly block Mozilla builds from between November 1 and November 
13 (that could be fixed by adding eight more lines, the contents of which are 
left as an exercise for the reader). It will also unfortunately block even 
those Mozilla derivatives which have the misfeature disabled or removed; but 
there's really no way of getting around that unless you maintain an exhaustive 
list of Mozilla distributions, thus reintroducing the repetitive opt-out 
problem which unsolicited /favicon.ico requests caused in the first place. 
Finally, note that the presence of the ")" in the 0.9.6 rule is important.

Alternatively, if you have PHP running, you could extend the httpd.conf and PHP 
script found at <http://mise.wox.org/constructive/favicon/> so that requests 
for /favicon.ico from Mozilla-based UAs get redirected to
<http://mozilla.org/somerandomstring/favicon.ico>.

The medium-term solution is to get <link rel="icon".../> used on all sites you 
have write access to, and lobby for <link rel="shortcut icon".../> to be used 
on other popular sites, as it would seem the relative lack of those elements is 
why the current Navigator `module owners' (and I use those scare-quotes 
reluctantly) have decided to introduce unsolicited /favicon.ico requests.

The long-term solution is (a) to push for a more transparent process of 
deciding and announcing who module owners are (currently they seem to emerge 
unannounced from the depths of netscape.com, hence the scare-quotes), and (b) 
to code enough so that it becomes embarrassingly obvious that you should be the 
module owner for your chosen module. Then you can reverse unfortunate decisions 
such as this. Today /favicon.ico, tomorrow /p3p.xml, then /sitemap.rdf, 
eventually /somanyfilesthattheusabilityofyourerrorlogapproacheszero.

This bug is verified fixed. I've seen some pages where no icon appears at all, 
but as long as Mozilla asks for /favicon.ico I'm not going to be filing them.
Status: RESOLVED → VERIFIED
> to code enough so that it becomes embarrassingly obvious that you should be the 
> module owner for your chosen module.

Just to see the current module owners not come by with reviews timely or
completely blocked the patches?
There's a very simple solution to the 404 issue for webmasters who really care.
Add a file called "favicon.ico" in the root of your web server.

As an added benefit, if you make that file contain a valid icon, then Konqueror,
Mozilla and IE will increase the user's appreciation of your site and brand
recognition of your site will increase overall.
I am not happy with the way Mozilla is forcing this feature down the throats of 
webmasters.  Outgoing bandwidth is expensive, especially if you end up using 
more per month than you expected to.  Many users have limited bandwidth as well.
> Add a file called "favicon.ico" in the root of your web server.

No. Who are you to tell me, how my URL space (and in my case dir space) should
look like?
This is pure lunacy and should never have been accepted.
If Netscape wants this feature (which is what obviously happened here), then
Mozilla needs to drastically change at once, and development needs to happen on
two trunks: one normal Mozilla trunks, and one trunks for stupid, crazy,
unpopular nonsense the Netscape people want.
Greg, quit trolling in resolved bugs.  Please file a bug to turn off aggressive
favicon.ico search.

In the biblical story I mentioned, King Solomon didn't actually have to cut the
baby in half, he just threatened to render that judgment, and the contending
parties came to a better agreement.  I can't make an analogous threat here, but
I wanted to say that I'm more than happy, on behalf of mozilla.org, to ensure
that aggressive favicon.ico requesting is off by default for mozilla1.0, *if*
that's the consensus of the community -- even if the module owner(s) want it on
in Netscape or a derived product.  Right now there is no such consensus.  It
isn't just the "module owners" who want favicon.ico fetching on by default, and
being self-righteous and inflammatory won't settle the dispute.

In the mean time (0.9.6-0.9.8), no baby is cut in half, so please tone down the
rhetoric, use the bugsystem properly, and start a newsgroup thread with less
heat and more light.  For instance, has anyone measured to see whether Jonas
Sicking's model for favicon.ico hits in comment #43 matches reality?  Tell us in
m.general, not here.

/be
Brendan, I have responded to your comments directly via e-mail.
I have started a thread in .general about getting this turned off.  I would 
appreciate it if some of you could reply to the post, and explain to me what the 
situation really is.  It would be nice to prove JTK wrong on this one, if 
possible.

Aaron
Ok, this is getting really annoying.  When I tried to bring up my questions in
bugzilla I was told to take it to m.general.  When I took it to m.general, I was
totally ignored.  Now I asked a very simple question to a very small group of
people, and I--some would say unrealistically--expected an answer.  If the
answer is "absolutely nothing" I will be really angry, but not as angry as I
will be if I do not receive an answer at all.

If I have to start emailing individual developers or bugging them on IRC I will
do so.  Don't bother ignoring me, because I do not plan to go away.


Aaron Andersen
www.xulplanet.com
I really don't see why there is such heated debate over favicon.ico.  Next 
thing we know, IE is going to start playing favmusic.mid as background music by 
default, some Mozilla developers will like that idea, and it gets added into 
the build.  Looks like the current status is priming things to become all set 
for another heated debate the next time this happens.  'Course, maybe this 
isn't viewed as a problem because this community doesn't at all mind having 
more heated debates :)

Shouldn't this have been done in a more general, less specific way, like 
generating a standard spot to list oft-requested files?  Right now I can 
readily think of several files every server is expected (by some people) to 
have: /favicon.ico, /w3c/p3p.xml, /w3c/policy.xml, /robots.txt.  This problem 
is only set to increase as new developments come up with new ideas for new 
files to become standard, and webmasters are likely to keep scrambling every 
time this happens.  Perhaps an entry into the robots.txt files that basically 
says, "The following are the frequently-looked-for files we have on this server 
(please don't be looking for any others)" or, alternatively, the robots.txt 
could have an entry that means the opposite ("Please feel free to look for oft-
checked files: We like having the 404's generated because it helps us learn 
about the files in the first place.  However, the following files do NOT exist 
(yet), so don't bother trying for them unless a child directory's robot.txt 
says that directory tree may have such a file.")
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: