Closed Bug 173762 Opened 22 years ago Closed 20 years ago

Favicons are forgotten after shutdown

Categories

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

Product:
Firefox
Component:
Bookmarks & History
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox1.0

People

(Reporter: andre.bugs2, Assigned: vlad)

References

(
URL
)

Details

(Keywords: fixed-aviary1.0, meta) 

After shutting down Phoenix the favicon for the website www.helixcommunity.org
is no longer present on the bookmark menu. The rest of the bookmark favicons are
still intact.
In the source code of the webpage I can see:

<link rel="shortcut icon" href="http://www.helixcommunity.org/favicon.ico"
type="image/x-icon">
There is the same bug for http://www.allocine.com/ : the favicon is here while
browsing, but it's no more there if you close/re-open the browser.
Allocine.com do not use the <link rel="shortcut icon" ... /> stuff, they just
have a favicon.ico in their web root directory.

Btw, I wonder if this is related to bug 109959, bug 113430 or bug 116832.
I filed this bug here because I know that Phoenix handles favicons differently
than Mozilla.
I think this is the case with most or all favicons in a fresh profile with
today's build.
*** Bug 173816 has been marked as a duplicate of this bug. ***
-> hyatt
Assignee: chanial → hyatt
I can see this bug on with many sites Linux Phoenix Build 20021012. And still
applies after trying a new profile.
*** Bug 178510 has been marked as a duplicate of this bug. ***
Renaming bug to make this cover all favicon lossage type of problems.
Summary: Favicon is forgotten for helixcommunity.org after a shutdown → Favicons are forgotten after shutdown
*** Bug 178214 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021119 Phoenix/0.4

Definately verified on latest builds. I'm losing favicons left and right; most
annoying has to be on the Bookmarks Toolbar (which I just started using) where I
like to use only the Favicon to identify the shortcut. I'm also losing them in
the Bookmarks all of a sudden where before I was not.

The favicon comes back after you go the site, but disappears again when
reopening phoenix. It seemed to work for a little while, but no longer. I'm not
sure what caused the change. No sites were unaffected by this; all were reset to
the default icon.
favicons are stored in the cache. If you lose you cache (a crash, clearing,
setting to size 0, whatever) then you'll lose your favicon images until you next
visit the site.
Severity: normal → minor
Yes, it would be understandable to have this happen when the browser crashes,
etc, but just shutting down Phoenix normally and then restarting it causes the
favicons to be lost sometimes as well.  This is much more frustrating.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021230 Phoenix/0.5

Normal use , no crashing , no clearing and a 50MB cache to store it all .. still
isn't enough to ensure your favicons won't go away.

It just happened to me again .. for all of the stored favicons.

Wouldn't it be better to store favicons seperatly along side the bookmarks file ?

And should the OS on this bug be changed to All as it doesn't just affect Linux ?
OS: Linux → All
*** Bug 191542 has been marked as a duplicate of this bug. ***
*** Bug 184264 has been marked as a duplicate of this bug. ***
I have always gotten the same problem whether I am using windows or linux. 
However I just downloaded the nightly binary for linux from 2003-04-16 and now
it seems to haphazardly save the favicons.  It doesn't seem to work every time,
but after many attempts to open phoenix, click on a bookmark (and get the
favicon to show up) then close out and re-open, I now have a set of favicons
that have come up after a close and re-open.

So it seems work is being made on this, but it's definitely not flawless at this
point.
Hello,

I'm adding this, cause it might be related:
Windows 2000Pro / Phoenix 0.5 and Firebird latest nightly

(i) write page.html:
     ...
     <link rel="shortcut icon" href="icone.ico" />
     ...
(ii) Open in Phoenix file:///c:/page.html
     The icon just flash in the location bar, and most time disappear (randomly:
you might need to open it one or two times)
(iii) If you open http://localhost/page.html (Apache 2.0.45):
     Same problem: the icon just flash and disappear.
(iv) This happens whatever the icon filetype, path...


Note that it only happens accessing the filesystem / localhost, never on the web.

This is not a Bookmark problem, but might be related, I don't known.

Thanks.

            Olivier
