Re: WindowProxy objects violate ES5 invariants

On Thu, Dec 13, 2012 at 10:32 AM, Mark S. Miller <erights@google.com> wrote:
> On Thu, Dec 13, 2012 at 9:27 AM, Allen Wirfs-Brock
> <allen@wirfs-brock.com> wrote:
>>
>> On Dec 13, 2012, at 8:14 AM, Boris Zbarsky wrote:
>>
>>> On 12/13/12 6:01 AM, David Bruant wrote:
>>>> whenever the underlying window of a WindowProxy can change
>>>
>>> Which is always.
>>>
>>>> the internal operations ([[DefineOwnProperty]],
>>>> [[GetOwnProperty]]) must throw whenever they're about to commit to an
>>>> invariant.
>>>
>>> That's not ok, unfortunately, because for security reasons we must be able to define things that look like non-configurable properties on a window.  Specifically, window.location needs to behave as if it were non-configurable for all intents and purposes; see the [Unforgeable] annotation in the spec there.
>
> The invariants say that you cannot claim to be non-configurable and
> then have observable changes that should have been possible. The

Should be: "...that should not have been possible..."

> invariants purposely allow the opposite "violation": a property can
> claim to be configurable but still refuse to be configured. This would
> be legal and solves your problem, but I think Allen's suggestion below
> is better.
>
>
>>>
>>>> More concretely, it means that a WindowProxy which can has its window
>>>> changed can't be made non-extensible
>>>
>>> This part is probably fine, though.
>>>
>>>> This change is not compatible with what's currently implemented in both
>>>> Chrome and Firefox, but I'm confident ES5 Object methods are not used a
>>>> lot in content and even less likely on WindowProxy instances, so I think
>>>> it's worth trying.
>>>
>>> So what do you propose getOwnPropertyDescriptor return for window.location?
>>
>> Note that the quoted invariants primarily are concerned with data properties. I would think that a non-configurable get only accessor property could do the job for window.location without violating those invariants.
>
> That sounds right to me.
>
>
>>
>> Allen
>>
>>
>>
>>
>
>
>
> --
>     Cheers,
>     --MarkM



--
    Cheers,
    --MarkM

Received on Thursday, 13 December 2012 18:38:24 UTC