- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 13 Dec 2012 11:14:28 -0500
- 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