Closed
Bug 173762
Opened 22 years ago
Closed 20 years ago
Favicons are forgotten after shutdown
Categories
(Firefox :: Bookmarks & History, defect, P2)
Firefox
Bookmarks & History
Tracking
()
VERIFIED
FIXED
Firefox1.0
People
(Reporter: andre.bugs2, Assigned: vlad)
References
()
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.
Reporter | ||
Comment 1•22 years ago
|
||
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">
Comment 2•22 years ago
|
||
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.
Reporter | ||
Comment 3•22 years ago
|
||
I filed this bug here because I know that Phoenix handles favicons differently than Mozilla.
Comment 4•22 years ago
|
||
I think this is the case with most or all favicons in a fresh profile with today's build.
Comment 5•22 years ago
|
||
*** Bug 173816 has been marked as a duplicate of this bug. ***
I can see this bug on with many sites Linux Phoenix Build 20021012. And still applies after trying a new profile.
Reporter | ||
Comment 8•22 years ago
|
||
*** Bug 178510 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 9•22 years ago
|
||
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
Reporter | ||
Comment 10•22 years ago
|
||
*** Bug 178214 has been marked as a duplicate of this bug. ***
Comment 11•22 years ago
|
||
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.
Comment 12•22 years ago
|
||
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
Comment 13•22 years ago
|
||
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.
Comment 14•22 years ago
|
||
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 ?
Reporter | ||
Updated•22 years ago
|
OS: Linux → All
Comment 15•22 years ago
|
||
*** Bug 191542 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
*** Bug 184264 has been marked as a duplicate of this bug. ***
Comment 17•22 years ago
|
||
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.
Comment 18•21 years ago
|
||
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
Comment 19•21 years ago
|
||
the curent MozillaFirebird release 0.6 is constantly loosing favicons, esp. those on the toolbar, too!
Comment 20•21 years ago
|
||
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.
Comment 21•21 years ago
|
||
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...
Updated•21 years ago
|
Target Milestone: --- → Firebird1.0
Comment 23•21 years ago
|
||
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.
Comment 24•21 years ago
|
||
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.
Comment 25•21 years ago
|
||
Thanks, I didn't know that. How come priority isn't set then?
Comment 26•21 years ago
|
||
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.
Comment 27•21 years ago
|
||
*** Bug 215052 has been marked as a duplicate of this bug. ***
Comment 28•21 years ago
|
||
I'm not seeing this anymore with Firdbird 20030903 on Linux, and I did before on a regular basis.
Hardware: PC → All
Comment 29•21 years ago
|
||
Verified this problem on latest FB GTK2/XFT build. Using bookmark toolbar, favicons in the toolbar not saved upon shutdown.
Comment 30•21 years ago
|
||
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.
Comment 31•21 years ago
|
||
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 **
Comment 32•21 years ago
|
||
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.
Comment 33•21 years ago
|
||
*** Bug 226493 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking0.8?
Comment 34•21 years ago
|
||
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.
Comment 35•21 years ago
|
||
Darin, any ideas? /be
Comment 36•21 years ago
|
||
unless there's a patch for this, it won't make 0.8
Flags: blocking0.8? → blocking0.8-
Comment 37•21 years ago
|
||
Dupe 116832 or 117895 ?
Comment 38•21 years ago
|
||
no, bookmarks is forked, so this has to stay open
Comment 39•21 years ago
|
||
*** Bug 240429 has been marked as a duplicate of this bug. ***
Comment 40•21 years ago
|
||
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"?
Comment 41•21 years ago
|
||
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...
Comment 42•21 years ago
|
||
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.
Comment 43•21 years ago
|
||
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.
Comment 44•21 years ago
|
||
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...
Comment 45•21 years ago
|
||
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
Comment 46•21 years ago
|
||
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.
Comment 47•21 years ago
|
||
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.
Comment 48•21 years ago
|
||
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.
Comment 49•21 years ago
|
||
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
Comment 50•21 years ago
|
||
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.
Comment 51•21 years ago
|
||
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.
Comment 52•21 years ago
|
||
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.
Comment 53•21 years ago
|
||
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 ;-)
Comment 54•21 years ago
|
||
(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! ;-)
Comment 55•21 years ago
|
||
(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.
Comment 56•21 years ago
|
||
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.
Comment 57•21 years ago
|
||
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
Comment 58•21 years ago
|
||
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
Comment 59•21 years ago
|
||
*** Bug 204421 has been marked as a duplicate of this bug. ***
Comment 60•21 years ago
|
||
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 :^)
Updated•20 years ago
|
Flags: blocking1.0?
Updated•20 years ago
|
Priority: -- → P2
Comment 63•20 years ago
|
||
(In reply to comment #62) > -> danm. I'm confused. What?
Comment 64•20 years ago
|
||
(In reply to comment #63) > (In reply to comment #62) > > -> danm. > > I'm confused. What? The Assigned To changed to Dan M.
Updated•20 years ago
|
Flags: blocking-aviary1.0RC1+
Comment 65•20 years ago
|
||
hot potato, hot potato. -> vlad initially. vlad, if you're overloaded, pass to danm.
Assignee: danm.moz → vladimir
Comment 66•20 years ago
|
||
*** Bug 249631 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 67•20 years ago
|
||
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.
Assignee | ||
Comment 68•20 years ago
|
||
The patch for bug #174265 fixes this issue.
Status: NEW → ASSIGNED
Comment 69•20 years ago
|
||
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/
Comment 70•20 years ago
|
||
I think favicons don't get lost anymore...
Comment 71•20 years ago
|
||
(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.
Comment 72•20 years ago
|
||
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.
Assignee | ||
Comment 73•20 years ago
|
||
Patch went in for bug 174265 that should fix this.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 74•20 years ago
|
||
*** Bug 251907 has been marked as a duplicate of this bug. ***
Comment 75•20 years ago
|
||
*** Bug 240794 has been marked as a duplicate of this bug. ***
Comment 76•20 years ago
|
||
*** Bug 252399 has been marked as a duplicate of this bug. ***
Comment 77•20 years ago
|
||
verified with firefox 0.9+ branch build 2004-07-21-09-0.9
Status: RESOLVED → VERIFIED
Comment 78•20 years ago
|
||
I installed .0.9.2 and the problem still exists. Platform Windows 2000 Pro
Comment 79•20 years ago
|
||
This was checked in after 0.9.2
Comment 80•20 years ago
|
||
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
Comment 81•20 years ago
|
||
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+
Comment 82•20 years ago
|
||
(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
Comment 83•20 years ago
|
||
setting fixed-aviary1.0 for bugs checked into branch, for searching purposes.
Keywords: fixed-aviary1.0
Comment 84•20 years ago
|
||
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+)
Comment 85•20 years ago
|
||
(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.
Comment 86•20 years ago
|
||
(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
Assignee | ||
Comment 87•20 years ago
|
||
(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.
Comment 88•20 years ago
|
||
> (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!)
Comment 89•20 years ago
|
||
(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.
Comment 90•20 years ago
|
||
I'm not clear on this. It is marked fixed, but there are repeated notes that it is not. Should the status be changed?
Comment 91•20 years ago
|
||
(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.
Comment 92•20 years ago
|
||
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
Comment 93•20 years ago
|
||
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
Comment 94•20 years ago
|
||
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
Comment 95•20 years ago
|
||
(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.
Comment 96•20 years ago
|
||
(In reply to comment #94) > favicon apears in tab and in addressbar, but not in my bookmarks. This is already covered with bug 246946.
Comment 97•18 years ago
|
||
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.
Description
•