W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Window and WindowProxy

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 8 Aug 2013 21:05:27 +0000 (UTC)
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Message-ID: <alpine.DEB.2.00.1308082052130.27623@ps20323.dreamhostps.com>
Cc: whatwg@lists.whatwg.org
On Thu, 8 Aug 2013, Boris Zbarsky wrote:
>
> (again, in ES6 terms)

I think the problem is that I have no idea what these ES6 terms are or 
what they mean.

Was all this a problem in previous revisions of JavaScript? Or is it some 
new problem caused by some new JavaScript feature?


> > > "var" needs to be able to define non-configurable properties.  
> > > Proxies don't necessarily offer useful guarantees about being able 
> > > to define such properties on them, and in particular the behavior 
> > > for index/named getters in WebIDL precludes definition of 
> > > non-configurable properties of the corresponding kind on the 
> > > relevant object.
> > 
> > I don't understand what this means, sorry.
> 
> Hmm.  Which part is unclear?

I have basically no idea what any of it means. I understand all the 
individual words of that paragraph, but I've no idea what they mean when 
put next to each other in that order. :-) A property is just an entry in 
the bag that is a JS object, what does it mean for it to be or not be 
configurable? A proxy is something that passes incoming requests from one 
object to another object, and passes the responses back; what does it mean 
for a proxy to have a property? Etc.


> > > Because getOwnPropertyNames should return the own properties of the 
> > > object, but doing that on a WindowProxy for a cross-origin window 
> > > should not in fact return the Window's own properties.
> > 
> > Yes, it should. At least, IMHO.
> 
> Er... That's a cross-site information leak.

How so? The names of the IDL attributes and methods on Window objects are 
the same on all Window objects (WindowModal notwithstanding), and the 
non-IDL properties aren't enumerable cross-origin.


> > WindowProxy should be _completely indistinguishable_ from the Window 
> > it currently points to, except for the way it can be distinguished 
> > when what it points to changes.
> 
> OK, so in this view there are multiple (one per origin, roughly) Window 
> objects in JS all representing the same underlying browser object?

"For members that return objects (including function objects), each 
distinct effective script origin that is not the same as the Window 
object's Document's effective script origin must be provided with a 
separate set of objects. These objects must have the prototype chain 
appropriate for the script for which the objects are created (not those 
that would be appropriate for scripts whose script's global object is the 
Window object in question)."


> I don't understand how this can work with document.domain, where things that
> used to not be same-origin suddenly become same-origin

(same effective origin) 

> in that situation two different origins become the same origin and the 
> fact that they have different Window objects for the same current window 
> ends up observable.

Well, what the spec says now is that when the script changes effective 
origin, it also changes its prototypes and so forth, essentially. This 
isn't very explicit, though. I don't really have a strong opinion on what 
this should do (I'm all for dropping document.domain wherever we can).


> > > Or another similar issue: getting a property descriptor from a 
> > > WindowProxy (for a same-origin window) should probably never claim 
> > > to have a non-configurable property, because on navigation the 
> > > property will in fact disappear and non-configurable properties are 
> > > not allowed to do that in ES.
> > 
> > IMHO, yes, it should.
> 
> That's not allowed in ES.  Do see the thread I linked to.

We (the Web community) can change what's allowed and what isn't allowed. 
We do so all the time.


> > Conceptually, it's just that the pointers to Window objects get 
> > redirected to point to a different Window object when the browsing 
> > context navigates.
> 
> Let me try to make this clearer.
> 
> If an object (in this case a WindowProxy, since that's what the script 
> is working with) ever claims that it has a non-configurable property for 
> some property name, ES requires that it _always_ do that from that point 
> on.

That's fine. The Window will keep having that property. The WindowProxy 
object's own properties can't be examined, because it just proxies (not in 
the ES6 meaning, whatever that is, but in the English meaning) everything 
to the underlying Window object.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 8 August 2013 21:05:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC