[whatwg] Window and WindowProxy

[Ian Hickson]

On Thu, 8 Aug 2013, Boris Zbarsky wrote:
> On 8/8/13 2:11 AM, Ian Hickson wrote:
> > I would imagine most languages other than JavaScript would break that 
> > invariant.
> 
> Why are we suddenly worrying about languages other than JavaScript?

It's not sudden. The HTML spec has tried to be language agnostic since the 
beginning. WebIDL is similarly language-agnostic. The DOM specs, back when 
the W3C was maintaining them, were language agnostic. SVG was designed to 
be language agnostic. Attempts at adding new languages to the Web have 
been tried multiple times by multiple vendors (VB from Microsoft; Python, 
a while back, in the Mozilla world, and more recently asm.js, to some 
extent; Dart from Google, as well as some other related attempts like 
PNaCl; etc), with varying degrees of success. It would behoove us to not 
ignore all that, IMHO. While any new language naturally needs significant 
API work, we're still better being prepared than having the interaction of 
a new language with the Web API be completely undefined, leaving it 
entirely up to the whims of a new language group (especially since, 
historically, the people writing new languages intended for the Web are 
not the same people who are deeply embedded in core Web platform work).


> > > Because the current spec effectively calls for the global to be a 
> > > proxy-like object (or some sort of object that's not describable in 
> > > ES spec terms at all, of course, but the idea of ES proxies is to be 
> > > able to describe anything remotely sane).
> > 
> > No, the global object is the Window, at least per the spec today. Why 
> > is this not accurate?
> 
> The current spec calls for the Window to be a proxy-like object, because 
> that's the only way to implement the spec's indexed getter behavior.

I don't understand what you mean. What's different about Window's indexed 
getter behaviour than the indexed getter behaviours of all the other 
interfaces in HTML that have indexed getters?


> > > That's not actually compatible with ES because of how "var" needs to 
> > > behave in global scope.
> > 
> > Could you elaborate on this?
> 
> "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.

If WebIDL makes it hard for an object that has indexed and named getters 
to also be a [Global] object, then we should fix WebIDL, since 33% of the 
[Global] objects, and nearly 100% of the actual [Global] objects in the 
wild, have indexed and named getters.


> > > So it seems to me that any implementor trying to implement this spec 
> > > will go to their favorite ES implementation and discover that the 
> > > spec cannot be implemented as written and must instead be mapped to 
> > > some other conceptual model.  After thinking about it for a bit, the 
> > > only obvious way to avoid having proxy-like behavior on the Window 
> > > is to put it all on WindowProxy, which _already_ has proxy-like 
> > > behavior no matter what.
> > 
> > I don't understand what mapping behaviour you think is conceptually 
> > needed on Window.
> 
> I'm not sure what you mean.  The "mapping" that needs to happen is "how 
> do I have a global that's not a magic proxy while being black-box 
> compatible with the spec?"

The Window object is just a regular object as far as I can tell. It has no 
magical proxiness. That's only WindowProxy, which isn't the global.


> > > Indeed.  Of course WindowProxy is already not "just a proxy": it 
> > > doesn't transparently proxy enumeration or getOwnPropertyNames, for 
> > > example.
> > 
> > It should act _exactly_ like Window. As far as I can tell, that means 
> > it _should_ proxy "proxy enumeration" and getOwnPropertyNames, 
> > whatever those are. Why do you think this is not the case?
> 
> 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.

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.

That's what this means:

# all operations that would be performed on [a WindowProxy] must be
# performed on the Window object of the browsing context's active document 
# instead

It seems pretty unambiguous to me.


> 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. It should be _exactly_ like the Window object. The 
fact that references to the WindowProxy later magically morph so that they 
look like they're references to a different object is the only magic that 
WindowProxy has. In every other respect, it should just be the Window.


> See 
> http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0386.html 
> and the threads it references.  But of course Window is required to be 
> able to have non-configurable properties (see "var").  So WindowProxy 
> can't just forward [[GetOwnProperty]] on to the Window.

I think you're making this more complicated than it need be.

Conceptually, it's just that the pointers to Window objects get redirected 
to point to a different Window object when the browsing context navigates. 
It's as if script had gone through every variable that points to the first 
Window object and set the variable to point to the new Window object.


> How objects behave in ES are defined in terms of various internal 
> operations. The set of operations ... keeps changing.  It used to be 
> there were [[Get]], [[Set]], etc.  Now, with property descriptors, there 
> are lower-level primitives like [[GetOwnProperty]], [[DefineProperty]], 
> [[Delete]].  For example, WebIDL defines the behavior of all its objects 
> in terms of those three primitives.  These low-level primitivies and how 
> they interact define the meta-object protocol (MOP) for the abstract ES 
> virtual machine.

Every single MOP primitive for WindowProxy should just transparently proxy 
to the current underlying Window MOP primitive.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'