W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

[Bug 22320] Form's supported property names should perhaps not be enumerable

From: <bugzilla@jessica.w3.org>
Date: Wed, 10 Jul 2013 20:05:53 +0000
To: public-script-coord@w3.org
Message-ID: <bug-22320-3890-cXgNJJIei0@http.www.w3.org/Bugs/Public/>

Tom Van Cutsem <tomvc.be@gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |tomvc.be@gmail.com

--- Comment #33 from Tom Van Cutsem <tomvc.be@gmail.com> ---
Mark asked me to post the following, for the record, as evidence that the JS
getOwnPropertyNames operation does come with a number of invariants defined in

Looking at JavaScript proxies, which are the tool one would use to self-host
this in JavaScript, even a proxy cannot claim to be non-extensible and claim
(via getOwnPropertyNames) to have no own properties, but later claim by other
means (e.g. getOwnPropertyDescriptor) to have own properties.

In other words, the result returned by getOwnPropertyNames should be consistent
with the result returned by e.g. getOwnPropertyDescriptor.

Test case:

var target = Object.preventExtensions({});
var proxy = new Proxy(target, {
 getOwnPropertyDescriptor: function(target, name) {
   if (name === 'foo') {
     return {value:42};

Object.isExtensible(proxy) // false
Object.getOwnPropertyNames(proxy) // []
Object.getOwnPropertyDescriptor(proxy,'foo') // TypeError: cannot report a new
own property 'foo' on a non-extensible object

IOW, if getOwnPropertyNames returns the empty array (and the object in question
is non-extensible), then that object should also not report the existence of
own properties through other traps.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 10 July 2013 20:05:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:17 UTC