418144 - Favicons are not affected by a hard refresh

Status: NEW

(Toolkit :: Places, defect, P5)

Description

[Hendrik Lönngren]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

Favicons are currently not affected by a hard refresh. But they should be. To reproduce, just create an html with a favicon, load the page, change the favicon and do a hard refresh.

Reproducible: Always

Comment 1

[benshadwick]

I'm experiencing this in Firefox 3.0.1 as well, including the case that a favicon.ico was added to the root of a site since the last time I loaded a page on that site.

I have the close the browser completely and re-open it to force a favicon refresh.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

This is a really old request, and the canonical dupe is bug 240795, though that report seems to sort of gloss over the fact that Shift-Reload should update the cached favicon.

Doesn't block 1.9.0.2, nor is it particularly needed for the branch, but we might want to revisit this for 1.9.1 as a long-standing polish issue.

Comment 3

[Dietrich Ayala (:dietrich)]

Not going to block the 3.1 release on this. Marking wanted.

Comment 4

[Marco Bonardo [:mak]]

Attachment: patch v1.0

patch splitted from bug 480873, toolkit implementation (a full browser impl could be possible too)

Comment 5

[John P Baker]

As I have said before, using the mForceReloadIconPages hash seems to be a clumsy, expensive and unreliable way of storing a boolean state that could be kept by the caller and then passed in the aForceReload argument to SetAndLoadFaviconForPage as required; I haven't checked but it is also likely that callers already have access to this state from progress listener or load group flags.

We probably still need the ability to pass null to setFaviconUrlForPage to remove an icon - but that may bug 434969.

[I also suspect - but I am in unknown territory - that, if forcing reload, flags need to be set on the fetch of an icon to ensure that the browser cache copy is rechecked with the server.]

Comment 6

[David Balažic]

Still present in version 4.0.1 (Windows).

Comment 7

[Chris Zim]

Also still present in FF 5.0 running on OpenSuse 11.4. Web server access logs shows that there's no request for the favicon.ico file when the HTML header contains '... link type="image/x-icon" ...' so I presume it's taken from a cache.

Comment 8

[Siddhartha Dugar [:sdrocking]]

Favicons in Panorama also do not refresh, but that should be a separate bug.

Comment 11

[bogomip]

The problem still exists in Firefox 44.0b4.

Comment 12

[benshadwick]

What is the reason for the priority downgrade to "we basically don't ever want this"? https://wiki.mozilla.org/Bugzilla:Priority_System

FYI, this still exists in 49.0.2.

Comment 13

[Marco Bonardo [:mak]]

(In reply to benshadwick from comment #12)
> What is the reason for the priority downgrade to "we basically don't ever
> want this"? https://wiki.mozilla.org/Bugzilla:Priority_System

P4 is currently unused, so it's not really a downgrade, that page is obsolete and wrong.

Comment 15

[benshadwick]

Happy 10th anniversary, embarrassing favicon refresh bug!

From the latest dupe, apparently you can force a refresh with a Browser Console command: PlacesUtils.favicons.expireAllFavicons();

Comment 16

[benshadwick]

Possibly related bugs:
Bug 333516
Bug 627046
Bug 699785
Bug 1230945
Bug 1253407 (see comments 8 & 9)
Bug 1417855

Comment 19

[u580221]

I tried the browser console command "PlacesUtils.favicons.expireAllFavicons();" followed by another CTRL+SHIFT+R but I'm still stuck with the old favicon...

Surely it's not that hard to get rid of the favicon during a hard refresh?

Comment 21

[Marius Gedminas]

I've successfully forced Firefox to reload a favicon for a site that was showing no favicon at all in the tab bar by doing the following in the browser console:

  const newURI = Components.classes["@mozilla.org/network/io-service;1"].getService(Components.interfaces.nsIIOService).newURI;
  PlacesUtils.favicons.removeFailedFavicon(newURI("https://mysite.example.com/favicon.ico"))

and then reloading the tab.

(Reminder for new people like me until very recently: to enter commands in the browser console you first have to set devtools.chrome.enabled to true in about:config and restart Firefox.  Once you do that, the browser console you get with  Ctrl+Shift+J gets an input box at the bottom.)

(I'm rather unfamiliar with Firefox internals and cannot say if there's an easier way to call the newURI() method.  If there is, I failed to find it.)

Comment 22

[Colin Jones]

This is clearly an ongoing issue for users.  Why has there been no movement on it (It's actually older than 10 years, as the previous closed bug report was fifteen years old)?  Where favicons are specified in the HTML by the website owner they should be followed, and whilst caching is fine, they should definitely be requested again where a user asks for a hard refresh of *all resources* associated with the website.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates and 13 votes.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 26

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.