the curent MozillaFirebird release 0.6 is constantly loosing favicons, esp.
those on the toolbar, too!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla
Firebird/0.6.

Ditto. No matter what I do, all favicons are lost after a reboot.
This applies to me too, brand-new install of Firebird 0.6 on WinXP, no favicons 
saved after reboot. And I agree with Christian Jensen's remarks about the 
favicon location...
Target Milestone: --- → Firebird1.0
taking QA contact, sorry about the bugspam
QA Contact: asa → mconnor
Why is this bug of 'minor severity'? I find it very annoying. Since it's
completely reproducable, applies to all new versions and has 30 votes, I'd say
it's importance should go far up. 
Dominik, the severity rating is not a measurement of priority.  Severity
reflects how much this affects operation or performance of the program.  See
http://bugzilla.mozilla.org/bug_status.html#severity for how this works in practice.
Thanks, I didn't know that. How come priority isn't set then?
Priority isn't really used within Firebird, targets are.  This is targeted to be
fixed before 1.0, but that's pretty open-ended, as fixing this is probably going
to require a rewrite of how favicons are stored.
*** Bug 215052 has been marked as a duplicate of this bug. ***
I'm not seeing this anymore with Firdbird 20030903 on Linux, and I did before on
a regular basis.
Hardware: PC → All
Verified this problem on latest FB GTK2/XFT build. Using bookmark toolbar,
favicons in the toolbar not saved upon shutdown.
Using aebrahim's P4 optimized builds, I'm seeing this too. Using his Athlon XP
build on my desktop, I'm not seeing this.

Going to try official build.
Verifying existence of same bug in Mac OSX (Clearing the browsers cache also
clears all bookmark icons).  Not integral to performance, just slightly annoying
when trying to spot ID links on the toolbar.
Build info:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031003
Firebird/0.7  ** Mac OS 10.1.5 **
Blocks: 222104
The same kind of things happens to me too, but this has a slightly more annoying
impact on user interaction. 

I have in my bookmars a link to an https:// site, with a favicon. For some
reason, the favicon disappears on Firebird restart (like other people). The main
issue I have (I don't really care about the favicon disappearing from the
bookmarks in itself), is that when I open the bookmarks menu, Firebird attempts
to redownload the favicon and thus asks me for username and password for this
site, even when I don't intend to go to that site.
*** Bug 226493 has been marked as a duplicate of this bug. ***
Flags: blocking0.8?
This happens with locally stored icons as well, set using the Extra tab on the
properties page of a bookmark. I'm speaking of favicon.ico files stored in a
separate folder on the local harddrive, not in the local cache. After a clean
shutdown of Firebird, and then a clean shutdown of WindowsXP, upon startup the
icons do not show on the bookmarks toolbar. Clicking on one or more of the
bookmarks usually brings some or all of the icons back.
Darin, any ideas?

/be
unless there's a patch for this, it won't make 0.8
Flags: blocking0.8? → blocking0.8-
Dupe 116832 or 117895 ?
no, bookmarks is forked, so this has to stay open
*** Bug 240429 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040413
Firefox/0.8.0+

The favicons are also lost inside a current session. This behavior occurs not
everytime so it's hard to reproduce. If I open the Bookmark Sidebar and select a
bookmark inside a folder which has actually no icon this will be loaded when
opening the page. When I close and reopen this folder the bookmark is gone. I
tried it several times with the same result. Because I'm using the prefbar I
pressed the "Clear All" button where following functions are called:
clearLocationBar() and clearHistory(). After this action I can't reproduce the
bug described above. So one of this functions will solve the bug but which one I
don't know. I have to wait for the next occurence.

How should the summary be updated? Should we leave it as it is and I file a new
bug or shall we remove "after shutdown"? 
Bug appears again and I realized that clearLocationBar() will help. After
calling this function the favicans are displayed automatically inside the sidebar.

Following code is called:

   var classID = Components.classes['@mozilla.org/browser/urlbarhistory;1']
   var urlbarHistory = classID.getService(Components.interfaces.nsIUrlbarHistory)

   urlbarHistory.clearHistory();
   navigator.preference('general.open_location.last_url', '');


