The global object in browsers

Maciej Stachowiak mjs at apple.com
Thu Feb 19 11:37:04 PST 2009


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.

However, this can only be observed in the presence of multiple global  
objects and global object replacement via navigation, which is a  
situation not adequately covered by the ECMAScript spec at present.  
One could make the case that because the difference is not observable  
under a single global object, then the behavior is conforming.

>
> 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 vulnerabiliites. 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.

Regards,
Maciej



More information about the Es-discuss mailing list