Blob.close() has several problems about fileapi HOT 9 CLOSED

It's (unfortunately?) not true that nobody implements close(). Chrome has had an implementation behind a flag for quite a while, and according to @dmurph we regularly get people asking us when we're finally going to ship it, and IE/Edge have had an implementation under the name msClose() since IE10. Not sure how close either of those implementations are currently following the spec though.

So I don't think just getting rid of close() is the right thing to do. Instead I'll try to audit all the callsites and edge cases to figure out what sensible behavior would be (and write tests to go with that, and see where the current Chrome and Edge implementations stand).

from fileapi.

See also #17 and #18

from fileapi.

So as far as I can tell nobody implements close(). Should we just remove it?

from fileapi.

Note that if we decide to keep and implement it, we need to carefully audit all callsites that take a blob and decide how they should handle a closed blob.

from fileapi.

That sounds reasonable. If you can put the processing model here for review before proceeding with enabling it by default that would be good. I'd like Firefox engineering to have a chance to review it first.

from fileapi.

So I played around with this a bit more myself, trying to figure out what sensible behavior would be for a bunch of situations. And I wrote some tests to see what Chrome and Edge currently do. Modulo throwing different types of exceptions Edge at least passes (almost all) those tests. Chrome unfortunately fairs a bit worse, mostly due to bugs in our implementation.

But writing those tests also made me realize that no matter how we treat closed Blobs in the various APIs, it's probably never going to be entirely nice and consistent.

Naively I would expect things to behave such that any kind of cloning of a blob/passing a blob to some kind of API behaves as if a completely new blob, with a completely new copy of the data was created. As such calling close() on one blob should not effect previously clones of that blob in any way (where clone means structured clone, new Blob([oldBlob]), oldBlob.slice(), or just passing the blob to any API that accepts a blob). Similarly closing one blob should revoke all URLs made for that specific blob instance, and leave alone all blob URLs that were made for clones of that blob instance. Chrome's current implementation fails pretty badly in this regard in a number of cases, edge seems to mostly get it right.

A more tricky question is what various methods should do when a closed Blob is passed to them. For consistency it could make sense to act similarly to how neutered array buffers are treated (for cases where both blobs and array buffers are valid options). That would mean that trying to postMessage a closed Blob would fail with a DataCloneException, but for example trying to pass a closed Blob as body to an XHR.send, or as body for a Response or Request will result in a valid zero-byte body instead (why is that the case for neutered array buffers anyway?)

Or maybe a more consistent model would be that any method that takes a Blob should throw if passed a closed blob, as it almost certainly is an error to pass a closed Blob to XHR.send, new Response, etc.

Finally there is the question what to do with blobs returned by various methods. XHR.response is documented to return the same Blob every time it is called, so closing that blob would really close the blob. On the other hand what should FormData.get do? Currently that method is seemingly specified to return the same File instance every time it is called (as it just returns the internal state directly), but what should happen if you close that returned instance?

So yeah, actually figuring this all out is far from trivial. And I'm sure I missed cases in my tests. Coming back to my current attempt at tests, Edge passes all my tests except that trying to XHR.send a closed blob throws an exception (yet posting a closed blob using fetch(new Request(...)) "works" and just posts zero bytes). Chrome is kind of all over the place...

from fileapi.

And I wonder if Microsoft has any usage stats for their Blob.msClose method...

from fileapi.

The behavior for a detached ArrayBuffer has historical baggage and still the specification and implementations are not aligned.

If we could just throw here that would be better I think, but you'll keep issues such as adding a Blob to a FormData instance and then closing it…

from fileapi.

I think I've actually changed my mind about Blob.close(). The main use-case I've heard for it is to allow websites to make sure memory is freed up when the website no longer needs the blob, to then for example allow it to create more blobs. But that particular use-case wouldn't actually be supported very well by Blob.close() as specified. One issue being that at least in the chrome implementation chrome might not actually be able to free up memory until some time later. And in that case it's not much better than just relying on garbage collection. Possibly a close method that returned a promise (that would resolve when the memory has been freed) would be more useful for this, but would also get even more confusing to explain to web developers. Also the fact that various ongoing usages of the blob might or might not keep the memory alive anyway seems like it would make it very difficult to explain what closing a blob would actually do, other than "the memory might get freed at some point in the future", which garbage collecting the Blob instance itself already does...

from fileapi.