111901 - not caching (negatively) http://bugzilla.mozilla.org/favicon.ico

Status: RESOLVED DUPLICATE of bug 116801

(SeaMonkey :: UI Design, defect)

Description

[John Morrison]

I'd noticed this earlier, and I was just looking at this again. I have a simple
proxy server that shows me when I am making (possibly redundant) requests for 
/favicon.ico. (If you need to use it, I can set you up, although you can probably 
see this easily enough with the appropriate breakpoint).

If I create a new profile, and go to http://bugzilla.mozilla.org/ and pretty
much any of its subsidiary pages and forms, I am always sending out another request 
for /favicon.ico. When I look in about:cache, there is no entry (either positive 
or negative) for http://bugzilla.mozilla.org/favicon.ico.

[Guess: since the bugzilla pages contain '<link rel="icon"
href="http://mozilla.org/images/mozilla-16.png" type="image/png">', perhaps
the cross hostname nature is confusing the negative caching logic].

Comment 1

[David Hyatt]

This is because I abort the favicon.ico load (which defeats all caching).  I
need to get support for some sort of "headComplete" DOM event, so that I can
only start fetching favicon.ico *after* I know there are no link rel=icon tags
on the page.

Comment 2

[John Morrison]

this one needs a fix.

Comment 3

[Stefan Moebius]

Isn't this a dup of bug 113102?

Comment 4

[John Morrison]

Heh, well given that I filed both bugs, and my last comment in bug 113102
is "Pages with '<link rel="icon...' are a _completely_ separate issue.",
then, um ... no.

Comment 5

[Aleksey Nogin]

Bug 116801 calls for not requesting /favicon.ico at all when <link rel="icon"
...> is present, which would make this bug to go away as well.

*** This bug has been marked as a duplicate of 116801 ***