W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: File API "oneTimeOnly" is too poorly defined

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 28 Mar 2012 17:49:03 -0700
Message-ID: <CA+c2ei_BoaqDbBms73F15i7hQB_3gYns-gum==2Deh4AhYhFDw@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: public-webapps WG <public-webapps@w3.org>
On Wed, Mar 28, 2012 at 4:36 PM, Glenn Maynard <glenn@zewt.org> wrote:
> Here's another proposal, which is an iteration of the previous.  It's based
> on the "microtask" concept, which is creeping up here and there but hasn't
> yet been properly defined.  The idea is that microtasks can be queued (call
> it "queue a microtask"), and the microtask queue is executed by the event
> loop as soon as the current task completes, so it executes as soon as the
> outermost task returns to the event loop.
> oneTimeOnly (a poor name in this proposal) would simply queue a microtask to
> revoke the URL.
> This is simpler, and answers a lot of questions.  It means you can use the
> URL as many times as you want synchronously, since it's not released until
> the script returns.  Any cases where the ordering may not be strictly
> defined (eg. the <video><video> case in
> http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1265.html may
> be like this; I don't know how innerHTML works, exactly) are now defined:
> both <video> elements would get the object.
> It has another nice side-effect: it's much less prone to leaks.  For
> example, under previous approaches, the following code would leak the blob:
> function updateProgressMeter() { throw "obscure error"; }
> url = URL.createObjectURL(blob, {oneTimeOnly: true});
> updateProgressMeter();
> img.src = url; // never happens
> Since the URL is never actually used, the blob reference leaks.  You'd have
> to work around this with careful exception handling, which is precisely the
> sort of thing oneTimeOnly is supposed to avoid.  With this proposal, the URL
> would always be revoked when the script returns to the event loop, whether
> or not it was actually used.
> This would still require work in each URL-consuming spec, to define taking a
> reference to the underlying blob's data when it receives an object URL.  I
> think this is inherent to the feature.
> "oneTimeOnly" would be the wrong name with this approach; it should be
> something like "autoRelease".
> This has one drawback: it doesn't work nicely in long-running Workers, which
> may never return to the event loop at all.  I think that's probably an
> acceptable tradeoff.

This is an interesting idea for sure. It doesn't solve any of the
issues I brought up, so we still need to define when dereferencing
happens. But it does solve the problem of the URL leaking if it never
gets dereferenced, which is nice.

/ Jonas
Received on Thursday, 29 March 2012 00:50:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:39 UTC