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 objects.
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.
Regards, Maciej _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
