http://bugzilla.mozilla.org/show_bug.cgi?id=173762#c52 raised this issue, and its worthy of its own decision. Does the user expect the favicon to remain stored, or to be updated when the site icon changes? Does changing the visual representation of the site icon imply that we should switch to the new title as well? (this would be dependent on whether the user changed the bookmark title at any point, of course) I think that making part of the bookmarks listing dynamic while leaving the text static is less "clean" from a UI perspective.
An interesting way to make the title and icon behavior consistent would be allowing the user to change the icon as well. That could be a useful feature for marking specific types of sites, or just for aesthetic reasons, much like people sometimes change the icons of applications or documents on their desktop. Also, customized icons would be very useful in the bookmark toolbar, since with an appropriate icon many bookmarks could have no title, allowing many more to fit. There could be checkboxes for the title and icon saying "Use site-provided", defaulting to on and turning off if the user modifies the title or icon. In the bookmark's Properties dialog a Refresh button could reload them both.
Just my comment: bookmarks do not change the title or URL of a page if it changes or uses meta-refresh to redirect to a new location. I'm not sure that updating the favicon is necessary, nor the right thing to do. I wouldn't mind if it was left open to be changed by an extension, however, if someone wanted to make an optional mod to Firefox to change the default behavior or allow such changes to take place with additional GUI dialogues, etc.
There are several bugs open on favicons. My opinion should be given little weight, because I am not all that interested in favicons, but it would certainly seem that there is room for a little application of logic to create a more consistent interface. A naive implementation, and the one that I would write, would treat favicons as cacheable only per session, and would use the favicon only after it had been compared to the origin site (unless the browser has been switched to some off-line mode). This seems to be in conflict with the 'principle of least surprise', so my first suggestion would be devise a way in which favicons can persist across sessions but still get refreshed (imagine yourself as a web site editor wanting to modify and check the favicons on your site). I would suggest the same disconnect be applied to displayed icons as is applied to displayed labels in bookmarks (I suspect that it is within bookmarks that the main problem lies). When bookmarking a page, the user has the option to edit or replace the title of that page with his or her own label, similarly, there should be the means to replace or edit the favicon, creating a custom icon. Just as the Label persists regardless of changes to the cache (or even the <title> of the origin page) so the Icon can now persist as it is disconnected from the cache, and for that matter the web. I would suggest that the properties sheet for each bookmark has an independent display of the user assigned Label (initialised to the <title> element) and the current <title> if fresh, and the user assigned Icon (initialised to "favicon.ico") and "favicon.ico" if fresh. There could be a button (similar to Dreamweaver's) to freshen/reload those data if they are missing, and buttons to overwrite stored data with live data. Obviously, most people will just leave these alone and gain the benefit of 'least surprise' without anyone else having to jump through hoops to ensure that the data are retained across shutdowns, crashes et cetera.
A comment from a non-developer: I would support leaving the icons as they are in the bookmark. Automatic refreshing involves several problems: 1. High network activity - This is particularly critical for those times on the road connecting using a modem. 2. Some secure sites may have the icon on the https server. Trying to access the icon may result in a password request form the user. 3. The previously mentioned 'principle of least surprise' If the decision is to refresh the icon with the site's latest, I would suggest only doing so when a user actually visits the site. That would even reduce the 'surprise' factor, since the user will first see the new icon on the site.
favicons provide a visual cue to my less sophisticated users. I'm an English teacher/sysadmin, and without the icons students have trouble remembering which link does what. Favicons don't work in .9. I won't be installing .9 on the school's network until it's fixed, just out of deference to those students, that I know, who will have trouble without the visual cue that favicons provide. btw, I do like the new theme though :) dennis
IMO, the favicon should be stored once, when the page is bookmarked. After that, the 'Properties' UI should provide a mechanism to refresh the favicon from the site or to replace it with any icon of the appropriate size from the user's hard drive. Same mechanism should be provided for the bookmark folders. I've used this feature a lot in IE, and frankly miss it quite a bit in Mozilla.
The question of how Firefox should behave and how would a new user would expect it work are two different things: Expectations may differ so this is kind of religious. So that gives the first question of how it should behave more weight. But that is easy to resolve: Make it configurable. Me, I would expect that the icon once fetched would keep intact as long as I don't manually update it. Additionally I would expect that - I *can* update a single bookmarks favicon it manually - I can update all bookmarks favicons with one command - I can assign a local favicon that won't ever be overwritten. I guess that would please all users despite from their expectations
> But that is easy to resolve: Make it configurable. Yes - though I think there is really only one viable default behavior. The options are: 1. icons stick to bookmarks at bookmark creation time. 2. icons are derived from bookmarks at runtime. 2 can be implemented on top of 1 but not vice versa. > Me, I would expect that the icon once fetched would keep intact as long as I > don't manually update it. > Additionally I would expect that > - I *can* update a single bookmarks favicon it manually > - I can update all bookmarks favicons with one command > - I can assign a local favicon that won't ever be overwritten. Add to this: - I can load an extension that refreshes bookmark icons periodically for me. Question: does anyone actually prefer the current behavior? I just don't get it: Other than being already implemented, I *really* don't see any benefit in trying to keep bookmark icons fresh at runtime. On the other hand, there are plenty of problems (sigificant performance, application experience, extra bandwidth, customization issues).
Really there needs to be 2 mechanisms for site icons. One for bookmarks and one for pages visited that are not in bookmarks. First, my suggestion is to have the icon in the bookmarks be in a permanent location (i.e. \<profile>\icons\). The icon should be written there when a location is bookmarked and the bookmark file should be updated with a resource:// url to that location. See bug 246209 for details on implementing a resource url for the profile directory. Then allow the user in bookmark properties to either refresh the icon or overwritten with a user defined. Second, when a page is visited first see if it is bookmarked if so use that icon. If it is on then try getting the icon from links within the page. Last if not defined in link, then get it from favicon on server.
(In reply to comment #9) > Really there needs to be 2 mechanisms for site icons. One for bookmarks and one > for pages visited that are not in bookmarks. I think I need to disagree here. I'd much rather site and bookmark icons be totally runtime orthogonal. Here's my suggestion: 1. site icons continue to work *exactly* as they do now (modulo various caching bugs which still seem to be open). Site icons (e.g. what shows up in the location bar) never look at bookmarks. 2. bookmark icons are stored on the user's disk, initialized from the site icon discovered in the usual way at bookmark create time. Display of a bookmark icon never requires network operation, and never depends on any icon/image cache state. My preference is to store the icon bitmaps in the bookmarks file itself - keeping them separate is going to violate least surprise somewhere along the way ("I copied my bookmarks.html file and now all my icons are gone!"). Maybe we need to jump to a multipart/attachment format to do this right. > ... > Second, when a page is visited first see if it is bookmarked if so use that > icon. If it is on then try getting the icon from links within the page. Last > if not defined in link, then get it from favicon on server. IMHO, This violates the principle of least surprise in the other direction: the site icon should be defined by the site always, the bookmark icon should be defined by the bookmark always. Once the bookmark is created, they are forever separated unless you update (or have an agent update for you). While I'd certainly not object if options/extensions were provided to offer automatic update of bookmark icons from the site, or using the bookmark icons as site icon cache, I would not be interested in actually using either.
The way things stand now, we don't update the title, so I don't think we should update the favicon. However, I would like to get some UI to allow you to reset the favicon -- I was thinking of displaying the favicon in the bookmark properties, but with the current layout there's no way to do that doesn't look horrible. Wherever the icon ends up, I was thinking to add a context menu entry to reset it, and a checkbox somewhere for "never display this favicon". But, like I said, I can't come up with a way to put the icon in there without making the UI look horrible.. I guess an "Icon: [ ]" thing wouldn't be /so/ bad, but..
(In reply to comment #11) > The way things stand now, we don't update the title, so I don't think we should > update the favicon. We shouldn't update the title because the user can (and many users do) change bookmark description to something other than the orginal page title. Many web page titles don't make good bookmark descriptions (and often for good reasons -- the two text server different purposes). However, if we don't update the favicon a user noticing the difference between the favicon and the web site will probably say "stupid browser" and not look for a manual mechanism to update the favicon. (I might be wrong -- I'm not a typical user and I can't always figure out how they would react. I'd love to have a user-interface usability study or good survey of typical users on the issue, but I don't expect that to happen.) B.J.
*** Bug 253045 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > (In reply to comment #11) > > The way things stand now, we don't update the title, so I don't think we should > > update the favicon. > > We shouldn't update the title because the user can (and many users do) change > bookmark description to something other than the orginal page title. Many web > page titles don't make good bookmark descriptions (and often for good reasons -- > the two text server different purposes). The same could be said about bookmark icons in IE. In particular, many IE users add icons to bookmarks without site-specified favicons - it would be an obvious error for a site icon to ever overwrite a modified bookmark icon. To my mind, it would be an error to ever overwrite/update a bookmark icon, though I can see why someone might want such behavior, in theory. > > However, if we don't update the favicon a user noticing the difference between > the favicon and the web site will probably say "stupid browser" and not look for > a manual mechanism to update the favicon. Gotta disagree here: 1. bookmarks are different than live pages - the whole point is that they are unchanging! Icons are often much quicker to recognize than words - tracking the site icon behind the users back could very well be extremely annoying: who cares if BayBank/Fleet/BofA decided to update their icon *again* - the user wants the bookmark to stay in the same place, with the same title and icon so that she can find it without having to search for it. 2. I don't see any particular use for the favicon in the location window - it is pretty, but it adds nothing to the user's experience. Putting it in the titlebar or iconified form, on the other hand is very useful. 3. One could easily imagine a website which changes icons depending on your state - e.g. green if you are "logged in" vs red if not - attempting to keep bookmarks in sync with the favicons would be horrible in this situation. UI options to select: 1. general bookmark icon update policy: a. no automatic tracking b. passive tracking (update bico if the page is visited and the favicon has changed) c. active tracking (poll on some schedule) 2. explicit update: a. from file b. from bookmark url c. from /favicon.ico d. clear I'd think an extension would be the right way to do any sort of active tracking, maybe even passive tracking.
I would love to have custom Favicons. I had this feature with IE and used it to organize my bookmarks (all financial urls had a "$" icon, TV listings had a tiny TV icon, etc). I have about 40 custom icons I'd like to associate with URLs. If no custom icon is linked then the site supplied icon should be displayed. Another bookmark feature I'd like is for the sort function (manage folder / view) to apply ONLY to individual folders -- not globally. When I tried this in my "newspapers" folder it sorted all folders. I don't know if this is a bug or just the design. It would be nice to sort and save my Newspaper folder URLs alphabetically, and my "Tech" folder URLs by frequency of use. Thanks.
(In reply to comment #11) > However, I would like to get some UI to allow you to reset the favicon -- I was > thinking of displaying the favicon in the bookmark properties, but with the > current layout there's no way to do that doesn't look horrible. Wherever the > icon ends up, I was thinking to add a context menu entry to reset it, and a > checkbox somewhere for "never display this favicon". But, like I said, I can't > come up with a way to put the icon in there without making the UI look > horrible.. I guess an "Icon: [ ]" thing wouldn't be /so/ bad, but.. Have you seen Torisugari's extension "Favicon Picker"? The implementation of showing, erasing and assigning new favicons in this extension seems non-horrible. http://cgi29.plala.or.jp/mozzarel/addon/firefox0_9/faviconpicker/
Bookmarks Toolbar icons are a time-saving device--they allow me to quickly find my most visited sites. Allowing the user to customize these icons would be nice. For one thing, many sites don't provide an icon, and it would be nice to be able to add one. But the more pressing task is to have these icons persist. It is very frustrating to find them disappear after a day or two. Is there some workaround for this problem now?
*** Bug 262367 has been marked as a duplicate of this bug. ***
*** Bug 261984 has been marked as a duplicate of this bug. ***
*** Bug 262907 has been marked as a duplicate of this bug. ***
Assignee: vladimir → vladimir+bm
*** Bug 260550 has been marked as a duplicate of this bug. ***
*** Bug 281628 has been marked as a duplicate of this bug. ***
Assignee: vladimir+bm → nobody
Putting on 2.0 radar. Should this get helpwanted key word?
*** Bug 314825 has been marked as a duplicate of this bug. ***
The new favicon service dynamically stores these, there's another bug where this is raised for places, clearing flag and resolving INVALID
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
(In reply to comment #25) > The new favicon service dynamically stores these, there's another bug where > this is raised for places, clearing flag and resolving INVALID > I'm missing something - how does this comment and change of status address this bug? In particular: 1. Has a decision been made as to if the favicon (by default) sticks or is refreshed? What was the decision, and where/how was it made? 2. Pointer to "the new favicon service" - what is it, what does it do, and how does it address this bug? 3. "there's another bug where this is raised for places" What is the bug number? 4. Why is this bug being resolved as invalid? the purpose of the bug was to discuss/track/and ultimately note a decision - shouldn't the bug be closed/fixed if the decision has been made, rather than declared a non-issue?
The discussion is under an entirely different context now that we're storing favicons for all pages in history, not just bookmarks. Discussing it in the original context of this bug is impossible, so keeping this bug around serves no purpose.
(In reply to comment #27) > The discussion is under an entirely different context now that we're storing > favicons for all pages in history, not just bookmarks. Discussing it in the > original context of this bug is impossible, so keeping this bug around serves > no purpose. While I appreciate this reply, it still doesn't fully address the issues raised in comment 26. For those of us interested in this topic, where is the new bug and where can we get a description of the new favicon mechanism?
*** Bug 326048 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > where is the new bug Can someone please answer this? "Principle of least suprise" has been mentioned a few times here. Here's my experience: I created a favicon for a page, viewed it and realised it had been messed up in the conversion process. I tried again, and it still looked screwed up. I *installed a whole extra graphics package* and tried converting a different way; still screwed up! Ah, maybe it's the browser, caching it despite me pressing shift-reload; clear cachhe; still messed up; then searched Bugzilla and found this bug. If it isn't obvious: Irrespective of what bookmarks should do, the favicon in the URL bar and tab should change, at least when the page is shift-reloaded. This is certainly the expectation that one gets from the way that it changes to the spinner while the page is reloading, and then back to the favicon.
(In reply to comment #30) > (In reply to comment #28) > Can someone please answer this? > > "Principle of least surprise" has been mentioned a few times here. Here's my > experience: I created a favicon for a page, viewed it and realised it had > been messed up in the conversion process. I tried again, and it still looked > screwed up. I *installed a whole extra graphics package* and tried > converting a different way; still screwed up! Ah, maybe it's the browser, > caching it despite me pressing shift-reload; clear cache; still messed up; > then searched Bugzilla and found this bug. > > If it isn't obvious: Irrespective of what bookmarks should do, the favicon in > the URL bar and tab should change, at least when the page is shift-reloaded. > This is certainly the expectation that one gets from the way that it changes > to the spinner while the page is reloading, and then back to the favicon. Well, the term 'Principle of Least Surprise' like its cognate 'intuitive' is meant to indicate a measure of merit (or perhaps an acceptance test/baseline) for an interface or interface element, but it is often used to just mean "my ideas are better than yours". IMHO, owing to the lack of specifications, there will never be an entirely satisfactory interface for configuring and working with favicons. There certainly needs to be a way for a website maintainer to check his or her current favicon(s); but it would also seem desirable that such a mechanism should NOT be surprising to the 'normal' user. I would question whether "Shift-Reload always overwrites the currently saved favicon" is the right answer, but the actions of going to the URL "http://my.site.org/favicon.ico" and re-loading should work as expected, that is, as it would for any other image file, including, of course, refreshing the cache (but not, IMHO, a saved, edited bookmark favicon). You might find that the 'Page Info', Cmd-I, does what you want. I would expect that most users (who outnumber both website maintainers and Firefox devs), would want favicons to persist, to be editable in a bookmarks file, and to be fully available off-line; and to be mighty surprised if this is not so. I don't see a simple implementation that can achieve all this. Speaking personally, I don't have strong view on this - I don't see it ever being fully resolved - and I think that we should make things as simple and as intuitive as possible for the average user. Unless someone comes up with some really nifty ideas, I suspect that means that people in your position will either need an extension to make things work the way you want, or to learn some roundabout way of achieving your goals. It might be an idea to add something to the FAQ sheet. I tend to agree with your suggestion that the favicon should only spin if has been re-fetched, but that is rather a subtle point!
I think the case is not that difficult. Let the favicon of an active (currently visited) webpage be refreshed on every reload that affects other webpage images too. Don't touch the favicons stored for bookmarks if they aren't loading directly from originating websites anyway.
I don't understand, why it is marked "resolved invalid".
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060627 Minefield/3.0a1 (In reply to comment #32) > I think the case is not that difficult. > > Let the favicon of an active (currently visited) webpage be refreshed on > every reload that affects other webpage images too. See Bug 260500 "Browser requests favicon.ico on every page view" for one discussion that has taken place on excessive requesting of these deploarable icons. > Don't touch the favicons stored for bookmarks if they aren't loading directly > from originating websites anyway. I think that this is what haapens now. The icon for the bookmark is stored in the bookmark database ...
(In reply to comment #33) > I don't understand, why it is marked "resolved invalid". > See comment 27 inter alios.
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.