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

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.

this one needs a fix.

Isn't this a dup of bug 113102?

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.

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