I hope this information will help to track the bug...
for some reason, the helixcommunity favicon appears to be ending up in the
memory cache only.  i haven't figured out why it isn't getting stored in the
disk cache.  also, i never see it appear in my bookmarks listing.  however, i do
see it in the ULR bar.
duh!  the problem here is that www.helixcommunity.com is a HTTPS site, and we
only cache HTTPS items in the memory cache.  you can workaround this bug by
enabling disk caching of HTTPS content, but i don't think we want to enable it
by default.
the pref is:

  user_pref("network.http.disk_cache_ssl", [true|false]);

IMO, this is a site bug.  it should not be serving up favicons over SSL.  what's
the point?  from a browser point of view, we have to assume that this icon is
somehow "sensitive" data.  if we store it on disk, then we are violating our
policy of not storing "sensitive" data on disk without explicit user consent.

i'd recommend turning this bug into a site evangelism bug.
It's not a bug in the site darin - favicons live at the root of the domain by
default (that is, if no <link> tag specifying one elsewhere is found) and it
looks like the entire domain is https, so one would assume that the favicon is
found at https://www.helixcommunity.org/favicon.ico

This probably affects other sites too. 

I wonder if it's worth creating a separate, less volatile caching mechanism for
favicons, given the reliability problems...
Ben,

How can the browser know that the site doesn't consider the favicon sensitive
data?  The site is serving it over SSL.  That means it is sensitive data.  Is
there a spec somewhere that says that favicons served over SSL should not be
considered sensitive data?  I doubt it.  Should we really invent such a rule?

I call this a site bug because the site can easily include a <link> header that
points the browser to a non-SSL site.  Doing so avoids ambiguity from a security
point of view.

I'm arguing this point from the stand that SSL content is SSL content for a
reason.  It seems risky to special case some SSL content.

I know we're only talking about an icon here, but I'm not sure I feel
comfortable assuming that it won't contain or represent something potentially
sensitive.

I seem to recall that Camino refreshes site icons in its bookmarks panel using
some kind of periodic algorithm.  (Or, maybe sfraser was just toying with the
idea.)  Perhaps something like that would be appropriate for Firefox?
Summary: Favicons are forgotten after shutdown → Favicons are forgotten after shutdown if served over HTTPS
I'm sort of half-reading bugmail today, but who morphed this to be just HTTPS?  
the "after shutdown" loss case also happens in cases of improper 
shutdowns/crashes where we flush the cache completely.  This then affects ALL 
favicons, not just ones served over SSL, and is a much bigger concern to most 
users.

whether to consider HTTPS favicons protected aside, creating a fixed store that 
refreshes periodically would prevent a lot of these reports.
Regarding the summary change (old summary was "Favicons are forgotten after
shutdown"), I don't think that's a fair summary of this bug.

Favicons don't only disappear after shutdown for https sites.  On my copy of FF
right now, the Slashdot and FreshMeat bookmarks have forgotton their favicons,
and neither of these is https.  Further, the site in comment 2 and the two dups
in comment 15 and comment 16 don't necessarily involve https.

Probably a new bug should be opened for either the https-specific case or for
the general case.
Unabashed personal opinion follows:
Favicons ought to be treated the same way page titles are (for purposes of
bookmarks, at least) - just another bit of information *permanently* associated
with a saved URL.  It doesn't matter how you got it - http, https, ftp, or
through a dialog in the bookmark properties editor: once associated it really
ought to stick forever unless the user clears/edits/refreshes it.  I see no need
for any sort of automatic refresh... A bookmark's icon ought to default to a
page's favicon when (and only when!) the bookmark is saved.  It really ought to
be stored *in* the bookmarks files, too (see bug 228862, for instance).  Caches
are for speeding up things that are normally slow when you are doing 'em lots of
times - not for implementing competatively important features (gloss or not).

Ok - so what if you got it over https?  if the user bookmarks it, she's
perfectly well aware that she is saving the association between the url and what
she *sees* in the title line (that is the point of a bookmark, after all!)  If
it has an icon, then that *must* be saved along with that association or you are
violating the user's expectations.
Yeah, don't morph bugs.  Do reassign this, hyatt is not working on it.  Do file
a new bug.  But since I'm going to forget this if I don't braindump it, I'll
blab here on the morphed-to topic, briefly.

Darin, SIAK: favicon fetching is an MS hack where the browser, with no advice or
direction from the site via protocol headres, links, or other content tags,
tries to fetch something from the top of the server's doc tree.

Maybe we should hack on MS's hack to transliterate https to http?

What does IE do?  (Let me guess: caches https: fetched data on disk...)

/be
OK, I seem to have gotten everyone excited! :)

