Quoting https://crbug.com/795735#c3

    the backing store used by Indexed DB lazily compacts data written to the log, 
    so the quota estimations are approximate. Like memory/garbage collection, 
    the usage will grow until the database does a collection pass. 
    This enables higher throughput at the expense of reporting accuracy. 
    At some point - on the order of table sizes, which are in the low megabytes - 
    a threshold will be passed and the data will be restructured.

Devtools seems to force the compaction, see  bug 729790 .

Tried testing the issue on chrome reported version# 70.0.3538.67 using Windows-10 with steps mentioned below:
1) Launched chrome reported version, dragged and dropped the file provided in comment# 0
2) Clicked on "add data" button, seen value changed above 'count' button and 'estimate' button
3) Clicked on 'clear' button, able to see only data got cleared above 'count' button but not above the 'estimate' button

@Reporter: Please find the above mentioned information and attached screencast for your reference and provide your feedback on it which help in further triaging it it.

Thanks!

Deleted: 898145.PNG 12.1 KB

	898145.PNG 12.1 KB View Download

Hi,

that's exactly the issue I'm experiencing. The digit above the count button shows the currently persisted row count (0 after clearing the store). However, the storage used by Blobs is not released and reported as used by the StorageManager and chrome://indexeddb-internals .

If ArrayBuffer is used, however, the used space is reclaimed after more data is written to the database.

I've added a button to add both Blobs and ArrayBuffers to demonstrate the issue. If ArrayBuffers are used, Chromium also seems to compact the contents and uses less space (the buffers consist of 0x00, not part of the issue).

Deleted: dexie.html 2.7 KB

dexie.html 2.7 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

dmurph@: Please investigate?

I suspect that we keep the Blob file around until garbage collection, because the renderer still has a handle to the Blob. We could use DevTools to verify this hypothesis.

Also, this can be done once Scopes is over, if you want to look into IDBBackingStore.

We already have situations where a blob can become detached, for example when clear-site-data is used.  Since this state already exists to some degree, maybe we could propose an explicit `.detach()` or something to explicitly close the handle.  That could help the case where you want to get rid of something large deliberately, but also explain other corner cases in the platform.

This is because the blob also have a reference in the renderer, and we rely on garbage collection to destroy the JS blob object, which will delete the underlying file.

If a URL was created for the blob, then this will cause the blob to stay alive until that URL is revoked by the website author.

We used to have a 'close()' method, but it turns out there are a lot of edge cases with blobs, as they can be shared between browsing contexts & origins, and their urls can also be sent around indiscriminately.

So basically, it looks like this is WAI, unless we see that the blob data isn't destroyed on JS garbage collection. Please re-open / re-comment if this is the case.

Adding mek@ just in case - they did a lot of work in this space.

Actually I have one question here for #1 - does javascript ever read in this data? Or is it always in IndexedDB?