[Bug 25242] Blob.close should not set the blob's size to 0 or cause slice() to throw

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25242

--- Comment #7 from Glenn Maynard <glenn@zewt.org> ---
(In reply to Arun from comment #6)
> If a web app gets a file reference, allows it to be displayed, including
> with metadata extraction (ID3 / EXIF), and then posted to the server with
> FormData, but wants to close the object at some point.

I think I see the confusion.  You mean that FormData should succeed, even
though it's not a fetch of the blob.  I don't mean that the one and only thing
that should fail is fetch.  I mean that the failure should happen when you try
to access the blob's data, Fetch being the most common place that happens.

> The keepalive list posited in Bug 25302 might allow FormData to work even
> after the Blob has been neutered, but other operations on that neutered
> Blob, happening AFTER the closing, should know the Blob is closed, and maybe
> recreate the file picker. 

Posting FormData should do the same thing as fetch, and grab a reference to the
Blob so it's immune to the user closing the blob later.  The approach I
suggested in the other bug should work for this too.

> Rather than throw on a subsequent read operation, we could return 0 bytes.
> This makes it hard to differentiate between a *real* 0 byte Blob that is
> still OPENED, and a CLOSED Blob. That is the problem Jonas identifies, but
> I'm not sure what the use case would be for real 0 byte objects that aren't
> neutered.

This is the original thing that this bug is arguing against.  Blobs should be
immutable (or at least act as though their data is immutable) and never change
size.

If there are use cases for detecting if a blob is closed, then we should just
add a property to expose that.

> It's related in that I don't think the right approach is to retroactively
> close all the parents of slices; I agree that a slice on a neutered Blob
> should also be neutered, but I don't think neutering a slice neuters the
> parent (original object).

Closing a slice absolutely shouldn't close the parent.  Earlier on I suggested
that we might want to support the opposite (closing the parent optionally
closes its slices), but Jonas brought up some difficulties with that, and it
would be a separate feature anyway.  (It was only a minor side-benefit of what
I was suggesting, and derailed the discussion for a bit.)  We can forget about
that for now.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 9 April 2014 21:41:26 UTC