User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:126.96.36.199) Gecko/20080201 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:184.108.40.206) Gecko/20080201 Firefox/220.127.116.11 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.
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 18.104.22.168, 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking22.214.171.124? → blocking126.96.36.199-
Not going to block the 3.1 release on this. Marking wanted.
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.]
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.
The problem still exists in Firefox 44.0b4.
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.
(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.
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["@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.)
You need to log in before you can comment on or make changes to this bug.