Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Dec 14, 2011 at 11:27 AM, Adrian Bateman <adrianba@microsoft.com>wrote:

> On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote:
> >   imgElement.src = blob
>


> 3. It's not very obvious what the lifetime of the blob should be if it goes
>   out of scope after this happens.
>

This, at least, seems straightforward: the object (eg. imgElement) would
hold a strong reference to the blob.  It's also nice that this would still
work:

imgElement1.src = blob;
...
imgElement2.src = imgElement1.src; // we don't know anything about
imgElement1 here

which wouldn't work with self-releasing object URLs.

We can certainly talk through some of these issues, though the amount of
> work we'd need to do doesn't go down. Our proposal is a small change to
> the lifetime management of the Blob URL and was relatively simple (for
> us) to implement. In our experience, createObjectURL is a good broker
> in web developers minds for switching from object to URL space.
>

I'd expect making this fully interoperable to be a complex problem.  It
makes fetch order significant, where it currently isn't.

For example, if two images have their @src attribute set to a URL one after
the other, what guarantees which one succeeds (presumably the first) and
which fails (due to the first releasing the URL)?  The order in which
synchronous sections after "await a stable state" are run isn't specified.
Combining different APIs which do similar things (eg. asynchronous XHR and
HTMLMediaElement's resource selection algorithm) would compound the problem.

Another possible problem, depending on where the blob release takes place:
if the UA doesn't support images, "update the image data" for
HTMLImageElement terminates at step 4; it would need to be careful to still
release the blob URL when terminating before the fetch.

This would probably have effects across a lot of specs, and couldn't be
neatly tucked away in one place (such as inside the resource fetch
algorithm); and it might force every API that performs fetches to worry
about creating race conditions with other APIs.  Assigning the blob
directly would still affect various specs, but it would be less likely to
lead to blob leakage and subtle, possibly racy interop failures.

-- 
Glenn Maynard