Re: [w3c/IndexedDB] Spec mostly doesn't mention blob expectations (Issue #454)

evanstade left a comment (w3c/IndexedDB#454)

You're right, sorry, the WPT only covers record deletion. Chromium's tests for db deletion are only internal unit/integration tests. [Here](https://chromium-review.googlesource.com/8476232) is the additional WPT that (arguably) should exist.

Chromium does indeed allow the database to be deleted without affecting the blob. Internally, this keeps certain files alive and C++ objects in memory, and those are cleaned up when the blob is GC'd. (Chromium does have a common blob store, but IDB blobs are only _referenced_ by it, FWIW.) As far as I can tell, this behavior has been there since the [initial implementation of Blobs in IDB](https://issues.chromium.org/issues/40130006).

I think the Chromium behavior is likely the most desirable and intuitive even though it does require additional implementation complexity.

> Arguably if the storage spec explicitly had a [storage endpoint](https://storage.spec.whatwg.org/#storage-endpoints) for blobs

Blobs never persist across browser restart except when they're in IndexedDB, so they aren't really "storage" in the same sense. (Even when blobs theoretically should persist, they don't, like when a blob is stored in `History.pushState` and the browser restarts, retaining the notion of session --- in this case the restored history `state` has missing data. Although I guess it's arguable whether this is "persistent" since "session" is somewhat transiently persistent.)

> in terms of navigator.storage.estimate()

I suppose in the case where a blob is still being served out of an otherwise-deleted DB, that blob will count against quota, whereas no other blob counts against quota. But quota accounting is so fuzzy to begin with I don't see this as a huge practical concern. I don't think it would be difficult to change Chromium behavior to correctly ignore these blobs.

> also the GC-dependency is also not great.

In Chromium, the database is conceptually deleted regardless of the existence of handles to blobs that were served by that database, so GC timing only affects internal bookkeeping. A database of the same name can of course be re-created while the blobs still exist, and this is handled as well.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/454#issuecomment-5873868583
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/454/5873868583@github.com>