116832 - Site icons (favicons) disappear in personal toolbar [on restart, new window, etc]

Status: RESOLVED WORKSFORME

(SeaMonkey :: Bookmarks & History, defect)

Description

[Manfred Lebek]

After restart of Mozilla the favicons doesnt appear in the Bookmarks or in the
Personal Toolbar. if you select a bookmark that contains a link with a favicon
mozilla stores the icon until the next start.

Comment 1

[gavin long]

WFM, win98SE, 2001122208, 

with one exception: if the browser crashes, all the icons go.  Reporter, did you
exit the browser normally, or crash?

The favicons are stored in the cache, and at present, if Mozilla crashes, the
disk cache will get wiped (taking all your favicons with it...)

Comment 2

[Christian Reis]

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

Comment 3

[Andreas Premstaller]

Reopening since this bug is about favicons disappearing in bookmarks and
personal toolbar upon restarting Mozilla, while bug 109959 is about another
favicons in the url bar disappearing upon reload of the page.

Using build 2002011503 on W2K, I still see this problem: Favicons in the
bookmarks and personal toolbar do mostly not show up after quitting and
restarting the browser.

Comment 4

[Andreas Premstaller]

Confirming and assigning to hyatt

Comment 5

[Aleksey Nogin]

I *never* see any favicons upon start-up. Only after I visit the site again, the
icon appears. Sometimes I see it in one Mozilla window, but not the other, so
it's unlikely it has much to do with cache.

Mozilla 0.9.7 (and some later builds) on RedHat Linux 7.2

Comment 6

[Aleksey Nogin]

It seems there is still come confusion between several favicon bugs. The way I
understand it, we have (at least) 3 different bugs.

Bug 109959 deals with favicon in the *url bar*. The problem usually manifests in
favicon disappearing on *page reload* and sometimes not appearing when already
visited page is revisited.

Bug 113574 deals with favicons in bookmarks *sidebar and management window*. For
some people (including myself), favicons *no longer appear there at all, no
matter what we do*. According to the initial reporter, this may be caused by
"conversion to <outliner> which just landed"

Finally, bug 116832 deals with favicons in bookmarks *personal toolbar and menu*
- there the problem is that the favicons are not displayed when Mozilla is
started (even if the bookmarks file contains them) and only appear when the site
is visited again. It also seems that sometimes some favicons would not appear in
toolbar and menus of a newly opened browser window even though they appear in an
older window.

-----

Did I get it right this time?

Is it time to create a tracking bug to help avoid confusing different issues?

Comment 7

[Rob McMillin]

This happens to me randomly.

Comment 8

[alge]

Same as Aleksey for me: I never see 'em on startup.
And, they never show up when creating a new window.

Obtw: _one_ icon sticked over a startup _once_, when upgrading from one nightly
to another. Not able to reproduce.

Comment 9

[Rob McMillin]

Based on comments here, I don't think what's happening to me is the same thing
as this bug, though it may be related.  My config is Linux 0.9.7.  I opened bug
120303 for the problem I'm seeing.

Comment 10

[Aleksey Nogin]

See bug 120466 for a description of an underlying cache problem that causes
favicons to stay out of disk cache (and, as a result, disappear on restart).
Notice that if you go visit the favicon URL explicitly (e.g. go to
http://slashdot.org/favicon.ico ), it will make it into the cache and will have
a chance to survive a restart (my experience - sometimes it survives, sometimes
it does not - probably there are some other problems here as well).

In general, I believe we have 3 ways (not necessarily disjoint) of combatting
the disappearing favicon problem:
1) Keep favicons in a separate place, not in cache (bug 117895)
2) Make sure that favicons are cached properly (bug 120466, bug 113340).
3) Change toolbar code so that favicons are requested from the network when they
are not in cache.

IMHO, the best approach would be to do (3) and also (2) to make sure that
favicons are only requested from the network when it is really necessary.

Comment 11

[Aleksey Nogin]

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

Comment 12

[Matthew Miller]

re comment #10 - I've got reservations about option 3, especially if 2 isn't
fixed really well. I don't want my browser hitting the icons for all (or almost
all) of my bookmarks every time I open a new browser window! Even if 2 is fixed,
having that happen every time I clear my cache (or if I copy my bookmark file to
a new machine) doesn't seem right.

Also, can we change the summary to remove "after restart"? Restart really has
little to do with it -- that's just one case of "new browser window".

Comment 13

[Aleksey Nogin]

With BuildID 2002011807 on RedHat Linux bug 120466 does not seem to be there
anymore, so *some* favicons now survive the restart, still not sure why not all
of them do...

