This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#processing-model-4 Complete: http://www.whatwg.org/c#processing-model-4 Referrer: Comment: Say "provide a stable state" if that is equivalent Posted from: 42.112.56.121 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36 OPR/19.0.1326.45 (Edition Next)
http://www.whatwg.org/specs/web-apps/current-work/#pause says "If any asynchronously-running algorithms are awaiting a stable state, then run their synchronous section and then resume running their asynchronous algorithm. (See the event loop processing model definition above for details.)" This looks identical to "provide a stable state", so just use that if it's equivalent. (When trying to implement awaiting/providing a stable state, I nearly missed this bit because of the wording.)
I'd also like to know why a stable state should be provided here. In none of the places that pause tasks does it seems particularly important to do this, is there a potential deadlock I'm missing?
Consider the case of a page that create a video element, then does alert("Ok, I've started the load!"). The user sees the alert, thinks "I'll go for lunch while it loads", comes back... and we haven't yet started the load, if we don't provide a stable state here.
Checked in as WHATWG revision r8460. Check-in comment: Fix one case where we provide a stable state but describe it oddly. http://html5.org/tools/web-apps-tracker?from=8459&to=8460
(In reply to Ian 'Hixie' Hickson from comment #3) > Consider the case of a page that create a video element, then does > alert("Ok, I've started the load!"). The user sees the alert, thinks "I'll > go for lunch while it loads", comes back... and we haven't yet started the > load, if we don't provide a stable state here. OK, I suppose that's reasonable.
i think that it'd be clearer in the spec to have one notion of "do my stuff after script has done doing it's thing". i suggest refactoring the stable state stuff to use microtasks instead. as for comment 3, i think it's not worth muddying a fairly clean concept by attempting to accommodate this (fairly exotic) use.
This bug is closed, so I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24724 instead.