[Bug 16953] createObjectURL and oneTimeOnly behavior should be defined in terms of stable state

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

--- Comment #11 from Glenn Maynard <glenn@zewt.org> 2012-07-12 16:33:38 UTC ---
(In reply to comment #10)
> > You need to await a stable state, not provide one
> > (http://www.whatwg.org/specs/web-apps/current-work/#await-a-stable-state).
> 
> OK.  It seems that "await..." is merely used to flesh out "provide..." and I
> don't know if we can use "await..." in the imperative "must" sense.  It would
> seem that HTML5 should bolster this a bit.

They're two different pieces.  You "provide a stable state" when you're part of
a synchronous algorithm and you want things awaiting a stable state to execute.
 (You don't want this; this is what things like the event loop and the parser
do to trigger it.)  You "await a stable state" to wait for that to happen.

See http://www.whatwg.org/specs/web-apps/current-work/#update-the-image-data
for an example of how this is used (which is what I based the text on).

> The gist of what we want done is:
> 
> 1. To allow the task that spawned the autoRevoke algorithm to run
> asynchronously TILL the synchronous portions of that script block are done.
> 
> 2. Then to revoke the Blob URI.

This doesn't sound quite right.  What this is doing, conceptually, is queueing
some code (step 5) that will run the next time another algorithm says "provide
a stable state", then returning to the caller and continuing as normal.  The
task that spawned autoRevoke (namely, the user code calling createObjectURL)
doesn't run asynchronously; it simply continues synchronously as usual.

The only thing that's actually happening asynchronously is the "sit around and
wait for a stable state to show up" step (4).  Once that happens, the last step
(revoking the URL) happens synchronously, before the "provide a stable state"
algorithm (invoked externally) returns.

(Just making sure we're on the same page--we're probably just thinking of the
same thing in different terms.)

> (1. above seems to take care of the genre of use case mentioned in Comment 9,
> since assignments based on the Blob URI that's been coined are synchronous).

This will definitely work for that sort of thing, at least once the "take a
reference on src assignment" stuff is done.  (We've talked about that before
but it needs to be fleshed out and specced.  I'll file a separate bug for that
later today.)

> Assuming that our understanding is correct, I think Comment 8 is what I'll put
> in the spec.

One thing I missed: step 5 (release the URL) needs to happen in a synchronous
section, to guarantee it completes before "provide a stable state" returns. 
See  update-the-image-data; I think we can just append "The synchronous section
consists of all the remaining steps of this algorithm." to step 4.

-- 
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 Thursday, 12 July 2012 16:34:41 UTC