Re: [FileAPI] createObjectURL isReusable proposal

On Wed, Feb 29, 2012 at 9:38 PM, Feras Moussa <ferasm@microsoft.com> wrote:

>  >Another case: whether loading a one-shot URL from a different origin,
> >where you aren't allowed to load the content, still causes the URL to
> >be revoked.  (My first impression was that it shouldn't affect it at
> >all, but my second impression is that in practice that error mode would
> >probably always result in the URL never being revoked and ending up
> >leaked, so it's probably best to free it anyway.)
> Similar to the above case, the URL is not revoked until after the data is
> accessed. If a URL is used from a different site of origin, the download
> fails
> and the data is not accessed, thus the URL is not revoked. Developers can
> notice this condition from the onerror handler for an img tag, where they
> can revoke the URL if it did not resolve correctly.
>

I think they'd be very unlikely to notice, because the only side-effect is
a reference leak wasting memory.  The entire point of this API is to handle
that collection for you; it should do it as consistently as can be
managed.  If you have to carefully watch onerror and release the URL in
some cases, then the problem hasn't been solved at all.

It makes more sense for the URL to be revoked upon entry to an API that
uses the URL.  The API, when it receives a URL, implicitly dereferences it
to the underlying resource (retaining that reference), and revokes the
URL.  This always happens, even if the fetch fails for any reason (such as
cross-origin restrictions), or even if the fetch never happens.

An example of another problem this solves: if a UA "obtains images on
demand" [1], it may never update the image data if the image is not
actually in a document (and possibly not even if it is).  If the URL is
only released on access (fetch), then it would never be released.  By
releasing the URL immediately (in this case, on assignment to
HTMLImageElement.src) and keeping an internal reference to the underlying
resource (the blob), this problem doesn't happen, and the release of the
URL happens at a consistent time, improving interoperability.

[1] http://dev.w3.org/html5/spec/Overview.html#the-img-element



>  > What do you think of a global release mechanism? Such as
> > URL.revokeAllObjectUrls();
> This wouldn't solve any of the problems previously listed in this thread,
> and would only be useful as a convenience API. That said, I'd question
> the trade-off of adding another API versus a developer writing their
> own version of this, which should be fairly trivial.
>

I think a "revokeAll" API would be very bad.  It would allow completely
unrelated pieces of code running on a site to interfere with one another;
using an API like this would almost always be the wrong thing to do.

We also think the spec should clarify what the expected behavior is for
> a revoked URL when accounting for the image cache. The concept of
> revoking URLs is to give the developer a way to say they are done with
> the object. If a user agent still has the bits in memory, it should not be
> in the business of blocking the URL from loading, even if it is revoked.
>

If the HTMLImageElement has already performed the fetch and has the
resulting data cached, and needs to access it again later (eg. because the
decompressed data was discarded while it was off-screen), then yes.
However, if you revoke a URL, then assign the URL to an image, that fetch
should always fail, even if the blob happens to have not yet been GC'd.  In
that case, the bits are in memory, but the URL should always fail to load.

-- 
Glenn Maynard