Harmony proxies: Object.getOwnPropertyNames(proxy) calls getOwnPropertyDescriptor trap

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
P2
normal
RESOLVED WORKSFORME
8 years ago
7 years ago

People

(Reporter: Tom Van Cutsem, Assigned: gal)

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; nl-nl) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16
Build Identifier: Tracemonkey (hg.mozilla.org/tracemonkey tip 199d64731816+ July 26, 2010)

Experimenting with Harmony proxies reveals that calling Object.getOwnPropertyNames(proxy) on a trapping proxy leads to unexpected behavior.

The following hg.ecmascript.org test cases fail:
* [ err] tostringarray-getOwnPropertyNames (TypeError: getOwnPropertyDescriptor is not a function)
* [ err] args-getOwnPropertyNames (TypeError: getOwnPropertyDescriptor is not a function)

Object.getOwnPropertyNames(proxy) calls the proxy handler's getOwnPropertyDescriptor trap for each property name returned by the getOwnPropertyNames trap. This is unexpected and should not be necessary. The above tests fail because the proxy handler does not define a getOwnPropertyDescriptor trap.

What is more: the implementation seems to call the 'getOwnPropertyDescriptor' trap in order to filter out non-enumerable properties. This seems wrong: getOwnPropertyNames should not filter out non-enumerable properties. Object.getOwnPropertyNames(proxy) should just return whatever handler.getOwnPropertyNames() returns, coerced into an array of strings.

Reproducible: Always

Steps to Reproduce:
Execute a script such as:

    var p = Proxy.create({
      getOwnPropertyNames: function() { return ["a"]; },
    });
    
    var result = Object.getOwnPropertyNames(p);
Actual Results:  
TypeError: getOwnPropertyDescriptor is not a function

Expected Results:  
The call to getOwnPropertyNames should return an array ["a"]

To run the test suite that tests the harmony proxies specification:

hg clone hg.ecmascript.org/tests/harmony/
cd proxies
./gentests > runtests.js
js runtests.js
(Reporter)

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
(Assignee)

Comment 1

7 years ago
Created attachment 479497 [details] [diff] [review]
patch
Assignee: general → gal
Status: NEW → UNCONFIRMED
Ever confirmed: false
(Assignee)

Updated

7 years ago
Attachment #479497 - Flags: review?(jorendorff)
(Reporter)

Updated

7 years ago
Assignee: gal → general
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

7 years ago
blocking2.0: --- → ?
>                 if (flags & JSITER_OWNONLY) {
>-                    if (!JSProxy::enumerateOwn(cx, pobj, proxyProps))
>+                    if (!JSProxy::getOwnPropertyNames(cx, pobj, proxyProps))
>                         return false;
>                 } else {
>                     if (!JSProxy::enumerate(cx, pobj, proxyProps))
>                         return false;
>                 }
>                for (size_t n = 0, len = proxyProps.length(); n < len; n++) {
>                    if (!Enumerate<EnumPolicy>(cx, obj, pobj, proxyProps[n], true, false, flags, ht, props))
>                        return false;
>                }
Hmm. Now we'll get all the property names, but we'll unconditionally pass true to the 'enumerable' parameter of Enumerate.

I think it is possible to get here with the JSITER_OWNONLY flag set but not JSITER_HIDDEN, and the behavior would be buggy, right?
Attachment #479497 - Flags: review?(jorendorff)
A test would be good, too, especially a test that

    for (k in Iterator(proxyobj, true))

reveals only properties that proxyobj says are enumerable and own.

Updated

7 years ago
blocking2.0: ? → final+
QA Contact: general → gal
Assignee: general → gal
QA Contact: gal → general
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
Unblocking on the assumption that full Harmony proxies spec support is not a required goal for Fx4. Correct me if I'm wrong.
blocking2.0: final+ → -

Comment 5

7 years ago
This bug cannot be reproduces in FF4b11.
(Assignee)

Updated

7 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 6

7 years ago
Re-executed my original tests, everything works fine now.
You need to log in before you can comment on or make changes to this bug.