Re: WindowProxy objects violate ES5 invariants

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
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

Received on Thursday, 13 December 2012 18:32:59 UTC