Re: Lifetime of Blob URL

Tying a 'lifetime' of a string url to a blob which is not even needed at the
point of use seems to be creating a mechanism that doesn't generally work:

function getImageUrl() {
  var a_blob = ... load a blob in some way, perhaps via XHR
  return a_blob.url;
}

... // sometime during initialization
var imageUrl = getImageUrl();

... // sometime later
anImage.src = imageUrl;

This may work all the time on the developer's computer and fail all the time
(or sometimes) in the field. It may be very frustrating. Tying
lifetime explicitly to the Window (url dies when window closes or revoke()
is called) does not fix all the issues but makes the mechanism less likely
to shoot the user in the foot by making it more explicit.

Dmitry

On Tue, Jul 13, 2010 at 7:37 AM, David Levin <levin@google.com> wrote:

>
>
> 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
>
>
>