By reviewing more carefully the Proxy internal methods, I have found the
following glitch in [[OwnPropertyKeys]].
https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys
<https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys>
Testcase:
```js
var base = Object.freeze({x: 1})
var target = new Proxy(base, {
ownKeys(o) {
return ['x', 'x']
}
})
Object.keys(target) // ['x', 'x'] // ok; according to ECMA262, Chrome, and
Safari TP; buggy in Firefox
var proxy = new Proxy(target, {
ownKeys(o) {
return ['x']
}
})
Object.keys(proxy) // !!! throws in ECMA262, Chrome, and Safari TP; should be
fixed so that it returns ['x']
```
The issue is in step 17:
17. Repeat, for each key that is an element of targetNonconfigurableKeys,
a. If key is not an element of uncheckedResultKeys, throw a TypeError
exception.
b. Remove all occurrences of key from uncheckedResultKeys.
because targetNonconfigurableKeys contains a list with twice the value 'x',
and, at the second iteration, a TypeError is thrown in step a.
The solution is simple: step 14 should guard against duplicate keys when
constructing targetNonconfigurableKeys and targetConfigurableKeys. Additional
text marked in bold:
14. Repeat, for each element key of targetKeys,
I. If key is not already an element of targetNonconfigurableKeys or
targetConfigurableKeys, then
a. Let desc be ? target.[[GetOwnProperty]](key).
b. If desc is not undefined and desc.[[Configurable]] is false, then
i. Append key as an element of targetNonconfigurableKeys.
c. Else,
ii. Append key as an element of targetConfigurableKeys.
―Claude
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss