W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2012

Re: WindowProxy objects violate ES5 invariants

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Thu, 13 Dec 2012 09:27:22 -0800
Cc: public-script-coord@w3.org
Message-Id: <D07280B3-6149-46DC-B855-1D7A33BC06D3@wirfs-brock.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

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

Received on Thursday, 13 December 2012 17:27:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC