The global object in browsers

Maciej Stachowiak mjs at
Sat Feb 21 08:44:55 PST 2009

On Feb 20, 2009, at 4:13 PM, David-Sarah Hopwood wrote:

> Ian Hickson's description of the two objects was:
> # The global object is a Window object. This object is per-Document.
> # The object returned by the "window" attribute on that global object
> # is actually a WindowProxy object, which forwards everything to the
> # "current" Window object.
> I don't understand how the WindowProxy "forwarding everything" to
> the Window object is is consistent with the two objects having
> "entirely different set[s] of properties".

Let's say you have a top-level browsing context currently displaying a  
document loaded from <>. This document has a  
subframe displaying <>. Inside the  
frame1 browsing context, a variable X containing the value "frame1" is  
defined. A function F is also defined which accesses variable X via  
scope, and via a retained reference to the global object. The top- 
level context gets a reference to function F. Now the nested browsing  
context is navigated to <>. This  
establishes a new Window, which the WindowProxy now points to. Let's  
say that inside this new global object, another variable X is defined  
which has the value "frame2". Now when F is called from the outer  
context, it will consistently see the value "frame1" when looking up  
variable X via scope, since the scope chain contains its Window. But  
when accessing X via a saved reference to the global object (for  
example via window.X) it will consistently see "frame2", since this is  
a WindowProxy reference that forwards to the now-current Window.  
Taking this further, the old Window and new Window (visible via the  
WindowProxy) could have totally different sets of properties.

Note that to observe the difference requires at least two frames, at  
least one of which is navigated, for a total of 3 different global  

Does that help?

> In any case, note that host objects can have arbitrary [[Put]] and
> [[Get]] internal methods, so it is possible for them to implement
> almost any conceivable behaviour that HTML5 could specify (given
> that ES code cannot obtain a reference to the object at the top of
> the scope chain, and so === cannot be used on it). That was my point
> above. In other words, ES3 has such a weak specification for host
> objects that literally any behaviour for property accesses on them is
> conformant.

If we take this approach, then the requirement that the top level  
scope entry and the global object are the same object would be  
meaningless.  I'm willing to buy the argument that it is in fact  
meaningless and imposes no real requirement, but perhaps others will  
disagree. Since there is no way to observe identity directly, one  
could always make the claim that two different objects are in fact one  
object with strange property access behavior.


More information about the Es-discuss mailing list