I have quite a few bookmarks in the bookmark toolbar, and most of those sites have favicons. I noticed that from a fresh install, after loading the icons for the first 3 or 4 bookmarks, the icons start to repeat through other bookmarks that also have favicons. For example, if I have mozilla.org's bookmark next to slashdot.org's bookmark, the mozilla icon will appear in both bookmarks. If I then visit slashdot.org, it's icon will then replace both icons.

They say a picture is worth a thousand words :)

Same for me on build from 20021014 on w2k.

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

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

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

Marking NEW since it is a well known bug

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

test case: http://bugzilla.mozilla.org/show_bug.cgi?id=174821#c2

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

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

This seems to happen for me if I change tabs while a page is loading. 1. I have two tabs open, tab 1 is active. 2. I start a new pageload in tab 1. 3. I switch to tab 2. 4. Tab 1 finishes loading. 5. The bookmark for the page in tab 2 acquires the favicon for the page in tab 1. Hope that helps.

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

This is not limited to favicons on the toolbar; I also see it among the regular bookmarks.

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

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

I think this sucker has been fixed.

This works for me, as of the 20021020 nightly build. However, the icons in the bookmarks toolbar are now consistently 'scrunched' a pixel or two, instead of sporadically. But that's a different bug. :)

(using Phoenix 2002-10-21-8 trunk on WinNT) Ever since Phoenix 0.3, in my Bookmark Toolbar, I have had the Slashdot favicon assigned to my Infoworld.com bookmark and just the generic favicon on the Slashdot bookmark. Now, with the 10-21 build (installed over the top of 0.3), the problem is still there. Re-opening each bookmark does not correct the favicon. Is this a new bug or a continuation of this "repeated favicons" bug? I guess I'm a little confused by this bug's Summary (and the meaning of "repeated"). Also, if the code that causes this is fixed, should my favicons auto-correct or do I need to reset them somehow?

Tony, please try a new profile and thus a new bookmark file. I'm resolving this as fixed, but reopen if you still see it with the new profile.

Michael, the bug of crunched icons in bookmarks toolbar if bug 175515, and it contains a fix (see the bug 175515 comment #2) easy to apply.

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

Downloaded latest build today. This is still happening on XP. Slashdot icon replacing others.

Additional Info. This happens Only for my Slashdot icon. I tried deleting and readding it. When I click on an favicon and then click the Slashdot icon, the previous icon becomes /. Also, not sure if this is related, but I rebooted and all icons except leftmost reverted back to default. Visiting each site refreshed the favicon.

Chris, have you removed your old profile and installed Phoenix to a blank directory? Don't use your old bookmark file.

setting status to New

This is the first install of Phoenix on This computer. I've just built it. I'll go ahead and delete entire directory and download latest build.

This is fixed. If you're still seeing it then you've got a corrupt bookmarks file. You can open it in a text editor and remove all the ICON="<url>" references or you can create a new bookmarks file. When we recommend creating a new profile we mean a new profile (that includeds files like bookmarks and cookies).

Looks Good :)

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

<DT><A HREF="http://www.yahoo.co.jp/" ADD_DATE="1052449499" LAST_VISIT="1052449750" ICON="http://www.google.co.jp/favicon.ico" LAST_CHARSET="EUC-JP" ID="rdf:#$y5cCr">Yahoo! JAPAN</A> Reproduced w/ clean profile Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030504 Mozilla Firebird/0.6

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

Reopening as I can still reproduce.

Title is not really describing the problem that well, since the icons are assigned to the wrong bookmarks, not repeated Summary should be "Wrong favicons assigned to bookmarks" And Target Milestone should be cleared or set to Phoenix 0.7 I also think this bug is missing some vital details, like only bookmarks with no favicon assigned or available gets a wrong icon. I believe I just reproduced it by opening a site with no favicon available and *while* it was loading, I loaded up php.net/manual (by clicking my bookmark), this resulted in the other site getting the PHP favicon

Tom: Yes, you are right. pch: -> Phoenix 0.7?

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

