[Bug 17765] APIs need to take a reference to blob data underlying object URLs

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765

--- Comment #8 from Glenn Maynard <glenn@zewt.org> 2012-07-13 20:19:28 UTC ---
(In reply to comment #7)
> How does the UA tell the difference between parsed (please assume parsing and
> resolving becomes a single thing) blob URL and a parsed blob URL after it has
> been revoked? They need to be different.

They aren't different.  Once you pass a blob URL to an API, that API retains a
reference to the blob data.  Revoking the URL causes future uses of the URL to
fail, but not ones you've already handed off to APIs.

See the earlier example:

function openURLLater(url)
{
    xhr.open(url);
    setTimeout(function() { xhr.send(); }, 1000);
}

This would work, even if "url" is revoked between open() and send().  It'll
also work if blob.close() has been called (the reference is to the underlying
data, not the Blob itself).  XHR retains a reference to the blob data (attached
to the resolved URL).  Revoking the URL would never interrupt the XHR fetch
after send() is called, either.

Similarly (and more importantly, since this one is harder to sidestep), if you
say

    img.src = URL.createObjectURL(blob, {autoRevoke: true});

the "update the image data" algorithm takes a reference to the underlying blob
data (possibly on resolve).  That way, even though the fetch happens
asynchronously (the algorithm goes async in step 10) and the blob URL may be
revoked before the fetch begins, the fetch still has access to the blob data.

One other important detail, though: if a reference is taken to the blob data,
then the release of the reference needs to be defined too.  I don't know if
that can be done other than spec-by-spec.  XHR would want to do this when
entering the DONE state, for example; "update the image data" would do it when
the algorithm returns.

I suppose in principle you don't need to define this; just pretend the
reference is kept forever and leave releasing it as a QoI detail, since you can
derive when that data can no longer possibly be accessed from the spec
implicitly.  I'm not sure if that'd be a good idea or not...

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 13 July 2012 20:19:29 UTC