Hi all, As probably many of you remember, in the past we had several issues with deleting site data. The main reason was that we have too many ways to delete data and they were/are out of sync: ForgetAboutSite, Sanitizer.jsm for android, Sanitizer.jsm for desktop, etc (some data is deleted by some components and not others). Plus, in the future we could have more components which will need to delete site data.
I want to introduce nsIClearDataService. A new service that cleans up data. See bug 1422365. ForgetAboutSite and Sanitizer.jsm have been already ported to nsIClearDatService. The next task will be to change Sanitizer.jsm for android (bug 1466130). This service can delete data by nsIPrincipal, or by hostname, or by time range, or all the data. With bitmap flags it's possible to specify what needs to be deleted. E.g. CLEAR_COOKIES | CLEAR_NETWORK_CACHE | CLEAR_IMAGE_CACHE | CLEAR_DOM_STORAGES. See patch 1 for the full list of flags. Not all the components are able to delete data by nsIPrincipal, or hostname or by time range. For this reason, nsIClearDataService uses a "is-this-a-user-request" boolean parameter. The idea behind this is: if the user wants to delete data, more is better than less. E. g., if we cannot delete _foobar_ data by nsIPrincipal, let's try to delete by host. If also this is not possible, better to delete all _foobar_ data for any host/principal/time range. On the other hand: if the request comes from an API or an exposed component (Clear-Site-Data spec for instance), less is better than more: if we cannot delete _foobar_ by host, definitely we don't want to delete all the _foobar_ data for any host/principal/time range. Of course the plan is to support delete-by-host, delete-by-principal and delete-by-range for each component. This will be done in follow up bugs. I implemented this feature exactly for Clear-Site-Data spec where a website can delete all its data passing a HTTP header in the response (Clear-Site-Data is not ready to land yet). I hope you find this component useful. Note for the DOM/QuotaManager/ServiceWorker people: this component covers all the DOM storages under 1 single flag: CLEAR_DOM_QUOTA. This is done because I know that the integration of localStorage and ServiceWorkerRegistrar into QuotaManager is in progress. Plus, there are no reasons to delete just localStorage, or just ServiceWorkers or just IDB data. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