Target Milestone should still be changed or reset...

taking QA contact, sorry about the bugspam

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

Shouldn't the product be changed to Browser here, not Firebird, because Mozilla and Firebird both have the exact same problem.

Pierre, are you going to be able to look into this any time soon? We've been collecting dupes for quite a while and it'd be nice not only to get this fixed but to cut down on the noise in Bugzilla.

this is not something to block a pre-1.0 release on. 1.0 would be a different story.

This is still in 0.7, with the tabbed problem - if I load a page on one tab, and then immediately switch to another tab and click something off of my bookmarks bar, whatever I click on will take the icon of whatever I was loading on the first tab. This appears to only happen for sites that do not have an icon of their own.

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

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

i have this happening since firebird. try to erase the cache. the url http://home.uol.com.br have an favicon that apears in my others bookmarked sites: www.annbr.com www.totoronoki.com www.animesgeneration.com i think this problem is related with the cache, because, erasing the cache these icons back to normality.. but after visit these pages again,they come back. Mozilla Firebird/Firefox is assuming that the bookmarked pages are in the same server.. but it's wrong.

I suspect cache too, for a different reason. I experience this problem quite a bit with my atypical cache configuration: two of my 6 open tabs right now either have no icon where they should, or the wrong icon, and after I switched to a tab and came back to this one, the urlbar icon has been reset to the default icon rather than the mozilla icon. I use a relatively small cache size: 0 disk, 10M memory. I encounter quite a few issues which I suspect are caused by these atypical settings (and I've filed them over the paste 3 year--though I don't think any have recieved any real attention, since they tend not to hit users under the defaults). Perhaps the lizard and fox would benefit from a cache guru surfing with similar settings for a week. *I* can live with them, but it seems like the effort might be justified for the large number of polish issues it could uncover for 1.0.

Re comment #45, the icons disappear when you clear cache as cache stores a copy of the images (e.g. the .ico files). But the bug (I think) is that the individual book mark entires in the bookmarks file end up with "icon" attributes that are wrong. Its difficult to see when this happens, but I'm 99% certain I have had this happen when downloading a page in one tab and at the same time opening another and downloading another page. Both pages are being downloaded from bookmarks. However, I can't re-create this. :( The problem existed in the official Firebird 0.7, but time will tell if the problem persists in Firefox 0.8. The problem was *very* uncommon, but did happen using a fairly typical installation; Win2K, a few extensions ("Text Links", "This Window" and "Live HTTP Headers), "Luna-Blue" theme. I *did not* change any cache settings that I'm aware of.

FWIW, I've been seeing this for as long as favicons have been supported (including in vanilla mozilla, when they were briefly enabled there). I'm not overly fussed because obviously it's a pretty cosmetic thing, but eh, you know, it's not really ideal behaviour.