Comment 14

[Andrew Hagen]

Old Summary: After restart the favicons doesnt appear in the bookmarks toolbar
and menus

New Summary: After restart the favicons don't appear in the bookmarks toolbar
and menus

Currently, this bug is set to depend on bug 113430. Bug 113430, however, is a
meta bug. I think this bug should be set to block that meta bug. Thus, changing
the bug to block bug 113430.

Comment 15

[Matthew Miller]

Fixing the grammar in the summary is nice; fixing the summary to change "After
restart" to "On opening new browser window" would be nicer. :) This is a key
fact that was clear in bugs that were marked as dupes of this one.

Comment 16

[Andrew Hagen]

Re: last comment.

I can't figure out how to reproduce the problem when "opening new browser window." 

I bookmarked Slashdot.org, went to Manage Bookmarks and moved Slashdot.org to
the top of my bookmarks list, closed Manage Bookmarks, opened the bookmarks
menu, saw that the Slashdot favicon appeared, closed the bookmarks menu, opened
a new window, opened the bookmarks menu, and saw that the Slashdot favicon appeared.

Comment 17

[Matthew Miller]

In that case, it's likely that that icon happened to "stick" for you. For some 
unknown reason, some icons do sometime. (Not consistantly for a given site for 
different browsers, unfortunately. Appears pretty random.) Note that the icon 
will still be there in your old window -- it just won't be in your new window. 
Try it with some more sites -- the problem will appear.

Comment 18

[Matthew Miller]

(Actually, for icons that exhibit the problem, moving the associated bookmark
around in the bookmark menu causes the icon to disappear.)

Comment 19

[Eugene Savitsky]

I do not know if this is releted, but may it be related to that I do not have
much of histpry after moz restart? I visit sites, but after restart they're not
in history...

Comment 20

[Eugene Savitsky]

Since this was moved to the Future I suggest to exclude favicon feature out from
MachV.

Comment 21

[Aleksey Nogin]

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

Comment 22

[Aleksey Nogin]

Changing summary based on Matthew Miller's suggestion to include both "restart"
and "new window".

Comment 23

[adam conolly]

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

Comment 24

[Chris Lyon]

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

Comment 25

[Olav Vitters]

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

Comment 26

[Chris Lyon]

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

Comment 27

[Aleksey Nogin]

Attachment: Adds a preference to always load icons, even if not in the cache.

This patch adds a preference (false by default) that would get all the icons
for which we already know the URL (e.g. all of them, except for doing
/favicon.ico on-the-fly) even if they are not currenly in the cache.

This assumes that favicons are back into toolbar menus (e.g. attachment 74530 [details] [diff] [review]
on bug 113574).

It's so nice to finally see all the icons probperly displayed in toolbar (even
if some of them are displayed empty at first for a few seconds while the icon
is loading)!

Comment 28

[Matthew Miller]

Hmm. I don't think that go in until the root problem (icons not getting into the
cache, or not staying there very long if they do) is solved....

Comment 29

[Aleksey Nogin]

That's the idea behind making it a preference - we can keep looking for a way to
make icons stay in cache longer, but those who reallt want to see the icons no
matter what can turn on the preference. Eventually we might change the default
to true - uless we end up doing some special caching arrangements for favicons,
they still need to be loaded off the net once they expire from the cache.

Comment 30

[James Ross]

With regard to comment #27, have you considered sites that use the LINK tag to
'relate' an icon to them? I can't really see how we could cope with the LINK
thing, without storing the icon's URL with the bookmark - which would be a
/little/ excessive.

Comment 31

[Aleksey Nogin]

James, icon URLs are *already* stored in the bookmarks (both for link rel and
/favicon.ico that we know to exist), and these are the only ones that my patch
supports!

Comment 32

[James Ross]

Wow. I'm sorry, I had no idea how much bloat bookmarks had... ;)  (but it is by
far the most logical way to do it) and thanks for poitning that out.

Comment 33

[Aleksey Nogin]

BTW, Mozilla RPMs (RedHat Linux packages) with this patch included are
available. Browse at http://nogin.org/RPM/untested/moz/ByDate.html or go
directly to the download location at
ftp://ftp.cs.cornell.edu/pub/nogin/unsorted_RPMs/mozilla/ 
Do not forget to add

user_pref("browser.chrome.always_load_icons", true);

to your prefs.js to see the patch in action.

