Function identity of non-configurable accessors
Tom Van Cutsem
tomvc.be at gmail.com
Wed Dec 19 05:29:17 PST 2012
2012/12/15 David Bruant <bruant.d at gmail.com>
> ES5 invariants are silent when it comes to function identity of
> non-configurable accessors. That is, for a given object o,
> Object.**getOwnPropertyDescriptor(o, 'a').get === Object.**getOwnPropertyDescriptor(o,
> (two seperate calls) is not guaranteed.
> The built-in [[DefineOwnProperty]] (ES5.1 - 8.12.9) prevents from changing
> of getter and setter functions when the property is not configurable (step
> 11), but that's not an expected invariant for self-hosted objects.
> I think that the current definition of non-compatible descriptors (based
> on Object.**getOwnPropertyDescriptor and Object.defineProperty) used in
> invariant checks makes impossible to use different functions and that may
> be a problem.
Indeed, proxies enforce this invariant. I don't see this as a problem.
> The way things are going, WindowProxy [Unforgeable] properties will be
> non-configurable getters. If, upon underlying window change, the
> WindowProxy is expected to keep the exact same getter function, then, it
> may result in capability leaks (attach something in a getter in one iframe
> and get it back when the iframe at src has changed). One solution could be
> to make these getters frozen; a better solution would be to not "same
> getter identity" as an invariant for proxies reflecting non-configurable
It seems you are arguing to weaken probably the most important ES5
invariant ("non-configurability implies stability", as Mark put it
succinctly) to support the emulation of a pretty exotic object.
Re. the potential capability leak: even if the get/set attribute of a
non-configurable property could be updated, how does that prevent the leak?
Code that could previously access the old value of the getter via a
WindowProxy can presumably as easily access the new value of the getter via
the same WindowProxy.
To me, the issue does not seem to be related to non-configurable accessors,
but rather to the fact that when a WindowProxy changes location, you expect
"old" clients of the WindowProxy to no longer be able to access "new"
target state. That seems impossible if both old and new clients share the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss