Re: Lifetime of Blob URL

On Fri, Jul 30, 2010 at 12:01 PM, Michael Nordman <michaeln@google.com> wrote:
>
>
> On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> Sorry about the slow response. I'm currently at blackhat, so my
>> internet connectivity is somewhat... unreliable, so generally having
>> to try to stay off the webs :)
>>
>> On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov <dimich@chromium.org> wrote:
>> > Thanks Jonas,
>> > Just to clarify some details we had while discussing this, could you
>> > confirm
>> > if this matches with your thinking (or not):
>> > 1. If blob was created in window1, blob.url was queried, then passed (as
>> > JS
>> > object) to window2, and window1 was closed - then the url gets
>> > invalidated
>> > when window1 is closed, but immediately re-validated if window2 queries
>> > blob.url. The url string is going to be the same, only there will be a
>> > time
>> > interval between closing window1 and querying blob.url in window2,
>> > during
>> > which loading from the url returns 404.
>>
>> Actually, it might make sense to make blob.url, when queried by
>> window2, return a different string. This makes things somewhat more
>> consistent as to when a URL is working an when not.
>
> Now suppose window2 queries the .url attribute before window1 is closed? I
> think most people would expect the same value as returned in window1 (yes?).
> Having the same or different value depending on whether the attribute was
> queried before or after another window was closed seems confusing. I think
> having the .url remain consistent from frame to frame/window to window could
> help with debugging.

The idea would be that we *always* return different urls depending on
which window queries a url. This gives the most consistent behavior in
that every url given is always limited to the lifetime of the current
window. No matter what windows around it does.

> Without fully understanding the gap between blob and .url life time, some
> folks are going to be mystified by when/why a url value stops working, or
> why the .url value is sometimes different than it was before. There are some
> pretty hidden side affect of accessing that attribute in a particular frame.
> These subtle oddities with the .url attribute are in part
> what originally motivated the proposal to make it more explicit.
> We're trying to make blob.url easy and natural feeling, but with too many
> caveats, will it be?
> I guess that's a long winded vote for resurrecting the same url value used
> in window1 in the particular case Dmitry raised.

I totally agree that this is not an ideal solution. However as far as
I can see there are no ideal solutions. The basic problem is that we
are using a string to reference a resource, and there is no way to let
a string value keep a resource alive.

Usually resource management is done by holding a reference to that
resource. Once there no longer are references to the resource the
resource can be deleted without anyone noticing. Ideal would be if you
could set:

myImageElement.srcFile = myFile;

However that would force us to add API to every single API that deals
with urls, thus making that option too non-ideal. Instead we have
chosen to have the ability to extract a url-string from the file,
leaving us with other non-ideal behavior in the case when a url is
transferred between windows.

/ Jonas

Received on Monday, 2 August 2010 20:47:20 UTC