1) The original URL is a https:// URL.  That's why i corrected the bug summary.
 If you load http://www.helixcommunity.org/, then it will redirect you to
https://www.helixcommunity.org/.

> What does IE do?  (Let me guess: caches https: fetched data on disk...)
2) Yes, IE places HTTPS content in the disk cache (last I checked anyways).

3) What about a browser crash causing the disk cache to be invalidated.  Right,
that is another thing that impacts favicons not being remembered.  That's
unrelated to the HTTPS issue.  You could certainly kill both birds with one
stone depending on how you go about fixing the bugs.

4) I cannot reproduce the problem described in comment #2

So, maybe some of the dupes are wrong, or maybe this bug morphed into a META
bug.  Maybe I am wrong to focus on the original bug report.  Let's see what the
dupes look like:

bug 178510 has no useful information.  No link to a site that doesn't work.
bug 173816 mentions a problem with www.google.com.  I cannot reproduce the problem.
bug 178214 mentions the crash-induced favicon bug.  Maybe that shouldn't be
marked a duplicate?
bug 191542 mentions a problem with shacknews.com.  Like www.google.com, I cannot
reproduce the bug.
bug 184264 mentions the problem where the cache fills up causing favicons to be
evicted.  Maybe that also shouldn't be marked a duplicate?
bug 215052 gives no links.
bug 226493 mentions www.google.com again.  it should really be a duplicate of
bug 173816.
bug 240429 mentions the general problem of all the favicons in the bookmarks
having dissappeared.  it is likely a duplicate of bug 184264 or bug 178214.

So, it sounds like we really have the following problems:

(1) bookmarked favicons are not saved if transfered over HTTPS
(2) bookmarked favicons may dissappear if evicted by the cache due to the cache
filling up
(3) bookmarked favicons may dissappear if evicted by the cache due to the cache
being cleared (either explicitly by the user or as a result of a browser crash)

#1 is the original problem described in this bug.
#2 is bug 184264.
#3 is bug 178214.

Perhaps all of these problems would be best solved using the technique of saving
a data: URL in bookmarks.html.  I agree that persisting a HTTPS favicon is ok if
the user bookmarked the site.

I would also add one more problem (that I have noticed), and that is the fact
that the favicons do not get added to the bookmarks view until I restart the
browser and click on the bookmark.  After that the favicons remain (subject to
the above list of factors).

As for how best to triage, my suggestion would be to separate out the three bugs
since they are different problems for sure.  A real META bug might be ideal in
this situation.  Also, I'd mark these bugs dependent on the bug that is about
storing data: URLs in the bookmarks.html file.  But, maybe someone has a better
idea of how to triage this bug.
URL: https://www.helixcommunity.org/
BTW, i don't know that the data: solution is so ideal.  what happens when the
site changes its favicon?  if we go with a solution that walks the list of
bookmarks, updating favicons periodically, then i think we'd have a much better
solution.  as startup, we could walk the list of favicons, reloading each one at
a time in series (not in parallel since we don't want to clog the network
connection).  in most cases, the loads will be satisfied by the cache.
Re comment 51:  when a site changes it's favicon, IMHO, the bookmark should (by
default) remain unchanged, precisely as the text of a bookmark is left unchanged
if a url's title later changes.  It would be a useful to write an extension
which scans your bookmarks looking for updated icons, but, frankly, I wouldn't
use it.  I've got a few hundred bookmarks - I'm sure I'm not alone.
Darin, currently every time we fetch a favicon for a page that happens to be
bookmarked then we update the bookmark with the favicon URL. In one of the many
duplicates I wrote a JS hack to update the bookmark instead with a data: URL
generated by reading the favicon out of the memory cache - well I opened a
channel hoping that the icon will be in the memory cache so I didn't bother
about async reads or stuff ;-)
(In reply to comment #52)
> Re comment 51:  when a site changes it's favicon, IMHO, the bookmark should (by
> default) remain unchanged, precisely as the text of a bookmark is left unchanged
> if a url's title later changes.

