W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

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

From: <bugzilla@jessica.w3.org>
Date: Thu, 12 Jul 2012 23:04:00 +0000
To: public-webapps@w3.org
Message-ID: <bug-17765-2927@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765

           Summary: APIs need to take a reference to blob data underlying
                    object URLs
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: File API
        AssignedTo: arun@mozilla.com
        ReportedBy: glenn@zewt.org
         QAContact: public-webapps-bugzilla@w3.org
                CC: public-webapps@w3.org


This is the remaining portion of the autoRevoke blob URL feature.  APIs that
take URLs and then operate on them asynchronously need to synchronously take a
reference to the underlying blob data before returning.

For example, when you say "img.src = URL.createBlobURL(blob)", the image fetch
doesn't necessarily begin immediately.  It may not happen until well after the
script returns.  Currently, that means that by the time the fetch begins, the
URL would no longer exist, because it's released as soon as the script returns.

To fix this, "img.src = blobURL" needs to take a reference to the underlying
blob data before the assignment returns.  Then, all fetches that would normally
operate on the @src URL actually take place on the blob data.

For example, using XHR2 as an example, "Associate blob data with *url*" would
be added as a step after 6 (after resolving the URL).  The "associate blob data
with url" algorithm would look up the Blob associated with the URL, and
associate the underlying data of that blob to it (or do nothing if it's not a
blob URL).  That way, the blob data tags along with the URL when it's lter sent
to fetch (when send is called).

(In case this isn't clear, this is treating XHR2's "url" property as a
string-like object with a property hanging off it, and this wouldn't be visible
to scripts.  It's essentially shorthand for passing a (url, blob) tuple to
fetch.)

As a side-effect, this also prevents "img.src = URL.createObjectURL(blob);
blob.close();" from being nondeterministic.  Currently, it depends on what
stage the image update was at.

One other note: all APIs should attempt to take this reference at the time the
URL enters the API (eg. when xhr.open is called), not at some later point (like
xhr.send).  That is, this should still always work (for any API) without caring
if the caller gave you a blob URL:

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

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 12 July 2012 23:04:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:53 GMT