What is correct execution sequence when attach multiple handlers to the same promise.

[azu]

The test case(in general, bad case...):

var p = new Promise(function(resolve, reject){
    console.log("start");
    resolve("");
});

p.then(function () {
    console.log("1-1");
}).then(function () {
    console.log("1-2");
}).then(function () {
    console.log("1-3");
});

p.then(function () {
    console.log("2-1")
}).then(function () {
    console.log("2-2");
}).then(function () {
    console.log("2-3");
});

The result of Firefox 35.0a1 and native-promise-only :

"start"
"1-1"
"1-2"
"1-3"
"2-1"
"2-2"
"2-3"

The result of Chrome 37.0.2062.94 , @domenic's reference-implementation (code) and native-promise-only:

"start"
"1-1"
"2-1"
"1-2"
"2-2"
"1-3"
"2-3"

Which is correct?

[getify]

Which is correct?

Both. No, seriously. Both.

There's actually no standard (nor will there be, apparently) that talks about the semantics of ordering between two different promises, only within a single promise. There's just simply no guarantees that can be made across two or more promises in any general sense.

See these threads for more info on this:

• Sequencing of promise resolution not being tested promises-aplus/promises-tests#61 (comment)
• Callback ordering promises-aplus/promises-spec#77

[azu]

@getify Thanks!

[domenic]

There's actually no standard (nor will there be, apparently) that talks about the semantics of ordering between two different promises, only within a single promise.

That's not correct. Promises/A+ does not give a standard for that, but ES6 does.

The second set of results are correct per spec, due to the nature of the microtask queue as FIFO.

[getify]

@azu

I apologize for too quickly skipping validating your original question and jumping to a conclusion. I should have checked that what you were asking was in fact valid. See below...

The result of Firefox 35.0a1 and native-promise-only :

"start"
"1-1"
"1-2"
"1-3"
"2-1"
"2-2"
"2-3"

Actually, that's not how NPO behaves. NPO behaves in this case exactly as you quoted Chrome and @domenic's reference implementation:

Here, go try it yourself. :)

I'm not sure if perhaps you were using an older NPO, or if perhaps you thought you were testing NPO but weren't actually, since it by-default is a polyfill that only installs itself if the global Promise symbol isn't already present? The above example link tweaks the normal NPO polyfill such that it installs itself as Promise_NPO so we are guaranteeing that NPO is running, even in environments where the native global Promise also exists.

[getify]

@domenic

but ES6 does... due to the nature of the microtask queue as FIFO

I suggested/asserted exactly this multiple times in those earlier linked discussions, as well as in other (not linked) discussions about creating the ES6 Promise test suite in particular. As you'll recall I was repeatedly told (as those earlier links clearly show) that no such semantic was intended between promises. It was implied as an indirect side-effect of the FIFO queue usage that there might be special cases (like this OP) where inter-promise sequencing was predictable.

If generalized inter-promise sequencing is totally expectable and reliable, why then was there pushback to my suggestion to create a ES6 test for inter-promise sequencing?

This particular example (being simplified as it is) is explainable (and predictable) directly through FIFO reasoning, I agree.

But in the general case where promises are resolving at different times, again as those earlier linked discussions asserted, there should be no reliance on inter-promise sequencing.

"Tests, or it didn't happen." If the spec implies something but there's no test to verify and guarantee it, I don't consider it a valid requirement. So, if there's since been an ES6 test designed for inter-promise sequencing, I apologize -- I certainly have tried to keep up to speed on these issues, and I clearly wanted such a test back when I was pushing for it.

But until there is definitely such a test, I stand by the assertion that people should not rely on the general case of inter-promise sequencing.

[domenic]

Those earlier discussions were all within the context of Promises/A+, not ES6 promises. I don't see anything in my replies in the linked threads that pushes back against any work on an ES6 test suite done independently from Promises/A+.

[azu]

@getify

since it by-default is a polyfill that only installs itself if the global Promise symbol isn't already present?

Oh... my bad. native-promise-only work fine!
(I edited #34 (comment))

[getify]

I've filed FF #1062323 about the incorrect ordering. I would imagine that bug won't get fixed until there's an agreed conformance test, but... shrugs.