Partial conclusions on WindowProxy and ES5 invariants
bruant.d at gmail.com
Wed Dec 19 08:52:57 PST 2012
In this message, I try to capture the conclusions of the couple of
recent threads that happened regarding WindowProxy and ES5 invariants
I understand the following conclusions:
1) WindowProxy don't allow scripts to set their internal [[Extensible]]
to false (attempts to do this throw). This one was unambiguous, but
2) WindowProxy don't allow the definition of new non-configurable
properties via Object.defineProperty/defineOwnProperties (attempts to do
3) WindowProxy objects reflect [Unforgeable] properties as own
configurable getters (properties like 'location' which are also
[PutForward] also have a setter)
3.1) It does NOT change the semantics of [Unforgeable] for other objects
(maybe 2 different annotations should be defined to differenciate the 2
3.2) There is some ongoing discussion to add new property descriptors
attributes which would be used only for some objects (like WindowProxy)
to express that a property is configurable and yet non-deletable using
the 'delete' operator . Maybe this discussion will lead nowhere, but
it's worth being followed by anyone interested by WebIDL.
3.3) Brendan Eich noticed that current engines reflect window.location
as a data property . All of them are expected to change this as soon
as possible to comply to WebIDL.
4) All other own properties (wherever they're from) are reflected as
5) var/function globals are reflected as configurable for WindowProxy
(ECMAScript is likely to change its definition to still prevent the use
of 'delete' but let the choice of the configurable value
6) It's probably a given, but implementations are expected to
instantiate fresh getters and setters each time navigation occurs in a
If these partial conclusions are applied, WindowProxy respect ES5
invariants without making too much trouble or adding too much weirdness.
configurable:true may be felt as not expressive enough, so I encourage
people on the WebIDL side to participate to the discussion about the
eventuality to reflect different property descriptor attributes for
WebIDL objects in cases where it'd be necessary. Or the eventuality to
reflect this information in other ways if relevant.
Is there a disagreement on these partial conclusions?
Thanks to everyone who participated to these discussions,
More information about the es-discuss