> Its difficult to see when this happens, but I'm 99% certain I have had this > happen when downloading a page in one tab and at the same time opening another > and downloading another page. Both pages are being downloaded from bookmarks. this happens to me with no tabs. with a single window. i just visit the bookmarked page and Firebird assumes the favicon and add to other bookmarked sites. > However, I can't re-create this. :( sorry, i just forget some informartion. ocasionaly is need to close Mozilla Firebird/Firefox and re-launch after visit/bookmark the pages that have the favicon, to icons appears on the wrong bookmark itens.

I can confirm the problem still exists in FireFox 0.8.

(In reply to comment #50) > I can confirm the problem still exists in FireFox 0.8. It still exists for .8 for me, too; eBay has its favicon, and then another site I bookmarked has eBay as its favicon instaed of its own favicon. However, the 2nd one I bookmarked (after eBay and before the other one) has its original favicon like it should. 3 more bookmarked sites after that are not displaying their favicons properly, just the default page icon (even though they should have favicons).

Yep, also getting this in completely fresh installs of Firefox 0.8 on two machines (XP and ME), and have previously experienced it in Phoenix too. The problem appears to be in bookmarks.html for me (rather than cache-related, as suggested in some posts above), with ICON= entries appearing against the wrong bookmarks. An annoying cosmetic thing, really. But cosmetics are what (dumb) users can understand...

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

Another incorrect bookmarks.html entry. Linux Firefox 0.8: % grep cnn.com .phoenix/default/xxx.slt/bookmarks.html <DT><A HREF="http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=day&mindate=&maxdate=&cvsroot=%2Fcvsroot" LAST_VISIT="1082764278" LAST_MODIFIED="1077579677" ICON="http://www.cnn.com/favicon.ico" LAST_CHARSET="ISO-8859-1" ID="rdf:#$tKhe62">Bonsai (24 hour)</A> As you can see, I don't even have any other bookmarks for a page on cnn.com. Though I can't say for certain I haven't in the past with this profile.

fmannino@euristic.it, do not change blocking flags a dev already set.

Ok, I've installed the latest nightly - 22/5/04 - and bookmarks are still being represented by the WRONG icons e.g - My "ebay uk" bookmark is represented by the bbc7 radio icon (which is also in my bookmark toolbar and has the correct icon) My Datecam icon (it doesnt have its own individual icon) is represented by an icon from the SEARCH BAR engines - the "DABSdirect" icon And finally a yahoo icon (Y!) is present not only for my "yahoo games" bookmark, but also for my "BBC News" bookmark Other icons seem to come and go, but they don't seem to be being saved...if you click on them the icon will reappear, but at startup a lot of them are just the generic bookmark icon, even if a specific icon is available.

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

(In reply to comment #56) > Ok, I've installed the latest nightly - 22/5/04 - and bookmarks are still being > represented by the WRONG icons > > e.g - My "ebay uk" bookmark is represented by the bbc7 radio icon (which is also > in my bookmark toolbar and has the correct icon) If you open your bookmarks file, it shows which favicon is stored for which bookmark. Close all of Moz, including Turbo and then Two options: 1) if possible start with a BLANK bookmark file. 2) if not possible make a backup of your current one, and edit out the wrong favicons. Start Moz again and see if the favicons are updated to their right equivalent. Trying to figure out if a) Moz still messes up favicons or b) Moz doesn't mess up anymore but doesn't clean up from earlier times when it messed up.

Yes, with {Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040607} I still get this issue. I used your '2' option; I did a search & replace to remove all the favicon references.

in firefox 0.9 this appears to be corrected after a clean install and not importing previous bookmarks. but importing old bookmark file the problem persist, because the bookmark need to be filtered to remove de old wrong-icon entries. i've made a test, removing these entries manualy using the editor "editpad" that shows html entries. - ICON="http://www.(site).com/favicon.ico(.png,.gif,etc)" - or some url like - aparently (i'm still testing) the wrong icons doesn't came back after several trip in the sites and firebird restarts. warnig - if some one try to make these modification on the bookmark file make a security copy(backup) my suggestion to mozilla developers, is to filter the bookmark to remove these icons during importing process.

The core cause of this bug may be related to something I've been seeing while working on bug 244078 -- when a page starts loading, data related to the previous page is still in attributes on various XUL elements until overwritten. The "src" attribute on page-proxy-favicon gets set in onLinkIconAvailable, so I think it's in theory possible to set a bookmark on a page before either stopping the page load or errors out (so the icon doesn't get updated like it normally would), but before the onLinkIconAvailable handler is called, thus giving you the old contents of page-proxy-favicon.src. Also might be seen more often on slow network links.

-> danm

-> vlad initially. vlad, if you're overloaded, pass to danm.

Here's a first cut at the fix. The side effect is that we now set the favicon on the bookmark whether it really exists or not; if it doesn't exist, we end up setting favicon.ico. The problem is, this causes the generic "page" icon to disappear from next to he bookmark -- you end up with no icon next to bookmarks with no favicon. I'm going to hunt down a fix for this, but I'm open to suggestions. A last resort would be to involve bug 173762 and to create a separate store/cache for favicons which would return a generic icon for invalid URLs. The cause of the bug was that the bookmarks icon was being set from the onload/onerror handler of a window-global widget; the onload handler could get called after the user switched tabs, but before a new src attribute was set on the image widget. The simplest way that I found to reproduce was to put a few bookmarks in the toolbar that have favicons (google, mozilla, slashdot, cnn) along with perhaps one or two pages that don't have favicons, open a tab for each bookmark, and then hold down control-pagedown/pageup... and watch the icons in the toolbar dance around.

Note: the patch also affects seamonkey, but those changes aren't included in the first cut. (apologies for extra bugspam)

Does this only happen for /favicon.ico icons?

The original issue affects all icons; my fix also works for both favicon.ico's and for explicit icon links. The generic-icon-disappearing issue only affects pages that have no icon link and for which the site has no favicon (i.e. where the generic "page" is displayed).

Is the issue that the load event is generated before the attribute is changed? Switching tabs should generate an onLocationChange notification which resets the icon via SetPageProxyState. Setting the location as an attribute on the image could help if somehow the location and image URL change asynchronously. However if the load event is generated for the previous source after the attribute is changed then this sounds like a bug in the image loader.

K, better fix. I'll come up with a test case for the image loader just to make sure, but I think it's just a case of stale data being passed around -- this patch ensures that data related to favicons is always passed around along with the parent URL for which the favicon URL was received, so that browser.js never has to use gBrowser.currentURI or similar. This is probably heading in the right direction for a fix to bug 173762 as well; just need to figure out where to store the received favicon data.

Hey, just my $0.02 (probably unwanted). Strangely enough, I get Yahoo's icon next to the bookmark for my bank. I haven't been able to nail down a pattern for the reoccourance of this. But I will try to post a screenshot when I can.

Let's try that again, this time with the correct attachment (i.e. one without typos). This patch will also remove incorrect favicons that are "stuck" on sites that don't have favicons of their own. Re comment #70: In theory, unless your bank is explicitly referencing yahoo's favicon, this patch should fix that issue..

Comment on attachment 152270 [details] [diff] [review] bookmarks-favicons-fix-2.patch I don't think that auto-remove is a good idea. Take this scenario: 1. You load www.mozilla.org 2. The tabbed browser sees a <link> for the icon, thus updating the bookmark icon 3. The favicon.ico load fails, thus clearing the bookmark icon... I expect you're planning on loading the icon data otherwise I would have suggesed using the link checker component.

(In reply to comment #72) > (From update of attachment 152270 [details] [diff] [review]) > I don't think that auto-remove is a good idea. Take this scenario: > 1. You load www.mozilla.org > 2. The tabbed browser sees a <link> for the icon, thus updating the bookmark > icon > 3. The favicon.ico load fails, thus clearing the bookmark icon... Yeah, I thought about that.. the right way is to keep a list of all favicon loads that are being/have been attempted for a particular URL, and then doing the right thing; in particular, <link> icons should override /favicon.ico icons. Right now the code assumes that the loads will happen in order, but that's not a generally safe assumption. I'll probably fix that today/tomorrow. > I expect you're planning on loading the icon data otherwise I would have > suggesed using the link checker component. Yep; the data will get saved somewhere, as soon as I figure out where :)

This patch fixes the issues with bookmarks favicons that I'm aware of, including this bug and bug #173762. We no longer store favicons as URLs; instead, all favicons are stored as data: URL's (inspired by Neil's original patch) that get updated whenever the page is visited (as with the current scheme). The notes from the previous patch also apply as far as fixing the desync issues. Despite my best efforts, I can't get wrong favicons to show up anywhere after this patch, and all the favicons come back after a restart, so we win. Because favicons are stored as data urls, this also neatly sidesteps the issue of https favicons, non-http favicons, etc.

Updated and fixed. Also would fix bug 117895, bug 173762, bug 228862, and probably a few others.

Comment on attachment 153379 [details] [diff] [review] bookmarks-favicons-fix-4.patch >+ if (gBrowser.mCurrentBrowser.mFavIconURL == null) { A local var browser = gBrowser.mCurrentBrowser here would make the code a fair bit easier to follow. >+ nsCOMPtr<nsIRDFNode> targetNode = do_QueryInterface(supports); >+ (void)mInner->Unassert(bookmark, kNC_Icon, targetNode); Can Unassert handle a null targetNode? You might have one here, if the QI fails. >+ if (aProperty == kNC_Icon) { >+ // if the user has favicons turned off, don't return anything >+ if (!mBrowserIcons) >+ return NS_NewEmptyEnumerator(aTargets); >+ } Combine the if predicates with &&, pls. >+ for (i = 0; i < tabBrowser.browsers.length; i++) { >+ if (tabBrowser.getBrowserAtIndex(i).contentDocument == event.target.ownerDocument) { >+ if (contentPolicy.shouldLoad(Components.interfaces.nsIContentPolicy.TYPE_IMAGE, >+ uri, origURI, event.target, >+ safeGetProperty(event.target, "type"), >+ null) != Components.interfaces.nsIContentPolicy.ACCEPT) >+ return; I know you didn't start the fire, but a const nsIContentPolicy = Components,interfaces.nsIContentPolicy; would make that code much more pleasant to read. Fix the nits, and I think you're good to go. (WTB some unit tests for favicons, PST.)

The favicons weren't being caught if the user switched to a different tab while the page was still loading; the fix is to stop using gBrowser.mCurrentBrowser, but to use whatever browser has the document for which we got the load event for.

Comment on attachment 153484 [details] [diff] [review] bookmarks-favicons-fix-5.patch It occurs to me, idly, that both favicons and tabs are hyatt's fault. r=shaver.

in on aviary.

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

(In reply to comment #79) > in on aviary. is there a reason this is not in the trunk?

verified with Firefox 0.9 branch build 2004-07-21-09-0.9

Not fixed on the trunk yet. Reopening.

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

When this patch saves the icon in bookmarks.html, it doesn't set the correct content type. It simply saves whatever the server sent. For four out of the six icons I've picked up so far, this is text/plain. It seems to me if we're making our own private copy of some data, we should be properly labeling our copy. And beyond just a correctness issue, wouldn't this be a perf win? I would guess that trying to load an image of type text/plain will force the use of the image type sniffer, whereas loading it with a correct content type would avoid that. For large bookmark files with hundreds of stored icons, having to sniff each of them at every runtime has got to cost a fair amount of cycles. Has any performance testing been done with this? Based on my rough estimates, the average BMP favicon stored as a base64ed "data:" URL is 1550 bytes more than storing an average-sized URL. My bookmarks file has 820 entries; this would increase it's size elevenfold, from 126,757 bytes to 1,397,757 bytes.

(In reply to comment #85) > When this patch saves the icon in bookmarks.html, it doesn't set the correct > content type. It simply saves whatever the server sent. For four out of the six > icons I've picked up so far, this is text/plain. It seems to me if we're making > our own private copy of some data, we should be properly labeling our copy. We can't properly label our copy until the patch for bug 247981 makes it to aviary; without it, we can't sniff the content type (wrong signatures in the idl, so we can't pass binary data from js). So we have to store whatever the server gives us. > Has any performance testing been done with this? Based on my rough estimates, > the average BMP favicon stored as a base64ed "data:" URL is 1550 bytes more than > storing an average-sized URL. My bookmarks file has 820 entries; this would > increase it's size elevenfold, from 126,757 bytes to 1,397,757 bytes. The perf hit should be minimal, but runtime memory usage will go up somewhat. There isn't really a middle ground here; we either lose favicons at the cache's whim (as previously), or we store them ourselves. In the future, we might be able to use a more memory friendly storage format than base64-encoded data: URIs (which are admittedly somewhat of a hack).

So is it worth putting either the needed-aviary1.0 keyword or requesting blocking-aviary1.0 on bug 247981, or is it something risky enough that it should be put off til after 1.0?

In on trunk, 247981 has aviary1.0 request; this -> FIXED (yes, still some small issues, but those are in other bugs atm).

(In reply to comment #88) > In on trunk, 247981 has aviary1.0 request; this -> FIXED (yes, still some small > issues, but those are in other bugs atm). Could you list the other "small issues" and bugs? Thanks.

(In reply to comment #85) > And beyond just a correctness issue, wouldn't this be a perf win? I would guess > that trying to load an image of type text/plain will force the use of the image > type sniffer, whereas loading it with a correct content type would avoid that. imagelib always sniffs the type of the data, and only uses the provided type if it can't sniff one.

Comments on the related history bug. http://bugzilla.mozilla.org/show_bug.cgi?id=221704#c6

FYI, the issue I raised in comment 85 has now been fixed as a side-effect of the patch for bug 255931.

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 Sorry, but even with the new ICON="data:..." approach it still happens frequently that bookmarks of sites without favicons somehow get associated with favicons of other, unrelated sites when both sites are opened in tabs in the same window at around the same time. Should this bug be reopened or is this issue dealt with in newer bugs such as bug 259993 which at the time of writing is unconfirmed, has only one vote and no blocking flag?

This bug hasn't been fixed. I'm still getty the wrong icons next to the wrong bookmarks and there seems to be no way to fix them currently other than delete the bookmark and readd it again.

People still seeing this problem probably still have old-style favicon references in their bookmarks.html. The old style is ICON="http://". The new style is ICON="data:". You can either hand-edit your bookmarks file and delete the old references, or use an extension like Favicon Picker to delete them. http://www.extensionsmirror.nl/index.php?showtopic=617

No, I don't have any old icons but I still sometimes get wrong icons even with this new approach. So, it's not related to that.

I'm seeing the same problem as Vedran Miletic. I checked my bookmarks.html file, and it's using the 'new' method, however there are multiple wrong icons. I've been using nightlies, and saw this start to happen within the last couple of weeks. I thought it might go away with some new nightlies, but the problem is still there. I'm using: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040921 Firefox/0.10

Although this is now much improved I'm still seeing it occasionally (my bookmarks file doesn't have any ICON="http... attributes in it). The problem seems to affect bookmarks for sites that don't have a favicon (e.g. my ve3d.ign.com bookmark is currently showing a mozillazine.org icon).

To sort of confirm what Pike said, about it happening on sites that don't have their own favicons, that seems quite possible. The last bookmark that did it for me was BBC News, which does not have an icon at all. And I /think/ the site before that was my latest-builds bookmark, (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/) which also has no favicon. (Though maybe someone should toss the Mozilla head up on ftp.moz.org?) However, I can't confirm that it's still happening, in 0.10 with a clean profile.

I've got a brilliant idea, folks... If the problem has its cause in empty ICON attribute of A tag, then the fix is pretty obvious for anyone who have his knowledge of XUL at least slightly above the zero: make all iconless websites have their ICON set to chrome://communicator/skin/bookmarks/bookmark-item.gif

based on comment 93 - comment 100 it appears that this isn't fully solved for all. Bug 271359 also reported the same problem. Instead of reopening this bug i suggest that people that are still experiencing this add their comments to bug 271359 and we'll take it from there.

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

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

I've never used this site before so maybe I misunderstand, but this bug is definitely NOT fixed for me. Since it looks like every bug related to incorrect favicons is considered a duplicate of this one, I decided to comment here rather than claim a new bug (the most recent comment here is newer than the one on 271359, sorry if I should have commented there). I didn't read every comment here but it doesn't look like anyone else has described it as follows. For me, it happens VERY reliably: 1. click bookmark for site A from bookmark toolbar 2. click link on site A to page on site B 3. once site B loads, bookmark favicon for site A is replaced with favicon for site B This was obvious to me because it only happens for one of my bookmarks, which is actually just a personal page with a list of bookmarks - whenever I access that page and click links on it, the bookmark favicon for the page changes. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.14) Gecko/2009090216 Ubuntu/9.04 (jaunty) Firefox/3.0.14 (bug still present in 3.5)

=> bug 487003