Deferred: behavior different from ECMAScript Promise for objects with [[Call]]

[akihikodaki]

Description

jQuery's Deferred is expected to be a close approximation to Promise of ECMAScript 2016 Language Specification. Promise defined in ECMAScript 2016 tests onFulfilled, onRejected and then are objects with [[Call]].
However, isFunction, used in the Deferred, tests toStringTag, which is irrelevant from the definition. As the result, Deferred shows different behaviors for some objects such as GeneratorFunction.

Link to test case

https://jsbin.com/civabuxabe/1/edit?js,console
Expected [object Generator] { ... }, but results in 0.

jQuery.Deferred()
  .resolve(0)
  .then(function *() {})
  .then(console.log);

[gibson042]

Confirmed, but I would classify this as a bug in jQuery.isFunction rather than Deferreds, and consider improper detection of async functions to be an even bigger flaw. I'd love to switch to typeof, but doubt we actually can, especially in a minor release... even lodash still goes by toStringTag.

[akihikodaki]

lodash says:

Checks if value is classified as a Function object.

However, the standard requires the callbacks are functions (objects implementing [[Call]]). jQuery.isFunction and _.isFunction is inappropriate for the purpose.

[gibson042]

It can be rather difficult to perfectly determine if an object has a [[Call]] internal method, and there are some tough edge cases (none of which we properly detect now):

• In IE9, which we still support, XML host objects have callable properties like getElementsByTagName for which typeof returns "unknown".
• In modern browsers, document.all is callable but has typeof "undefined".

The intent of jQuery.isFunction is to serve as a reasonable approximation of ECMAScript IsCallable, and we're not going out of our way to catch every possible trick but I for one want it to recognize generators and async functions. So maybe we are at the point where typeof makes the most sense. @jquery/core would anyone else like to weigh in?

[akihikodaki]

It can be rather difficult to perfectly determine if an object has a [[Call]] internal method, and there are some tough edge cases (none of which we properly detect now):

I was not aware of these cases. By the way, I tested the second case. document.all was not callable on Firefox 52. It was callable on Chromium 57, but jQuery.isFunction(document.all) returned false. I'm still investigating those cases.

The intent of jQuery.isFunction is to serve as a reasonable approximation of ECMAScript IsCallable

A test suggests it is different from ECMAScript IsCallable.

	obj = document.createElement( "object" );

	// Firefox says this is a function
	assert.ok( !jQuery.isFunction( obj ), "Object Element" );

jquery/test/unit/core.js

Line 442 in ac9e301

obj = document.createElement( "object" );

It is callable. We may need to clarify the expected behavior of jQuery.isFunction. I have opened an issue. jquery/api.jquery.com#1034

[akihikodaki]

So maybe we are at the point where typeof makes the most sense. @jquery/core would anyone else like to weigh in?

Opened #3601.

[gibson042]

If we pursue a fix for #3600 (which I'd like to do), then the only requirement to resolve this issue will be new unit tests.