The global object in browsers
david.hopwood at industrial-designers.co.uk
Fri Feb 20 16:13:35 PST 2009
Maciej Stachowiak wrote:
> On Feb 19, 2009, at 1:20 AM, David-Sarah Hopwood wrote:
>> Ian Hickson wrote:
>>> On Tue, 17 Feb 2009, Mark S. Miller wrote:
>>>> I don't understand. If the object you're calling Window is inaccessible
>>>> from ES code, and if the object you're calling WindowProxy forwards
>>>> everything to your Window, why not just relabel Window ->
>>>> InternalWindow, WindowProxy -> Window?
>>> I don't really mind what the objects are called, the point is just that
>>> the object at the top of the scope chain is not the same as the object
>>> returned by "this" (or "window" on the global object).
>> MarkM's point is that *given that the object called Window is inaccessible*,
>> there's no way to observe that the object called Window is at the top of
>> the scope chain. An implementation could reflect all property changes
>> in that object to the object called WindowProxy, by some unspecified
>> mechanism (which is allowed since they are both host objects).
> It is possible to observe that the object at the top of the scope chain
> behaves differently than the global "this" value (it may have an
> entirely different set of properties), so this arguably violates the
> ECMAScript requirement that these be the same object, even though object
> identity cannot be observed directly.
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".
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
>> I'm confused by the motivation of the change in HTML5. It seems like
>> it is imposing most of the complexity that would be needed to fix
>> some of the security problems associated with the global object,
>> *without* actually fixing those problems.
> The HTML5 spec behavior does fix important security problems, relative
> to what older browsers used to do. Older behavior was to reuse the same
> global object across navigations, but simply clear the variables. This
> creates easily exploitable XSS vulnerabilities.
That's obviously broken, yes. When you say "older behaviour", what versions
of the main browsers are you talking about, approximately?
> Note though that HTML5 is following the implementations here rather
> than leading.
>> Also, it is a breach of standards development etiquette for the HTML
>> WG to make a a change (even in a draft) that it believes to be
>> incompatible with the ECMAScript spec, without consulting TC39. It
>> should not have been left to you in the role of an implementor to
>> point out the incompatibility.
> I think Ian discharged his obligation by notifying TC39 of the issue and
> starting this discussion. At this point, the important thing is to come
> up with a solution we can agree on.
I was confused partly by the fact that Ian said:
# For HTML5, this behaviour has been defined in more detail. [...]
# The HTML5 spec says: [...]
as opposed to something like: "It has been proposed for the next draft
of HTML5 to define this in more detail. [...] The proposal is: [...]"
More information about the Es-discuss