Re: Lifetime of Blob URL

On Tue, Jul 13, 2010 at 6:50 AM, Adrian Bateman <adrianba@microsoft.com>wrote:

> On Monday, July 12, 2010 2:31 PM, Darin Fisher wrote:
> > On Mon, Jul 12, 2010 at 9:59 AM, David Levin <levin@google.com> wrote:
> > On Mon, Jul 12, 2010 at 9:54 AM, Adrian Bateman <adrianba@microsoft.com>
> > wrote:
> > I read point #5 to be only about surviving the start of a navigation. As
> a
> > web developer, how can I tell when a load has started for an <img>? Isn't
> > this similarly indeterminate.
> >
> > As soon as img.src is set.
> >
> > "the spec could mention that the resource pointed by blob URL should be
> > loaded successfully as long as the blob URL is valid at the time when the
> > resource is starting to load."
> >
> > Should apply to xhr (after send is called), img, and navigation.
> >
> > Right, it seems reasonable to say that ownership of the resource
> referenced
> > by a Blob can be shared by a XHR, Image, or navigation once it is told to
> > start loading the resource.
> >
> > -Darin
>
> It sounds like you are saying the following is guaranteed to work:
>
> img.src = blob.url;
> window.revokeBlobUrl(blob);
> return;
>
> If that is the case then the user agent is already making the guarantees
> I was talking about and so I still think having the lifetime mapped to the
> blob
> not the document is better. This means that in the general case I don't
> have
> to worry about lifetime management.
>

Mapping lifetime to the blob exposes when the blob gets garbage collected
which is a very indeterminate point in time (and is very browser version
dependent -- it will set you up for compatibility issues when you update
your javascript engine -- and there are also the cross browser issues of
course).

Specifically, a blob could go "out of scope" (to use your earlier phrase)
and then one could do img.src = blobUrl (the url that was exposed from the
blob but not using the blob object). This will work sometimes but not others
(depending on whether garbage collection collected the blob).

This is much more indeterminate than the current spec which maps the
blob.url lifetime to the lifetime of the document where the blob was
created.

When thinking about blob.url lifetime, there are several problems to solve:
1. "An AJAX style web application may never navigate the document and this
means that every blob for which a URL is created must be kept around in some
form for the lifetime of the application."
2. A blob passed to between documents would have its blob.url stop working
as soon as the original document got closed.
3. Having a model that makes the url have a determinate lifetime which
doesn't expose the web developer to indeterminate behaviors issues like we
have discussed above.

The current spec has issues #1 and #2.
Binding the lifetime of blob.url to blob has issue #3.

dave