It is not clear to me what Promises do right now, but last time I check they were not using microtasks but something else. Microtasks were initially designed for MutationObserver, and that is what the original implementation is too.

Just looked at what Promises do, and it is very different to what microtasks actually are.

I'll try to find time to fix this one, but if anyone is interested in this, feel free to take :)

The following test shows that our Promises don't actually use microtasks but some setup where checkpoint is at the beginning of a task or at the end of a task. But end of microtask (microtask checkpoint) should be by default at the end of the outermost script execution or at the end of task. data:text/html,<script>window.addEventListener("click", function() { console.log(1);}); window.addEventListener("click", function() { Promise.resolve().then(function() {console.log(2)});}); window.addEventListener("click", function() { Promise.resolve().then(function() {console.log(3)});}); window.addEventListener("click", function() { console.log(4);});</script>Click me and look at the ordering in web console

(In reply to Olli Pettay [:smaug] from comment #3) > data:text/html,<script>window.addEventListener("click", function() { > console.log(1);}); window.addEventListener("click", function() { > Promise.resolve().then(function() {console.log(2)});}); > window.addEventListener("click", function() { > Promise.resolve().then(function() {console.log(3)});}); > window.addEventListener("click", function() { > console.log(4);});</script>Click me and look at the ordering in web console Here are some tips I found from current implementation. Please correct me if wrong: 1. These 4 EventListeners are triggered by a single task in the event loop. 2. The 2 resolve callbacks are put into the microtask queue by CycleCollectedJSRuntime::EnqueuePromiseJobCallback() in [1] after Promise.resolve.then() is invoked. 3. After the single task in #1 is done, all the microtasks will be executed in CycleCollectedJSRuntime::AfterProcessTask() in [2]. In addition, in [2], we can see that the MutationObservers are executed by nsContentUtils::PerformMainThreadMicroTaskCheckpoint() which is in prior to the execution of microtask queue, i.e., Promise::PerformMicroTaskCheckpoint() in CycleCollectedJSRuntime::AfterProcessTask(). [1] https://hg.mozilla.org/mozilla-central/file/tip/xpcom/base/CycleCollectedJSRuntime.cpp#l963 [2] https://hg.mozilla.org/mozilla-central/file/tip/xpcom/base/CycleCollectedJSRuntime.cpp#l1379

yeah, and nsContentUtils::PerformMainThreadMicroTaskCheckpoint() is also called whenever LeaveMicroTask is called (with mt level going to 0), which happens when nsAutoMicroTask goes out of stack or when it is called explicitly by callback code like http://searchfox.org/mozilla-central/rev/d83f1528dbcb1e837d99cf5b6c36a90b03bf0e77/dom/bindings/CallbackObject.cpp#290

I guess we need to merge the queues Promises and MutationObservers use, and then trigger the callbacks the way MutationObserver callbacks are called (and make that stuff work in workers too, since MutationObservers are mainthread only).

Do we do the reentry thing with microtasks where we don't reenter microtask processing if we're already processing microtasks? Last I checked we did not, which meant promise ordering would get screwed up if we actually processed them whenever we promise microtasks... See also discussion in bug 1193394, of which this one may be a duplicate.

In common case we do process all the scheduled mutation observers before the ones which are scheduled during the mutation observer callback calls, so the ordering should be correct. That code hasn't changed for ages.