I've seen the same pattern, though mysteriously, running a revoke in the same loop still allows the image to be loaded. I may have made a mistake in reading those source files or it may be a special quirk in the order of event loading.
However this is approached, I think it should have firm roots in the operation of the event loop. On Dec 13, 2011, at 4:52 PM, Adrian Bateman <adria...@microsoft.com> wrote: > At TPAC [1,2] I described our proposal for adding an isReusable flag to > createObjectURL. A common pattern we have seen is the need for a blob URL > for a single use (for example, loading into an <img> element) and then > revoking the URL. This requires a fair amount of boilerplate code to > handle the load/error events. > > createObjectURL is modified as follows: > > static DOMString createObjectURL(Blob blob, [optional] bool isReusable); > > The value of isReusable defaults to true if it is not supplied and this > results in the behaviour documented for File API today. However, if you > supply false for the flag then the first dereference of the URL revokes it. > > This means that you can do something like: > > imgElement.src = URL.createObjectURL(blob,false) > > and not worry about having to call URL.revokeObjectURL to release the Blob. > > We have implemented this in experimental form in IE10 preview builds and > it works well. There seemed to be a fair amount of support at TPAC and we're > hoping this will be adopted in the File API spec. > > Thanks, > > Adrian. > > [1] http://www.w3.org/2011/11/01-webapps-minutes.html#item02 > [2] http://pages.adrianba.net/w3c/FilesAndStreams.pdf > > >