Personal toolbar icons are lost when mozilla is killed (or crashes). If it was only killing I would not mind. But this also includes crashes which ahppen from time to time. Reproduce: visit a page with an icon, bookmark it in Personal Tollbar folder and kill mozilla. My build: 2001120621 May be related to bug 114612 or perhaps (more likely) to 113430. I guess sthg wrong is happening with cash while the application is killed. Note that the icons where on the toolbar several days already so they could not just be in memory cache. They must have resided in The Cache already ( or may be The Cash :)
The favicons are stored in the Disk cache. Mozilla delete the cache if you crash (avoid problems with a corrupt cache file) Networking:Cache, Hyatt, Invalid ?
Then they should not be kept in cache or the cache should be better organized. Or perhaps both. I do not now how is it organized currently but with a slightest database knowledge you know that it is a bit crazy to invalidate all writes to a database which occured in the session which crashed. Just unroll the last transaction. Unrolling the whole seession sound like over kill. Additionaly it is not ony the problem of how icons look. This also generates some extra traffic in network. Should be avoided by good applications. Bear that I (and many) happen to have mozilla running for many days before it actually crashes, gets killed or is simply closed (not relevant in this prooblem I guess). Unrolling cache gathered for many days means erasing a lot. I see this becomes more a cache issue than icons indeed.
Confirmed on 20011211 06 Win2K. The icon cache should be maintained after a crash.
Status: UNCONFIRMED → NEW
Ever confirmed: true
>The icon cache should be maintained after a >crash. It's the disk cache and not a special Icon cache. And it will be marked wontfix if you mean that the cache should not deleted after a crash. (there is already a bug in bugzilla about this problem) CC Hyatt (favicon) and gordon (cache) Can you please add a short statement ?
*** Bug 113430 has been marked as a duplicate of this bug. ***
*** Bug 116783 has been marked as a duplicate of this bug. ***
*** Bug 116877 has been marked as a duplicate of this bug. ***
*** Bug 117076 has been marked as a duplicate of this bug. ***
*** Bug 117728 has been marked as a duplicate of this bug. ***
Gordon? Comments on the cache behavior?
Assignee: pchen → hyatt
The icons are also deleted after the disk cache is cleared manually via the menu. Personally I think the disk cache is the wrong place to store site icons. I would have thought that the icon should be persistant until either the bookmark it removed or the site issues a new icon.
Special treatment of the icons would probably make bug #113430 go away, too....
there should just be a "favicon"-subdir in the profile folder, in which the icons get stored.
*** Bug 118106 has been marked as a duplicate of this bug. ***
*** Bug 118354 has been marked as a duplicate of this bug. ***
Tested with Mac OS X 10.1.2 v0.9.7 build 20020010212 and Win32 on Windows 2000 professional, Mo v0.9.7 build 20020010403 through multiple intentional exits and forced quits and crashes. OSX: Once in a while loses favicons when quitting normally by selecting Mozilla -> Quit. Icons revert to default every single time that the program crashes or is killed with Apple Menu -> Force Quit. Win32: Favicons revert to default frequently when exiting normally. Couldn't make the win32 version crash as easily. Killing with task manager caused one or two icons to revert to default while the rest stayed in the desired state. I suggest marking this bug to OS: All, since it can be reproduced in Linux, Win32 and Mac OS X.
Site icons are lost even after normal exit, but only after PC restart. If I start Mozilla without computer restart, site icons are remain (tested with Mozilla 0.9.7 2001122106, Windows 95 Eng, Windows 98 Rus). May be this icons saved in the memory, but not in the cashe.
That particular problem sounds like it might be a bad interaction between Quick Launch and the cache. It seems like Quick Launch doesn't allow mozilla to shutdown cleanly when the PC is shutdown.
I cannot confirm comment #17 on Linux (build 2002010721). Icons are preserved even if I reboot the machine after closing mozilla gently. This would be very weird otherwise. Perhaps some processes/threads are not etrminated properly on Windows?
It seems that comment #18 is correct, the problem remains if Windows restart with the active Quick Launch (the Quick Launch icon shown in the tray). To avoid favicon disappearing the Quick Launch has to be closed manually before restart.
I can confirm that comment #20 (and so comment #18) are correct with 0.9.7 on WinNT. You don't have to restart to create the problem, logging out then in is sufficient, but it still boils down to a problem with quick launch.
Currently, this bug is set to depend on bug 113430. Bug 113430 bug is a meta bug. I think this bug should be set to block bug 113430. Thus, changing the bug to block bug 113430.
No longer depends on: 113430
*** Bug 122202 has been marked as a duplicate of this bug. ***
I've created a patch that adds a preference to always load the icons, even if they are no longer in the cache - see bug 116832.
Making this depend on 117895, which is for giving bookmark icons their own cache. The cache isn't maintained after a crash by design, see bug 105843.
Depends on: 117895
The bug 117895 gives one possible solution for this, but not the only one. If my patch for always loading icons off the network (see bug 116832) is accepted, this problem will also go away (at a cost of having to reget all the icons after any crash).
I can confirm that personal toolbar and _bookmarks_ icons (web site icons/favicons) are lost when Mozilla crashes (still happens from time to time) for Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3; MultiZilla v126.96.36.199) Gecko/20030314. I can say that the behaviour in comment #17 (personal toolbar/bookmark icons are lost after computer restart) may happen on Linux too. It, unfortunately, happened to me. Everything was working all right (with the exception that for some sites, most probably those with redirects, bookmarks icons appeared only after restarting Mozilla), now it doesn't. I have checked in Help/About Config, that both browser.chrome.favicons and browser.chrome.site_icons are set to true, and that in Preferences/Appereance the 'Show Web Site Icons' is checked. BTW. web site icons and favicons are displayed in tabs all right.
It's known that they are lost. The favicons are stored in the browser cache and the cache will be wiped if Mozilla crashes (to get no unkown state). see comment #1 And it should be clear that the favicons in a TAB are not affected because you load the page to get it in a tab (and that will reload the favicon) There is no reason to add a comment because the bug is clear and it's clear why this happends. This bug could be closed as invalid because it's by design. A solution would be to store the favicons in the bookmarks as data URL or use another cache (bug 117895)
OS: Linux → All
Hardware: PC → All
If this is by design, then thi bugreport should not be closed as INVALID, but rather changed priority to enhancement.
Regarding comment #28: after correcting the ownership of ~/.moxilla/registry (was root.root for unknown reason) everything works as it should, i.e. favicons in bookmarsk/personal toolbar forlder do not disappear after restarting Mozilla.
Sometimes web site icons (favicons) in personal toolbar folder (in bookmarks) dissapears for no aparent reason (no crash as far as I can tell, no cache cleaning). Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3; MultiZilla v188.8.131.52) Gecko/20030314
Jakub -- yes, that's very true, and more general than this bug. See bug #113430.
*** Bug 210480 has been marked as a duplicate of this bug. ***
*** Bug 236830 has been marked as a duplicate of this bug. ***
*** Bug 230595 has been marked as a duplicate of this bug. ***
*** Bug 250134 has been marked as a duplicate of this bug. ***
I agree with Comment #11. The web site icons should be saved in a semi permanent fashion. The bookmark pref file seems like the logical place to me. They could be updated automatically when a person goes to a web site and the icon has changed.
I think I read in another bug that David Hyatt has moved on to Apple. If this is true does this bug need to be reassigned to another?
firstname.lastname@example.org: sure, too bad the current owner is also missing, are you volunteering to fix this bug? we'll gladly help you. note that one approach to 'fixing' this is to steal the work done for firefox which bloats the bookmarks file with static copies of the icons as they were originally seen. too bad this means your icons won't update if the site updates.
Timeless: I have learned from reading Bug 117895 that there is real resistance to adding the Favicons to the bookmarks. I have since opted to back a separate Favicons file that resides next to the Bookmarks file in a persons profile folder. This seems the easiest solution, to implement and fix the bug, with the least resistance, and the least negative possible repercussions. As for fixing this bug myself? I haven't written any code in 30 years and wasn't that good at Fortran and Basic when I did.
Apparently, as of 184.108.40.206 they ARE being cached with the bookmarks, as now I've got stale/bad favicons that won't change no matter what. How does one go about getting them to refresh when they're bad? I've tried flushing the cache to no avail.
This is no longer a problem in Firefox trunk, has it been fixed in Seamonkey trunk too?
No; SeaMonkey doesn't have Firefox's favicon service.
Assignee: hyatt → nobody
Status: ASSIGNED → NEW
QA Contact: claudius → bookmarks
Target Milestone: Future → ---
(In reply to comment #44) > No; SeaMonkey doesn't have Firefox's favicon service. Neil, is this also not picked up in SM 2?
No, we still aren't using the favicon service yet, sorry.
Is there a reason, why not do dupe to bug 116832? pi
> No; SeaMonkey doesn't have Firefox's favicon service. We do now.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.