The global object in browsers
mjs at apple.com
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 <http://example.com/>. This document has a
subframe displaying <http://example.com/frame1.html>. 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 <http://example.com/frame2.html>. 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
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