Normative: Remove proxy OwnPropertyKeys error with duplicate keys

[bterlson]

Previously, proxy OwnPropertyKeys returning duplicate keys would cause an error when the target object was non-extensible. The error does not seem deliberate but rather a result of not considering the possibility of duplicate keys. This PR handles that possibility and removes the error.

I think this is just a bug fix but if anyone thinks this needs consensus let me know. Also note that this is a breaking change for spidermonkey and chakra. V8 already implements these semantics. cc @efaust.

[bterlson]

Also cc @msaboff.

[efaust]

No objections, your honor.

[littledan]

Looks good to me; this is what we do now if I understand correctly.

[saambarati]

@bterlson We currently throw an exception, but we can fix that.

[bterlson]

Alright, thanks! Since all the implementers that currently throw are on board with this change I'll go ahead and accept this as a bugfix. Thanks!

[saambarati]

@bterlson
The algorithm you wrote seems to have odd semantics when targetConfigurableKeys or targetNonConfigurableKeys itself has duplicate properties. I think this will always cause an exception in either loop. Is this intended? I haven't thought too hard about it, but I think it's possible for those lists to have duplicates.

[bterlson]

I am currently thinking hard about this as well. Starting by testing everyone's implementation (except JSC, which I don't have running on windows :()

[bterlson]

v8, sm, and Chakra all throw in this case per spec:

var obj = {};
Object.defineProperty(obj, 'a', { value: 42 });

var p1 = new Proxy(obj, {
  ownKeys() {
    print('getting p1 keys');
    return ["a", "a"]
  }
});

var p2 = new Proxy(p1, {
  ownKeys() {
    print('getting p2 keys');
    return ["a"]
  },
  getOwnPropertyDescriptor(t, p) {
    print('getting own property ' + p);
    return Reflect.getOwnPropertyDescriptor(t, p);
  }
});

print(Reflect.ownKeys(p2));

Removing the duplicate key from the p1 proxy doesn't result in an error. I think this is also a bug that should be fixed. Agree @littledan, @saambarati, @efaust, @evilpie?

[bterlson]

There are probably a bunch of possible fixes, but possibly easiest is to keep a list of seen keys in the step 14 loop and skip any seen keys. This will make sure that we only ever get the descriptor for a duplicated property once.

[saambarati]

@bterlson Why not just only add things to every list if it's not already in the list?

[bterlson]

IIUC, then we'd do [[GetOwnProperty]] N times for N-duplicated keys, which seems possibly bad (you could get very strange behavior if the proxy decided that the key was configurable the first time and non-configurable the next time). This might be fine? But not processing the key at all seems easier.

[saambarati]

@bterlson I wasn't suggesting that. I'm suggesting, for example, to change this line:
"Append key as an element of targetConfigurableKeys."
to
"Append key as an element of targetConfigurableKeys if key is not already in targetConfigurableKeys".

Also, thinking about this more, there are some other weird semantics. I think the intersection between targetConfigurableKeys and targetNonconfigurableKeys may be non empty. That seems weird. I wish we enforced them having an empty intersection. I'm not 100% sure if Proxy's would allow you to fake this, but I suspect it would and then one of those loops is guaranteed to throw an exception.

[saambarati]

@bterlson To clarify on my first point, I don't think that'd change how many times [GetOwnProperty] is called. targetKeys will still be a list with maybe repeating elements.

[saambarati]

@bterlson
Sorry, I just must have skipped over your comment about step 14. I see it now. Sorry for duplicating your proposal. I agree that this is probably the easiest thing to do, and it is what I was suggesting too.

[raulsebastianmihaila]

@bterlson It seems to me that the changes from this PR contradict what has been discussed in #461.

[bterlson]

@raulsebastianmihaila Thanks for pointing that out! I can whip up a PR removing duplicate keys (unless someone else is gung ho about it).

[anba]

Thanks for pointing that out! I can whip up a PR removing duplicate keys (unless someone else is gung ho about it).

@bterlson Ping?

[bterlson]

@anba gah I dropped this, thanks for pinging me. I have a start but it needs rebasing. Will work on this tomorrow.

[bterlson]

@anba I actually lied to you, sorry to say; I'm in an all-day meeting today.