P.S. As an additional benefit, my builds also come with a spellchecker (see bug
56301 and http://spellchecker.mozdev.org/)

Comment 34

[Greg Valure]

Renaming some bugs to cut down on confusion, per comment 6.

Comment 35

[Aleksey Nogin]

Reducing confusion is good, but we still need the keywords in description to
avoid dups.

Comment 36

[Aleksey Nogin]

Comment on attachment 76974 [details] [diff] [review]
Adds a preference to always load icons, even if not in the cache.

See Attachment #101582 [details] [diff] to Bug #143687 for a new version.

Comment 37

[[e-mail]]

Would not solution 1) in comment #10 be the right way how to deal with site
icons in bookmarks and toolbars? I think what a user wants is that the site icon
and the URL form an inseperable pair, so the site icon can be used as a quick
visual clue for finding the right URL. Hence the site icon should be stored
permanently as long as the URL is included in the bookmarks or the toolbar. Not
even "clear cache " should affect that. Reftching the site icons from the net is
a very bad solution, because that would mean to refetch a *lot* of icons after a
clear cache operation. IMO, a cache is not for storing things, but for caching
things, but these icons need to be *stored* :)

Comment 38

[Aleksey Nogin]

> Would not solution 1) in comment #10 be the right way how to deal with site
> icons in bookmarks and toolbars?

If you are willing to ignore all the expiration data in the HTTP header, always
show the old icon and never refresh it (at least not until the bookmarked URL is
visited again).

Comment 39

[Paul Baker]

That works for me actually. That is the best that can be expected really. I
think whoever has the know how to implement it, should.

Comment 40

[Aleksey Nogin]

> That is the best that can be expected really.

This is just not true - my patch in bug 143687 allows configuring Mozilla so
that icons are re-downloaded as necessary. Works quite good.

> I think whoever has the know how to implement it, should.

First icons should be brough back (see bug 143687). Without that making them
better is irrelevant since there is nothing there to make better.

Anyway, can somebody please review my patch in bug 143687? Pretty please!

Comment 41

[Matthew Miller]

The site icons are back in the bookmark manager at least, but this problem still
exists exactly as before, because there's been no change in bug #113430, the
underlying caching problems.

Comment 42

[Jason Barnabe (np)]

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

Comment 43

[Aleksey Nogin]

Now that my fix to bug 143687 was finally checked in, one can make icons more
persistent by setting

user_pref("browser.chrome.load_toolbar_icons", 2);                             
     

Comment 44

[Ian Tommins ('thelem')]

Removing blocking1.7 flag which recently replaced blocking1.8a1, and adding
blocking1.8a1 back.

1.7 is currently at RC2, that is there are a few (<20) critical/blocker bugs
which need to be fixed before it is released. This is no where near critical,
and could even be considered an enchancement. 

Comment 45

[Michael]

No, this isn't critical, but it is highly annoying and should be fixed.

Comment 46

[Andy Boze]

Site icons work fine for me, except when I start Navigator from Quick Launch. When I start Navigator from Quick Launch, site icons no longer appear on the Personal Toolbar or in Bookmarks, though they do appear in the Location bar and on Tabs. If I close SeaMonkey and then exit Quick Launch, the next time I start SeaMonkey, the site icons reappear in Bookmarks and Personal Toolbar.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060228 SeaMonkey/1.5a

Comment 47

[Boris 'pi' Piwinger]

Coming back to it after five years ...

It is worse than that. Actually, the site icons are away after restart. Right.

I mostly open my browser while the computer is offline (SeaMonkey is not set to offline which does not make any sense for me), often I need to enter some log in to local network before being online to the internet. So obviously favicons are not loaded (as we know they are not cached properly). Now when I get online it still fails.

Further, if I expand the bookmarks menu or sub-menus in the bookmarks the icons are loaded there. This is also true for the folder called "Personal Toolbar Folder". But at the same time the exact same entries in the actual personal toolbar are not updated which is strange, they should be identical.

pi

Comment 48

[Philip Chee]

Boris, what version of SeaMonkey are you on? Can you test with SeaMonkey 2.1b2pre?

Comment 49

[Boris 'pi' Piwinger]

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.16) Gecko/20101123 SeaMonkey/2.0.11

I will try newer versions soon.

pi

Comment 50

[Boris 'pi' Piwinger]

I tried the latest version. I am shocked. It killed all the bookmark setup. Looks a bit like following the mistakes of Windows 7 and Internet Exploder. Anyway, no bookmark icons appear at all anymore. So not solving the problem, only making it harder.

Since also add-ins did no longer work I rolled back immediately.

pi

Comment 51

[Philip Chee]

Now using the favicon service so resolving as WORKSFORME.

Please reopen if you still see this problem in SeaMonkey 2.1b3