Well, the favicon has an URL, whereas the title of the page does not.  Moreover,
the title saved in bookmarks might have been edited by the user.  The user
cannot edit the favicon.  So, I don't exactly see the parallels between the two.

At any rate, my point about it being difficult to update data: URLs is
apparently moot since Neil says he has a patch! ;-)

(In reply to comment #54)
> Well, the favicon has an URL, whereas the title of the page does not.  Moreover,
> the title saved in bookmarks might have been edited by the user.  The user
> cannot edit the favicon.  So, I don't exactly see the parallels between the two.

Hmmm - you are focused on the implementation, not what the user sees.  The
"least surprising behavior" here (IMHO) is when you drag the little favicon from
the address bar to your bookmarks (or whatever), the title and icon go with it
and stick forever until you change it.  Like it or not, an informal poll of
clueless users (sorry, only had a few handy) would seem to agree.  See, that's
the problem - we've set it up so that it *really* looks like it is part of the
bookmark, so people get upset when it doesn't act like part of the bookmark.
You shouldn't change the title of this bug because this behavior happens to 
non-HTTPS urls as well. That is why I voted for this bug. If you change the 
title you might as well clear all the votes because people didn't vote for an 
HTTPS specific bug, they voted for favicons disappearing. 

You should note that it happens consistently with HTTPS urls, but it also 
happens inconsistently with HTTP urls. When I do a normal shutdown, the Google 
icon stays but my Slashdot icon disappears. This Slashdot link is not HTTPS.

Either change the title back to cover both cases or create a new bug, one for 
HTTP and one for HTTPS.

ok ok, lets do this:

- revert title to original issue, and turn this into a meta bug (which it sort 
of became anyway)
- split off each of the individual issues into independent bugs blocking this
- actually decide how to handle each of these (i.e. figure out the 
implementation details)

I'll file the appropriate bugs after work tonight, unless someone beats me to 
it.
Keywords: meta
Summary: Favicons are forgotten after shutdown if served over HTTPS → Favicons are forgotten after shutdown
Depends on: 240792
to keep things clean, I split off the issues into the following bugs:

bug 240792 for the HTTPS storage issue (which blocks bug 133755)
bug 240794 for the reliance on cache problems
bug 240795 for the persistence/refreshing issue, i.e. should we replace the icon
if the site changes theirs, this should be addressed for any solution to the
first two

-> default owner/QA
Assignee: hyatt → p_ch
Depends on: 240794, 240795
*** Bug 204421 has been marked as a duplicate of this bug. ***
Hi all. Two comments from a non-developer firefox fan:

1: First, it's nice to see this bug getting some attention. I do 90 percent of
my surfing from a series of folders on the URL bar. Right now the bookmarks in
the folder are a mishmash of favicons and blank page icons. As one person here
pointed out, that is not how a new user *expects* things to work.

2. That sort of feeds into my next point. It might be nice if favicons somehow
automatically updated themselves when a site updated them, but on the other
hand, a) it sounds like it would involve significant code-bloat, and b) is it
really going to make any difference to the average user? I think most of us
would be perfectly happy with one icon that stayed put -- in fact, many of us
would be *happier* if our browser let *us* decide, rather than letting the site
force icon changes upon us.

