- From: Domenic Denicola <notifications@github.com>
- Date: Fri, 06 Mar 2020 11:06:09 -0800
- To: heycam/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <heycam/webidl/issues/847@github.com>
Discovered by @syg in a different context: https://github.com/tc39/ecma262/pull/1597#issuecomment-595560524 First, an easy problem. > Although at the time of this writing the ECMAScript specification does not reflect this, every ECMAScript object must have an associated Realm. The mechanisms for associating objects with Realms are, for now, underspecified. However, we note that in the case of platform objects, the associated Realm is equal to the object’s relevant Realm, and for non-exotic function objects (i.e. not callable proxies, and not bound functions) the associated Realm is equal to the value of the function object's [[Realm]] internal slot. This should probably use [GetFunctionRealm](https://tc39.es/ecma262/#sec-getfunctionrealm), which handles callable proxies and bound function objects. OK, but callable proxies have an additional issue. Given ```js const { proxy, revoke } = Proxy.revokable(() => {}, {}); revoke(); ``` we have IsCallable(_proxy_) being true, but GetFunctionRealm(_proxy_) throws a TypeError. I don't think any uses of "associated Realm" throughout the web spec land are prepared for TypeErrors. One particular case is in https://heycam.github.io/webidl/#es-invoking-callback-functions and its nearby counterparts. That should probably rethrow the TypeError, or convert it to a rejected Promise, as appropriate. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/heycam/webidl/issues/847
Received on Friday, 6 March 2020 19:06:22 UTC