Bucket hooks

[annevk]

@jakearchibald @jungkees hey! I was wondering what kind of hooks you need to make it clear e.g., service worker registrations and the Cache API are stored in a box.

In #4 we are discussing the cleanup steps for when a box gets closed, but maybe we should also have formal language for actually storing something inside?

[annevk]

On IRC Jake suggested that we could just have "bucket has an associated X" where X could be service worker registrations and such. This assumes that when clearing a bucket is replaced with a new one (allowing X effectively to be GC'd as there are no more references to it). Is that the model we want? Currently we just say a bucket is cleared.

One problem is that we'd have to copy some state over from the old bucket, such as persistence and potentially more in the future once we start expanding the concept. At least, I think if you clear, you don't necessarily expect to have to invoke persist() again.

Thoughts?

An alternative is that a bucket has something like a specification-level GetStorageHandler(Identifier, optional ClearCallback) operation that returns a StorageHandler in which you can store stuff.

cc @inexorabletash @mikewest

[jakearchibald]

An alternative is that a bucket has something like a specification-level GetStorageHandler(Identifier, optional ClearCallback) operation that returns a StorageHandler in which you can store stuff.

"A bucket has storages", and it's the storages that become detached.

Adding callback steps for cleanup is fine unless the order becomes observable.

[annevk]

I think the order will be observable given the combination of navigator.storage.clear() IDB, and Cache API. Probably also with other APIs.

https://w3c.github.io/webappsec-clear-site-data/#abstract-opdef-clear-dom-accessible-storage-for-origin deals with this through enumeration (though doesn't list the Cache API). My idea with the identifier was that we'd first sort lexicographically and then invoke the ClearCallback, but perhaps it's better to just list everything in the Storage Standard and require it to be updated as new things are added.

[jakearchibald]

perhaps it's better to just list everything in the Storage Standard and require it to be updated as new things are added.

That seems fine. Doesn't hurt to have all origin storage referenced from one place.

[mikewest]

perhaps it's better to just list everything in the Storage Standard and require it to be updated as new things are added.

I'd agree that this is the right approach. Clear-Site-Data would be better if it deferred to Storage, rather than requiring additional enumeration of storage mechanisms.