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

asutherland left a comment (w3c/IndexedDB#454)

The test is slightly misleading as it only tests record deletion, not database deletion.  In Firefox [a bug was recently filed with a test case using database deletion](https://bugzilla.mozilla.org/show_bug.cgi?id=2033168) that demonstrates that in Gecko that holding onto an IDB-backed Blob will not prevent the database from closing/being deleted and so the Blob becomes invalid because our blob storage is specifically tied to the database (we don't have a common blob store currently).  Reports in the bug [suggest Chrome may keep the Blob alive but not block the database deletion](https://bugzilla.mozilla.org/show_bug.cgi?id=2033168#c0) whereas [Safari may block the database deletion and thereby keep the Blob alive](https://bugzilla.mozilla.org/show_bug.cgi?id=2033168#c4), but I have not validated either and I may be parsing the description of what happens in Chrome incrorrectly.

[Jan's current proposal for Gecko](https://bugzilla.mozilla.org/show_bug.cgi?id=2033168#c4) would be to (match our understanding of Safari) such that we would block database closure, which is both the easiest implementation fix for us and arguably the most straightforward for spec purposes in terms of navigator.storage.estimate() (and [usageDetails](https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate#usagedetails)), but has the problem that [especially because Blob.close() was removed from the File API](https://github.com/w3c/FileAPI/issues/10), database deletion then becomes potentially quite messy/unreliable, especially as it relates to Blob URLs[1], but also the GC-dependency is also not great.

Arguably if the storage spec explicitly had a [storage endpoint](https://storage.spec.whatwg.org/#storage-endpoints) for blobs the spec thing could be potentially a little simpler in terms of defining that any living blob references at the time of deletion get to keep existing but they are notionally moved into the blob-store bottle.  (I think we'd roughly discussed having something like that in terms of multiple storage buckets.)

1: For Blob URLs  the [blob URL entry](https://w3c.github.io/FileAPI/#blob-url-entry) conceptually keeps a Blob and its content alive even after revocation.  Step 4 of [URL parsing](https://url.spec.whatwg.org/#url-parsing) entrains that Blob URL entry ("Set url’s blob URL entry to the result of resolving the blob URL url") in a way that's arguably messy because from an implementation perspective we do absolute care about the difference between JS calling "new URL(...)" which parses a URL but does not allow a load of the Blob URL, and calling fetch/XHR, etc.  I believe Chrome has a concept of blob URL tokens which are used to track the need to be able to get at the blob contents because of this.

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

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