Open Bug 418144 Opened 17 years ago Updated 6 months ago

Favicons are not affected by a hard refresh


(Toolkit :: Places, defect, P5)





(Reporter: wikibugs, Unassigned)



(Keywords: polish)


(1 file)

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

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
Component: General → Bookmarks
QA Contact: general → bookmarks
Version: unspecified → 2.0 Branch
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.
Flags: blocking-firefox3.1?
Flags: blocking1.9.0.2?
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, 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.
Ever confirmed: true
Flags: blocking1.9.0.2? → blocking1.9.0.2-
OS: Windows XP → All
Hardware: PC → All
Version: 2.0 Branch → Trunk
Not going to block the 3.1 release on this. Marking wanted.
Flags: wanted-firefox3.1+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Target Milestone: --- → Firefox 3.1
Keywords: polish
Priority: -- → P3
Target Milestone: Firefox 3.1 → ---
Attached patch patch v1.0Splinter Review
patch splitted from bug 480873, toolkit implementation (a full browser impl could be possible too)
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.]
Flags: wanted-firefox3.5+ → wanted-firefox3.6+
Still present in version 4.0.1 (Windows).
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.
Favicons in Panorama also do not refresh, but that should be a separate bug.
Priority: P3 → --
Priority: -- → P4
The problem still exists in Firefox 44.0b4.
Priority: P4 → P5
What is the reason for the priority downgrade to "we basically don't ever want this"?

FYI, this still exists in 49.0.2.
(In reply to benshadwick from comment #12)
> What is the reason for the priority downgrade to "we basically don't ever
> want this"?

P4 is currently unused, so it's not really a downgrade, that page is obsolete and wrong.
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();
Possibly related bugs:
Bug 333516
Bug 627046
Bug 699785
Bug 1230945
Bug 1253407 (see comments 8 & 9)
Bug 1417855
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?
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[";1"].getService(Components.interfaces.nsIIOService).newURI;

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 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.)
Severity: normal → S3

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.

Flags: needinfo?(mak)

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.

Flags: needinfo?(mak)
See Also: → 1845222
Duplicate of this bug: 1845222
Component: Bookmarks & History → Places
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.