Closed Bug 174265 Opened 17 years ago Closed 16 years ago

Wrong favicons in bookmarks

Categories

(Firefox :: Bookmarks & History, defect, P2)

x86
All
defect

Tracking

()

RESOLVED FIXED
Firefox1.0

People

(Reporter: cachapa, Assigned: vlad)

References

Details

(Keywords: fixed-aviary1.0)

Attachments

(3 files, 5 obsolete files)

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.
Attached image Picture of the bug
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 174821 has been marked as a duplicate of this bug. ***
*** 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.
OS: Windows XP → All
Summary: Bad favicons in bookmark toolbar → Repeated favicons in 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.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Status: REOPENED → 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). 
Status: NEW → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Target Milestone: --- → Phoenix0.4
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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?
Assignee: hyatt → chanial
Status: REOPENED → NEW
Component: Toolbars → Bookmarks
Summary: Repeated favicons in bookmarks → Wrong favicons in bookmarks
*** Bug 207368 has been marked as a duplicate of this bug. ***
Target Milestone should still be changed or reset...
Target Milestone: Phoenix0.4 → Firebird1.0
taking QA contact, sorry about the bugspam
QA Contact: asa → mconnor
*** Bug 216203 has been marked as a duplicate of this bug. ***
Blocks: 222104
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. 
Flags: blocking0.8?
this is not something to block a pre-1.0 release on.  1.0 would be a different
story.
Flags: blocking0.8? → blocking0.8-
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...
Flags: blocking1.0?
Flags: blocking1.0? → blocking1.0+
*** 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.
Flags: blocking1.0+ → blocking1.0?
fmannino@euristic.it, do not change blocking flags a dev already set.
Flags: blocking1.0? → blocking1.0+
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
Assignee: p_ch → danm.moz
Flags: blocking-aviary1.0RC1+
-> vlad initially. vlad, if you're overloaded, pass to danm. 
Assignee: danm.moz → vladimir
Attached patch bookmarks-favicons-fix-0.patch (obsolete) — Splinter Review
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.
Attached patch bookmarks-favicons-fix-1.patch (obsolete) — Splinter Review
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.
Attached patch bookmarks-favicons-fix-2.patch (obsolete) — Splinter Review
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..
Attachment #152269 - Attachment is obsolete: true
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 :)

Attached patch bookmarks-favicons-fix-3.patch (obsolete) — Splinter Review
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.
Attachment #152270 - Attachment is obsolete: true
Attached patch bookmarks-favicons-fix-4.patch (obsolete) — Splinter Review
Updated and fixed.  Also would fix bug 117895, bug 173762, bug 228862, and
probably a few others.
Attachment #152315 - Attachment is obsolete: true
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.)
Attachment #153379 - Flags: review?(bugs) → review+
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.
Attachment #153484 - Flags: review+
in on aviary.
Status: NEW → RESOLVED
Closed: 17 years ago16 years ago
Resolution: --- → FIXED
*** 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
Status: RESOLVED → VERIFIED
Not fixed on the trunk yet. Reopening.
Status: VERIFIED → REOPENED
Keywords: fixed-aviary1.0
Resolution: FIXED → ---
Whiteboard: needs trunk checkin
*** Bug 248032 has been marked as a duplicate of this bug. ***
Blocks: 222602
Blocks: 204393
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).
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Whiteboard: needs trunk checkin
(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. ***
Blocks: 271359
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
Duplicate of this bug: 438773
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)
You need to log in before you can comment on or make changes to this bug.