I think you may want to add some unit tests using a Promise lib, or just plain old native Promises. Since the implementation of jQuery.fn.ready returns this, and you're assigning that function to your thenable object, you're essentially getting into this scenario:

var myCrazyPromise = { then: function() { return this; };
Promise.resolve(myCrazyPromise).then(console.log.bind(console));

If you run that, you'll see that the then handler is never invoked since this is infinitely recursive

Test added, but no changes required. Notice that while jQuery.ready is a thenable, jQuery.fn.ready is not.

Hmm, thinking about this wrong. Maybe it's only a problem pre-ready event.

I was thinking about it wrong (context is still jQuery.ready), but I don't see the problem you're describing whether it's before the ready event or not. Do you see anything wrong with my test?

Oh, blurp, I think this is a misunderstanding of Promise.resolve(thenable). Promise.resolve(thenable) follows the thenable and eventually defers to its state. This means that the thenable is responsible for calling .then. Notice that your example doesn't resolve even when you don't return this. For example, this works fine...

var myCrazyPromise = { then: function (fn) { fn(); return this; } };
Promise.resolve(myCrazyPromise).then(function() { console.log('resolved'); });
// Promise instance resolves asynchronously

Yep, I agree with that. Apparently I'm not as familiar with thenables as I thought.

FWIW part of my confusion may be attributed to something that seems weird in Chrome, but I have no idea if this is a legitimate thing.

If you run Promise.resolve(jQuery.ready) then inspect the internal [[PromiseValue]] the returned promise, you can see that the value the promise was resolved with is not what was passed to the .then handler; the resolved value is jQuery.ready as I had initially expected. Might be an implementation and/or devTools bug, but it doesn't look like it has any observable side effects other than confusion.

This is not the easiest to read. Would breaking it up increase the size? What size penalty would it bring to just use booleans?

I'd prefer to such "clever coding" to be performed by Uglify, not in source.

Because the invocations are synchronous and not wrapped in a try block, jQuery.ready is not a conforming Promises/A+ promise. This should either include the explanatory comment from #1778 (comment) or be corrected (not that that would be sufficient, but it would prevent callback lockups).

I'd update this to "promise-consumable"; it's more clear and might head off too much effort being spent on bugs like jQuery.ready.then( fn ).then(…) not working as expected.

As coded, this still halts execution until a subsequent handler is added. But you could fix it with a setTimeout( whenReady ) here.

As you say, this only fixes the case where ready could never be called again. I'm not sure we need to go beyond that.

It would certainly be more Promise-compatible to have

jQuery.ready.then( throws );
jQuery.ready.then( shouldRun );

work without waiting for a subsequent jQuery.ready.then invocation. And fixes don't get much simpler than setTimeout( whenReady ).

Seems like we'd have to add a catch. Wouldn't putting the whenReady call in the finally block cause an infinite loop?

We don't need a catch, and the whenReady doesn't go infinite because the throwing callback has already been .shift()ed off the list.

I don't see how it wouldn't be a loop. A finally is called regardless of whether an error is thrown, so it would just keep calling itself.

So by not having a catch, it also barfs immediately on the console right? That's a good thing.

It keeps calling itself, but will terminate when the callbacks list is empty: https://jsfiddle.net/ewjschzw/

So by not having a catch, it also barfs immediately on the console right? That's a good thing.

Yes.

Oops; I see what you mean @timmywil... you just need to move the try into the loop (I thought it was already there) check readyCallbacks.length.

Ah, yes, that would work.

Would it help for the check for fn being a function be done here?

As long as you duplicate it in the redefinition of whenReady. Doing it this way is just conceptually simpler, and it's not like the function test is expensive.

Agreed, given that it's inexpensive, I'd want to do whichever is smaller. Right now, that would be what we currently have.

Retrying synchronously here swallows all but the last exception generated by a block of readyCallbacks (e.g., jQuery.ready.then( thrower ); jQuery.ready.then( thrower )): https://jsfiddle.net/ewjschzw/1/

I think a setTimeout is necessary.

Thanks, didn't notice that.

The whole point of deprecating stop() semaphore in favour of assert.async() was to discourage fragile patterns like this. The code should reflect care of which callback gets popped by which sub path. E.g. create them explicitly and have each mark its own subpath as complete.

var resolveDone = assert.async(),
    promisifiedDone = assert.async();

..
    promisifiedDone();
..
    resolveDone();

Otherwise, at least simplify with var done = [ assert.async(), assert.async() ];.

This is a pattern we already use in several places. Regardless, we'll switch patterns when we update QUnit.

You want to somehow detect such pattern? You mean update to 2.0... or?

@Krinkle assert.async now accepts a number specifying how many times its result should get called so this is sort of blessed by upstream currently... We planned to switch to this pattern once we update QUnit.

I have updated QUnit to 1.20.0, so after rebase, you can start using new signature in this pull