120466 - favicons are placed into cache with "expire immediately" expiration date

Status: RESOLVED WORKSFORME

(Core :: Networking: Cache, defect)

Description

[Aleksey Nogin]

I am finally able to show a concrete example of cache not doing a right thing
wrt favicons.

Reproducible: always
To reproduce: 
1) Quit Mozilla 
2) Erase the contents of the cache dir
3) Start "mozilla about:blank"
(the above steps can probably be replaced with clearing both caches from the
Preferences panel, but this feels more reliable)
4) Visit http://slashdot.org/ (note the current time)
5) Go to about:cache and find the entry for http://slashdot.org/favicon.ico in
the Memory cache

Expected: favicon.ico is present in both Memory cache and Disk cache with some
reasonable expiration date.

Actual: favicon.ico is present in Memory cache with last modified = expiration =
actual time of the http://slashdot.org/ visit. It never makes it into disk cache
*at all*

I tried changing the setting for "Compare the page in the cache with the page on
the network", it does not appear to matter.

Note that if I *explicitly* visit http://slashdot.org/favicon.ico, then it gets
into disk cache with an expiration date some time in the future and
consequently, the favicon in toolbar will survive Mozilla restart *after such an
explicit visit*.

Other sites seem to have this problem as well.

Comment 1

[Aleksey Nogin]

I am currently using BuildID 2002011021 on RedHat Linux 7.2

P.S. IMHO all this mess with favicons does not belong to 1.0 - it's very visible
and gives people bad impression.

Comment 2

[John Morrison]

.

Comment 3

[Matthew Miller]

fwiw, the "visit ico explicitly" trick doesn't work for me, at least not for
slashdot. Meanwhile, some icons, like the http://www.bbspot.com/ one, get put
into the disk cache (expires Jan 28th...) just fine, and I know I never did
anything special for that site. On one of my systems, Google's icon gets cached,
on others it doesn't. Same with Sluggy Freelance, Wired News, etc. See
http://bugzilla.mozilla.org/show_bug.cgi?id=113430#c10 ....

Comment 4

[Aleksey Nogin]

Yes, there seems to be lots of other "random" things going on, hopefully if
problems like this bug will get fixed, the rest will look less random and make
it easier to fugure out what else is going wrong there...

Also, "visiting it explicitly" does not help much if you keep browsing, but if
you clear the cache, visit only one icon and then restart, that one icon usually
sticks, even for slashdot :-)

Comment 5

[Matthew Miller]

:) yeah okay that worked for slashdot. Tried it for several other of my
bookmarks, with about 80% success..... *sigh*

Comment 6

[Aleksey Nogin]

Hm, this seems to be working better with BuildID 2002011807 on RedHat Linux 7.2

Comment 7

[Andrew Hagen]

Old Summary: favicons are placed into cache with "expire immediatelly"
expiration date

New Summary: favicons are placed into cache with "expire immediately" expiration
date

Comment 8

[Chris Lyon]

*** Bug 136014 has been marked as a duplicate of this bug. ***

Comment 9

[Aleksey Nogin]

hyatt, do you thing your recent commit "Set an infinite expiration for bookmark
favicons. Not used by Mozilla (Phoenix only). r=brendan, sr=jag" 
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp#1.258
have fixed this bug?

P.S. Care to review the "bring back the favicons in Mozilla" patch in bug
143687? TIA!

Comment 10

[Andrew Schultz]

this WORKSFORME with linux trunk 2005041205
is this still a problem for anyone else?

Comment 11

[Joël Kuiper]

*** Bug 294646 has been marked as a duplicate of this bug. ***

Comment 12

[u7736]

WORKSFORME - Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 
with www.slashdot.org and www.yahoo.com

Comment 13

[AndrewM]

Given that favicons are now stored in places.sqlite (IIUC), is this bug still an issue?

Comment 14

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

This was filed against core... is a Firefox-only fix good enough?

Comment 15

[AndrewM]

Probably not, I hadn't realised that the favicon service isn't shared with SeaMonkey, so it could still be a problem. Could someone test a recent SeaMonkey build?

Comment 16

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 17

[Philip Chee]

SeaMonkey 2.1 uses the favicon service.