[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 #10 from Arun <arun@mozilla.com> 2012-07-12 16:20:30 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > 1. autoRevoke is true by default, since there's much resistance to having
> > developers call revokeObjectURL.  In this model, *unless* developers include
> > the autoRevoke="false" dictionary member syntax with a createObjectURL call,
> > they don't need to call revokeObjectURL.
> 
> Isn't it too late to change the default?  createObjectURL has been in the wild
> for quite a while without this.

Yes, but there's also been enough of an outcry against making the default
pattern necessitate a revokeObjectURL call that it seemed best to make the
default pattern autoRevoke.  Comment 9 suggests to me that as long as we
address the majority use case, the temporary pain of changing an implementation
is worth the longer term gain of a better default pattern.

> 
> 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.

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.

(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).


> 
> You don't need to describe what happens when the dictionary argument is
> omitted; WebIDL will give you the default.

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

-- 
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:20:36 UTC