Re: Lifetime of Blob URL

On Mon, Aug 2, 2010 at 1:39 PM, Jonas Sicking <jonas@sicking.cc> wrote:

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

If that's the idea, then I would vote for a non-instance method somewhere to
provide the context specific URL. Having a simple attribute accessor return
different values depending on which context its being accessed in is very
unusual behavior.

Can't say that its "ideal", but window.getBlobUrl(blob) and
window.revokeBlobUrl(...) would be an improvement.


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