Closed Bug 240795 Opened 20 years ago Closed 19 years ago

Persistence of favicons, should they be permanent or periodically refreshed?

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mconnor, Unassigned)

References

Details

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.
Blocks: 173762
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.
Assignee: p_ch → vladimir
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?
Flags: blocking-aviary2.0?
*** 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
Closed: 19 years ago
Flags: blocking-firefox2?
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.