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

Re: WindowProxy objects violate ES5 invariants

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 13 Dec 2012 11:14:28 -0500
Message-ID: <50C9FEE4.40003@mit.edu>
To: public-script-coord@w3.org
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?

> It's been pointed that a script can add a non-configurable property to
> its global object [5] and there is no reason to prevent that. So from
> the spec perspective, there would bit 2 types of WindowProxy:
> * Those which are guaranteed to never change the underlying window (and
> can add non-configurable properties)
> * Those which can change the underlying window (and should never do
> anything committing to invariants)

How would you decide which one to use, exactly, when you have to hand 
out a WindowProxy?

> What do you think of the problem?

It seems like a pretty abstract problem with not much relevance to 
actual web authors, honestly.  I can see how it's a problem for internal 
consistency, of course...

> What do you think of the suggested solution?

I'm still trying to understand the proposal.

> I'd like to write tests to be added to the webapps test mercurial. But
> before doing so, I'd like to know the exhaustive list of cases and
> conditions where:
> * one has access to a WindowProxy which is guaranteed to never have its
> underlying window changed

Never.

> * one has access to a WindowProxy which may have its underlying window
> changed

Any time you have a WindowProxy.

-Boris
Received on Thursday, 13 December 2012 16:14:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:08 UTC