Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Boris Zbarsky]

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 
the window.

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 
run into.

Just wanted to get this written down while it's fresh in my mind,
Boris