Figuring out the behavior of WindowProxy in the face of non-configurable properties
bzbarsky at mit.edu
Wed Jan 14 21:50:05 PST 2015
On 12/4/14 5:58 AM, Boris Zbarsky wrote:
> OK. What do we do if we discover that throwing from the defineProperty
> call with a non-configurable property descriptor is not web-compatible?
Based on a nice long conversation Yehuda and I just had, if we end up
there and really want to preserve all the current invariants we could
try a hybrid approach inspided by the Safari implementation. To whit:
1) Assume that we can distinguish when we're "inside" a window and when
we're "outside" it. For example, compare the current Realm's global to
2) When inside the window, everything works as normal: you can define a
non-configurable property on the window you're inside,
getOwnPropertyDescriptor will claim it's non-configurable, etc. At
least while that window is current. Once it's non-current, I haven't
tested what Safari does and am not sure what we could/should spec.
3) When outside the window, where observing navigations is easy, we try
to apply one of the possible mitigations: throw on defineProperty that's
non-configurable or whatnot, report all props as configurable, etc.
This seems to be all kosher if we assume a membrane between inside and
outside the window, such that we're actually operating on different
objects in the two cases...
This may mitigate the compat impact depending on what compat issues we
Just wanted to get this written down while it's fresh in my mind,
More information about the es-discuss