Re: [FileAPI] createObjectURL isReusable proposal

On Fri, Jan 27, 2012 at 11:57 AM, Arun Ranganathan <aranganathan@mozilla.com
> wrote:

>  I'd expect making this fully interoperable to be a complex problem.  It
> makes fetch order significant, where it currently isn't.
>
> For example, if two images have their @src attribute set to a URL one
> after the other, what guarantees which one succeeds (presumably the first)
> and which fails (due to the first releasing the URL)?  The order in which
> synchronous sections after "await a stable state" are run isn't specified.
> Combining different APIs which do similar things (eg. asynchronous XHR and
> HTMLMediaElement's resource selection algorithm) would compound the problem.
>
>
> Adding this API increases the likelihood of a race condition; it may not
> do to simply go all Highlander on this problem ("There can be only one!")
> and leave it to implementations.  Is this an argument to *do away* with the
> dictionary key for "oneTimeOnly" or to make another spec modification that
> explicitly calls for a strong reference during HTMLMediaElement's resource
> selection algorithm (is such an ask even possible)?
>

I'm only arguing that adding an API that's racy by design should be
scrutinized very carefully.

I think to avoid raciness, the URL should be "consumed" *synchronously*
when it's used, even if the associated fetch is asynchronous.  This avoids
the problem of using a URL with multiple, unrelated APIs which consume the
URL from different task queues, where the order of the queued tasks aren't
defined relative to each other.

You point out later on [1] that this can also be true of revoke* for async
> XHR.
>

Right.  I didn't mean it as precedent to not concern ourselves with races,
though, just an acknowledgement that the platform isn't completely perfect
in this.

> Another possible problem, depending on where the blob release takes place:
> if the UA doesn't support images, "update the image data" for
> HTMLImageElement terminates at step 4; it would need to be careful to still
> release the blob URL when terminating before the fetch.
>
>
> This can be another spec detail for UAs that don't support images; in
> other words, should we have a section on revoke* ("advice to implementors")?
>

I think it'd be best to have the point at which the URL is considered
consumed to be a clear, explicit step in every algorithm that can consume a
single-use URL.  In other words, the point where the algorithm takes a
reference to the resource underneath the URL and revokes the object URL.  I
don't know the best way to do that, and I don't know how many algorithms
would be affected.  Presumably, a concise, reusable wording would need to
be found that could be plugged into other specs as easily as possible.

For example, "img.src = tempUrl1; img.src = tempUrl2" should be required by
spec to always consume both URLs, even if the first fetch didn't complete
before the second assignment happened.  (It would probably happen early in
the "update the image data" algorithm.)

A more complex, multi-API example: "img.src = tempUrl1; xhr.open('GET',
tempUrl1, false); xhr.send();".  That sets an image to the URL, then
immediately does a synchronous XHR on the same URL.  If the first
assignment synchronously consumes the URL, then the behavior is always
defined.  The XHR get will always fail, even if the fetch associated with
the img.src assignment hasn't yet happened, because the synchronous part
("update the image data") consumes the URL.

Something else that needs to be defined: does "xhr.open('GET', url)"
consume the URL, or does that only happen when xhr.send() is called?  (I'm
not looking for the answer here, just giving an example of something that
needs to be clearly defined.)

-- 
Glenn Maynard