Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050821
"Clear Cache Now" doesn't clear bfcache. I think it should, since bfcache
usually holds at least as much private information as the normal cache for the
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050821
I see this too.
Created attachment 193423 [details]
bryner, could you take a look? thanks
This is going to be easier once all of the session histories can be enumerated,
which is going to be part of bug 292965. Deferring this until that one is fixed.
Created attachment 197287 [details] [diff] [review]
What about nsICacheSession::evictEntries? It seems like this observer event is
only generated by a call to nsICacheService::evictEntries, which takes a
parameter to control the storage type to evict. In other words, this API does
not map directly to the button in the preferences panel. Perhaps it would be
better to generate the observer event from the prefs panel. It would almost
make sense for the cache service to observe that event instead (but I might hold
off on that change for now).
(In reply to comment #6)
> not map directly to the button in the preferences panel. Perhaps it would be
So it will get invoked twice, true... I don't really know a good way to avoid
that though, since the content viewer caching doesn't correspond entirely to
either memory or disk cache (it's an in-memory cache, to be sure, but should
also go away if the disk cache is cleared, since it contains similar
> better to generate the observer event from the prefs panel. It would almost
I specifically wanted to avoid that, because it would require changes to any
Gecko client that has a "clear cache" option. The back forward cache is a
detail that Gecko clients shouldn't need to worry about.
Created attachment 197628 [details] [diff] [review]
This patch is more inclusive about sending the notifications. I changed the
call sites in browser and xpfe to avoid notifying more than once, however, a
client that does flush memory and disk separately will still empty the bfcache
This looks good to me, except i would put some big disclaimer comment by
the EvictAllContentViewers function explaining how inefficient it is.
I marked as approved so you can go ahead and submit after adding the comment.
One more concern: I believe that the nsICacheService is an API designed to be
called on any thread (hence mCacheServiceLock). nsIObserverService is not
threadsafe, however. So, if someone decided to trigger cache eviction on a
background thread, then suddenly lot's of other stuff would run on that thread.
I think this means that you need to use NS_GetProxyForObject. See
nsCategoryManager, which has to deal with exactly the same problem.
Created attachment 197804 [details] [diff] [review]
with comments addressed
Comment on attachment 197804 [details] [diff] [review]
with comments addressed
please add a comment in nsICacheService.idl detailing the observer topic.
someone should not have to look at the source code to see what this thing
means. for example, you might want to follow the documentation found at the
bottom of nsIHttpProtocolHandler.idl.
otherwise, patch looks good to me. sr=darin with those nits picked.
Created attachment 197908 [details] [diff] [review]
Checked in on the branch