Discuss
  • Partial conclusions on WindowProxy and ES5 invariants

Partial conclusions on WindowProxy and ES5 invariants

# David Bruant (13 years ago)

In this message, I try to capture the conclusions of the couple of recent threads that happened regarding WindowProxy and ES5 invariants starting [1][2]. 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 bares repeating.
  2. WindowProxy don't allow the definition of new non-configurable properties via Object.defineProperty/defineOwnProperties (attempts to do this throw)
  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 cases) 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 [3]. 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 [4]. 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 configurable
  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 implementation-dependent)
  6. It's probably a given, but implementations are expected to instantiate fresh getters and setters each time navigation occurs in a browsing context.

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,

David

[1] lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0322.html [2] esdiscuss/2012-December/027080 [3] esdiscuss/2012-December/027223 [4] esdiscuss/2012-December/027145

# David Bruant (13 years ago)

Le 19/12/2012 17:52, David Bruant a écrit :

(...) 3) WindowProxy objects reflect [Unforgeable] properties as own configurable getters (properties like 'location' which are also [PutForward] also have a setter)

A different solution is suggested [1] and has a lot of support. With this solution, the couple of WindowProxy [Unforgeable] getters/setters would be deeply frozen (the function is frozen and all objects reachable from this function through properties, [[Prototype]], etc. are frozen too). Because it involves Function.prototype and Object.prototype and these can't be frozen, getter/setter would have their own deeply frozen version of Function.prototype and Object.prototype.

3.1) It does NOT change the semantics of [Unforgeable] for other objects (maybe 2 different annotations should be defined to differenciate the 2 cases)

This still applies. Regardless if configurable:true or deeply frozen getters/setters is chosen, there will be a need for 2 annotations to distinguish WindowProxy [Unforgeable] and other [Unforgeable].

David

[1] esdiscuss/2012-December/027194