962334 - Provide synchronous methods for clearing cache

Status: RESOLVED WORKSFORME

(Core :: Networking: Cache, defect)

Description

[Mike Perry]

Attachment: Hacky patch to make synchronous cache clearing possible.

In Tor Browser, we make it easy for users to do the equivalent of "Clear Private Data" and get a new Tor Circuit via a single click from the toolbar. As part of this process, we need to clear various aspects of browser state in a synchronous fashion, so that the user is unable to perform any navigation or browsing operations until the process completes.

However, somewhere around Firefox 10, the API calls to clear the cache became asynchronous. As a stopgap, I hacked them nsICacheService.EvictEntries to become synchronous.

This probably isn't an ideal solution, but it was expedient for us. I'm open to suggestions. It's not fully clear to me that the onCacheEntryDoomed callback event is exactly what we want either. Is the cache entry finally unavailable to content there?

The patch is against FF24ESR.

Comment 1

[Jason Duell]

Michal/Honza, do you have thoughts on a solution here?

Comment 2

[Michal Novotny [:michal]]

(In reply to Mike Perry from comment #0)
> However, somewhere around Firefox 10, the API calls to clear the cache
> became asynchronous. As a stopgap, I hacked them
> nsICacheService.EvictEntries to become synchronous.

The change was made just for dooming a single entry, not for clearing the whole cache. Anyway, now we have a new cache and it is asynchronous.


> As part of this process, we need to clear various aspects of browser state
> in a synchronous fashion, so that the user is unable to perform any
> navigation or browsing operations until the process completes.

I don't understand what you exactly need to wait for. Simply call nsICacheStorage.asyncEvictStorage() and assume the cache is cleared. It is guaranteed that asyncOpenURI() won't find any previous entry even if asyncEvictStorage() didn't finish yet.

Comment 3

[Honza Bambas (:mayhemer)]

Mike, you want to the code changes on ESR24?  ESR is currently on 38 (not sure what was the recent number).

Anyway, netwerk/cache is dead.  If you need anything do it in netwerk/cache2.

If your only concern is that the data in the cache are invisible/inaccessible to the platform then you don't need sync API.  When you do nsICacheStorageService.clear() anything previously stored in the cache is no longer accessible after clear() returned.  Actual data deletion happens in the background (all data moved to "trash.nnn" folder).

Is that enough?

Comment 4

[Mike Perry]

(In reply to Honza Bambas (:mayhemer) from comment #3)
> Mike, you want to the code changes on ESR24?  ESR is currently on 38 (not
> sure what was the recent number).
> 
> Anyway, netwerk/cache is dead.  If you need anything do it in netwerk/cache2.
> 
> If your only concern is that the data in the cache are
> invisible/inaccessible to the platform then you don't need sync API.  When
> you do nsICacheStorageService.clear() anything previously stored in the
> cache is no longer accessible after clear() returned.  Actual data deletion
> happens in the background (all data moved to "trash.nnn" folder).
> 
> Is that enough?

Yes, we are finally switching over to cache2, and the way the clear() method works is sufficient for our purposes. Thanks!