The execution order of the promise according to the return type

I would like to know the reason why the execution order varies depending on what is returned in a then callback:

<!-- begin snippet: js hide: false console: true babel: false -->

<!-- language: lang-js -->

var a = Promise.resolve();

var b = a.then(function a_then() {
  console.log(1);
  var c = Promise.resolve();
  var d = c.then(function c_then() {
    console.log(2);
  });
  var e = d.then(function d_then() {
    console.log(3);
  });
  console.log(4);

  return c; // <--- this influences the output order

});

var f = b.then(function b_then() {
  console.log(5);
  var g = Promise.resolve();
  var h = g.then(function g_then() {
    console.log(6);
  });
  var i = h.then(function h_then() {
    console.log(7);
  });
  console.log(8);
});

console.log(9); 

<!-- end snippet -->

Without that return c (so returning undefined), the output order is: 9,1,4,2,5,8,3,6,7 and this order was explained as an answer to my previous question.

But adding that return c changes the output order to 9,1,4,2,3,5,8,6,7.

Why is the value 3 now output before values 5 and 8? Why is the order of the events like this?

NB: A similar change in output happens when returning d or e.

It would be very nice if you could explain it using the table that was used as answer to my previous question:

When a fulfills, the callback a_then will be executed. The return value of that callback determines how b resolves. If that then callback returns a promise (like c), a core feature of promises kicks in: the promise b will not simply fulfill with that returned promise object, but will instead remain pending and get "locked-in" to the returned promise: the way promise c will settle will determine how b will settle -- b's fate is locked-in to that of c.

The Promise internal implementation that called a_then makes this happen by inspecting the returned value. It detects that this returned value is a thenable (it has a then method), and will actually plan to call that then method (c.then in this case) as that is the only way to get informed about the settled state of that thenable (c in this case). It will pass its own (internal) callback to that then method.

This is a callback that is not part of your JS code -- it is provided by the Promise implementation (see the ECMAScript specification on Promise resolve functions step 13). Moreover, this call of c.then will happen asynchronously (see step 14 in the same specification). We can imagine that asynchronous job to look something like this (simplified):

function lockin_b(c) {
    c.then(function fulfill_b(value) {
        _fulfill(value)
    });
}

...where _fulfill is the internal function with which b can be settled.

So, in summary, there are two extra asynchronous jobs involved in this locked-in scenario:

1. The asynchronous call of c.then by the Promise internals so to lock-in b to c
2. The asynchronous call of the callback passed to c.then when c is resolved.

This means that b will settle later than when that return c would have been omitted, and consequently the b_then callback that outputs 5 and 8 will also execute later.

Here is a sequence of events that happen during the execution of that code.

• The first column represents what is executing (the main script, a function initiated from the event loop, or the host that dequeues an item from the PromiseJob queue)
• The second column has the current expression/statement being evaluated
• The columns a to i represent the state of the promise with that name: ? for pending, F for fulfilled and R for resolved, but not yet settled (i.e. locked-in).
• The last column pictures what is present in the PromiseJob queue, managed by the host

One can make a similar analysis for when the return statement in the b_then function returns a different promise. It is the same principle.