Remove single image from cache

Until now I’ve used following code to remove single image from cache (based on this snippet):

cache = Cc["@mozilla.org/image/tools;1"].getService(Ci.imgITools).getImgCacheForDocument(null);
cache.removeEntry(nsIURI);

But starting from FF44, there are no more removeEntry() method in cache, obtained as above. Is there are more smart way to clear cache for single image, other than call full cache.clear() for specific document?

1 Like

This is some cool stuff. I haven’t work much with cache myself, but this post shows some of the modern cache tech: http://stackoverflow.com/questions/27842615/how-to-find-specific-cache-entries-in-firefox-and-turn-them-into-a-file-or-blob

https://bugzilla.mozilla.org/show_bug.cgi?id=1202085

Looks like they might have boobed on this. Maybe one of the rare times when you can spam a bug to make sure they really understood what they were doing. Or use other channels to talk to the devs about what they were smoking when this happened.

Is it actually the internal (temporary) image cache you want to remove? Or also the permanent disk cache entry for that image?

Update: I butted in myself at Bugzilla. This is a feature I use and it will break one of my addons if it disappears. Stay tuned and see if I completely misread things. At least it should get an answer to your question, one way or another.

2 Likes

Brilliant reply @Lithopsian, you have pointed me to the real cause of the problem once again! Could you teach me how to find such things in bugzilla? I tried to look at <a href=https://bugzilla.mozilla.org/buglist.cgi?component=ImageLib>recent ImageLib changes, but #1202085 isn’t listed there.

My addon provides visual bookmarks and uses removeEntry to update thumbnails after resize or refresh. I’m not shure the memory or disk cache cleanup is required, but removeEntry was enough.

Thanks, let’s wait for reply from devs. I hope they will think again.

Searching is tricky. Things aren’t always labelled the way you expect. In this case, I had to track back to the commit that removed the function from imgICache.idl.

A little background on cache. Everything, html pages, images, etc is all cached on disk (unless it is private browsing, cache is disabled, etc.). There is also an in-memory cache for things that can’t be written to disk for privacy or policy reasons, but it is very rarely used. When you load something, this is the first place to look, then possibly a check over the web to see if a newer version of the resource is available. If you code your own XMLHttpRequests then you can force the timestamp check, or even completely override the disk cache. Possibly in your case, you are working with images that you obtain yourself and are not even in the disk cache? Perhaps you have your own disk cache?

As you’ve no doubt found, replacing an image that is displayed by Firefox with a different image at the same URL does not result in a change in Firefox. Images are decoded and cached in a special image cache (actually now two image caches, one for private browsing), entirely separate and in addition to the standard document caching. This is manipulated using imgICache, and now imgITools, but only in a very limited way.

I’m not so familiar with the new worker Cache Storage objects. They are new and should enable web workers to maintain their own semi-persistent stores of data. So far as I know this shouldn’t affect the existing caching arrangements, but maybe I’m missing something.

1 Like

To make sure that Cache Storage operates independently from the Image Cache, I’ve tried to clean the Disk Cache Storage and Memory Cache Storage:

LoadContextInfo = Components.classes["@mozilla.org/load-context-info-factory;1"]
.getService(Components.interfaces.nsILoadContextInfoFactory);
CacheStorageService = Components.classes["@mozilla.org/netwerk/cache-storage-service;1"]
.getService(Components.interfaces.nsICacheStorageService);

DiskCacheStorage = CacheStorageService.diskCacheStorage(LoadContextInfo.default, false);
MemoryCacheStorage = CacheStorageService.memoryCacheStorage(LoadContextInfo.default);

DiskCacheStorage.asyncDoomURI(nsIURI, “”, nsICacheEntryDoomCallback);
MemoryCacheStorage.asyncDoomURI(nsIURI, “”, nsICacheEntryDoomCallback);

But it does not help to refresh the updated image in the browser. Looks like we definetly needs in removeEntry or similar to remove single entry from Image Cache directly.

Absolutely, you need to clean out the image cache for the image to change. The other cache clearing may or may not be necessary depending on whether your images can get in there (or whether you just decide to bypass the cache altogether).

A workaround to avoid the image cache is to change the URL for the image when the image itself changes. I don’t know if this is practical in your addon or not. Probably not worth planning big changes until we find out if this function is coming back.

HAHAHA you’re so funny man :stuck_out_tongue:
Awesome sleuth work by the way!

Here is an awesome MDN page explaining the new cache technologies (and sometimes comparing it to the old tech):

Could we ask anyone to grep AMO sources to find out how many addons currently uses removeEntry? The answer could be an additional argument for the need to preserve it.

t might get to that point. At the moment, they don’t believe anything useful or necessary has been removed. Maybe it hasn’t, and a magical alternative will be revealed to us :slight_smile:

Their <a href=https://bugzilla.mozilla.org/show_bug.cgi?id=1202085#c43>suggestions make me laugh through tears. Ok, let’s deprecate the doors and jump through the windows. Looks like new cache v2 became so smart, that devs themselves can’t control it :angry:

Yes, suggesting bizarre workarounds for broken features is becoming something of a habit. I’m not sure it is official Mozilla policy yet (although it will be soon), but the culture has become one where there is no interest in supporting features only used by addons,