This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"Stable state" is somewhat vague, since scripts can't really know when Blob URIs are auto-revoked.
It seems to me revoking after stable state would mean basically nothing could use the URL even if you try to use it in the same script, since things that fetch URLs are usually async (like e.g. <img src>).
Please define the term "microtask" first.
It is in HTML spec.
See https://www.w3.org/Bugs/Public/show_bug.cgi?id=16790#c4 for an example of why it should use stable states, not microtasks. (In reply to comment #0) > "Stable state" is somewhat vague, since scripts can't really know when > Blob URIs are auto-revoked. What's vague? It means URLs will always be revoked immediately and deterministically when your script returns to the event loop, at step 5 in the event loop processing model. (In reply to comment #1) > It seems to me revoking after stable state would mean basically nothing could > use the URL even if you try to use it in the same script, since things that > fetch URLs are usually async (like e.g. <img src>). Part of the autoRevoke mechanism would be making each place that uses URLs asynchronously like this convert (conceptually) from object URLs to underlying blob data synchronously. This has been brought up before but I'll make another mention of this in #16953. (In reply to comment #3) > It is in HTML spec. HTML doesn't define "microtask". All it defines is "perform a microtask checkpoint"; it doesn't give any mechanism to let other specs insert behavior when that happens (there's nothing like "queue a microtask"). It could be added, but #16790 settled on stable states for this.
(In reply to comment #0) > "Stable state" is somewhat vague, since scripts can't really know when > Blob URIs are auto-revoked. Bug 16790 was filed with this very purpose: to see if the "microtask" was more than just a magic word, and really could be bound to a concept that we could use. That bug's been closed because stable state could be what we need. Also note that Bug 16953 Comment 8 points out an important clarification to the autoRevoke algorithm: we're awaiting a stable state, not providing one. Does this make the stipulation less vague?
See Bug 19554