Just my thoughts. I'm not an expert, so in grand old internet fashion, feel free
to rip me a new one  :^)
Flags: blocking1.0?
+ing, a big visual issue.
Flags: blocking1.0? → blocking1.0+
-> danm.
Assignee: p_ch → danm.moz
(In reply to comment #62)
> -> danm. 

I'm confused.  What?
(In reply to comment #63)
> (In reply to comment #62)
> > -> danm. 
> 
> I'm confused.  What?

The Assigned To changed to Dan M.
Flags: blocking-aviary1.0RC1+
hot potato, hot potato.

-> vlad initially. vlad, if you're overloaded, pass to danm.
Assignee: danm.moz → vladimir
*** Bug 249631 has been marked as a duplicate of this bug. ***
A version of this already seems fixed in the trunk -- bug #143687 has an
additional pref.  Right now, we pretend like there is no icon attached to a
bookmark if it's not in the cache; the patch from 143687 adds a pref to control
this (whether to go out to the network to fetch favicons if they're not cached
or not).  Would merging this be a fix for this?

Otherwise, my thinking is to encode the current favicon in a data url upon
serializing bookmarks.html, and to ensure that the cache entry exists for the
data upon reading bookmarks.
The patch for bug #174265 fixes this issue.
Status: NEW → ASSIGNED
Hi,

For Windows 2000
remove the following extension: Add Bookmark Here 0.5 By Daniel Lindkvist 

For Windows XP SP1 and others
Possible Firefox is double encoding the URI when saving the image location.
Saves the name with %20%20 (double space).
When it goes to retrieve the image from the cache it is %20%20 instead of just %20.
The extra space causes it not to be recognized.
So you decide to clear the cache. Great idea. You are now back to the original
link, so of course it recognizes it. Until Firefox tries to save the image again
of course.
The endless cyle continues.

Try this with a favicon:

Have one favicon located in the home directory
of your website and watch the behavior when
you load the home page

Then try to specify where it is explicitly with:
<LINK REL="SHORTCUT ICON" HREF="http://www.yourdirectory/images/favicon.ico">
between the <HEAD></HEAD> tags.

If you change the favicon and clear the cache, the new favicon will appear in
all instances.
If you change the favicon, refresh the page, and don't clear the cache, the favicon
will seem to disappear but "only from the address bar" because the browser still
has it loaded in the other menus.


Thanks
Dan McTaggart
dan@websitepromotion.ws
http://www.websitepromotion.ws/

I think favicons don't get lost anymore...
(In reply to comment #70)
> I think favicons don't get lost anymore...

If you follow the forums, you will find that they still do
for many people.
This seems to have gotten worse since they checked in the last livemarks component.

I've gotten reports of people (including me) losing their icons every time the
browser is closed. The browser doesn't delete the cache, but all the favicons go
every time.
Patch went in for bug 174265 that should fix this.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 251907 has been marked as a duplicate of this bug. ***
No longer depends on: 240794
*** Bug 240794 has been marked as a duplicate of this bug. ***
*** Bug 252399 has been marked as a duplicate of this bug. ***
verified with firefox 0.9+ branch build 2004-07-21-09-0.9
Status: RESOLVED → VERIFIED
I installed .0.9.2 and the problem still exists.
Platform Windows 2000 Pro

This was checked in after 0.9.2
I installed firefox 0.9+ branch build 2004-07-21-09-0.9 (from the setup
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-07-21-09-0.9/)  and
the problem still exists.

Platform Windows 98
it works perfectly! (at last…)
thanks!

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040727
Firefox/0.9.1+

(In reply to comment #79)
> This was checked in after 0.9.2

Where is the patch?
Do you have to reinstall totally with another build?
Dan
setting fixed-aviary1.0 for bugs checked into branch, for searching purposes.
Keywords: fixed-aviary1.0
I just tried the branch build of today, and it seems the favicons of some
webpages such as www.zonelabs.com or www.heise.de are not properly shown at all,
just the default blank page favicon (though they are shown in the address bar) ....


Adding these web pages as new bookmarks doesn't help either. Deleted cache and
history, but no better.

just me, or can someone confirm this?

(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040810
Firefox/0.9.1+)
(In reply to comment #84)
> I just tried the branch build of today, and it seems the favicons of some
> webpages such as www.zonelabs.com or www.heise.de are not properly shown at 

This is bug 246946.
(In reply to comment #85)
> (In reply to comment #84)
> > I just tried the branch build of today, and it seems the favicons of some
> > webpages such as www.zonelabs.com or www.heise.de are not properly shown at 
> 
> This is bug 246946.

Well let's put it this way.  I installed the brand new 0.9.3 and when
I clear my cache, the favicons disappear.
Don't bother posting about it because these favicon related posts and
bugs just keep getting closed, even though they are not fixed.
You can also type your brains out and explain the whole situation in
the mozilla forums as I did, and even explain to the programmers what
is happening.  It doesn't matter.  You are wasting your breath.
There is a serious communication problem with regard to the development
of this browser.  This in no way reflects on the brain-busting amount
of time that dedicated and enthusiastic programmers put into it.
The branch you are having problems with is not in the latest build,
it is the branch that leads to Mozilla.org
Dan McTaggart

(In reply to comment #86)
> Well let's put it this way.  I installed the brand new 0.9.3 and when
> I clear my cache, the favicons disappear.

The fix is not in 0.9.0, 0.9.1, 0.9.2, or 0.9.3.  0.9.1, .2, and .3 only contain
security/critical fixes from the 0.9.0 release.  Unless you download a nightly
build, the first time you'll see the favicon fixes is when Firefox 1.0 PR1 is
released.

(In reply to comment #85)
> (In reply to comment #84)
> > I just tried the branch build of today, and it seems the favicons of some
> > webpages such as www.zonelabs.com or www.heise.de are not properly shown at 
> This is bug 246946.

No, this is bug 255085.

> (In reply to comment #85)
> > (In reply to comment #84)
> > > I just tried the branch build of today, and it seems the favicons of some
> > > webpages such as www.zonelabs.com or www.heise.de are not properly shown at 
> > This is bug 246946.
> 
> No, this is bug 255085.

I revisited both URLs and this are two different bugs:

www.zonelabs.com 255085
www.heise.de 246946 (no redirection!)
(In reply to comment #88)
> > (In reply to comment #85)
> > > (In reply to comment #84)
> > > > I just tried the branch build of today, and it seems the favicons of some
> > > > webpages such as www.zonelabs.com or www.heise.de are not properly shown at 
> > > This is bug 246946.
> > 
> > No, this is bug 255085.
> 
> I revisited both URLs and this are two different bugs:
> 
> www.zonelabs.com 255085
> www.heise.de 246946 (no redirection!)


There are lots of favicon related bugs.
Go back through this thread and see how many times
they are supposed to be fixed.
I'm not clear on this. It is marked fixed, but there are repeated notes that it
is  not. Should the status be changed?
(In reply to comment #90)
> I'm not clear on this. It is marked fixed, but there are repeated notes that it
> is  not. Should the status be changed?

It is fixed.  Do not change the status.  All remaining issues are being
addressed in other bugs.
Please read what vladimir@pobox.com wrote.  THIS BUG HAS BEEN FIXED.
"The fix is not in 0.9.0, 0.9.1, 0.9.2, or 0.9.3.  0.9.1, .2, and .3 only contain
security/critical fixes from the 0.9.0 release.  Unless you download a nightly
build, the first time you'll see the favicon fixes is when Firefox 1.0 PR1 is
released."

Thank you,
-=MaStA ViC
Please read what vladimir@pobox.com wrote.  THIS BUG HAS BEEN FIXED.
"The fix is not in 0.9.0, 0.9.1, 0.9.2, or 0.9.3.  0.9.1, .2, and .3 only contain
security/critical fixes from the 0.9.0 release.  Unless you download a nightly
build, the first time you'll see the favicon fixes is when Firefox 1.0 PR1 is
released."

Thank you,
-=MaStA ViC
still isn't working right on some sites.
example zeldman.com, bt.easytree.org, texturizer.net/firefox/themes/,
alistapart.com, suprnova.org

favicon apears in tab and in addressbar, but not in my bookmarks.

Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
(In reply to comment #94)
> still isn't working right on some sites.
> example zeldman.com, bt.easytree.org, texturizer.net/firefox/themes/,
> alistapart.com, suprnova.org
> 
> favicon apears in tab and in addressbar, but not in my bookmarks.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10

I think it's a separate issue, use the "create new bug" link.
(In reply to comment #94)
> favicon apears in tab and in addressbar, but not in my bookmarks.

This is already covered with bug 246946.
No longer depends on: 240795
Blocks: majorbugs
No longer blocks: majorbugs
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
You need to log in before you can comment on or make changes to this bug.