The global object in browsers

Maciej Stachowiak mjs at apple.com
Sat Feb 21 08:27:18 PST 2009


On Feb 21, 2009, at 1:49 AM, David-Sarah Hopwood wrote:

> Ian Hickson wrote:
>> Right now ES3 assumes that there is a single global object, which  
>> is used
>> at the top of the scope chain and that is returned for "this" in the
>> global scope.
>>
>> It is possible to show that this is now what some browsers do:
>>
>>   var x = 1;
>>   function f() { return x; }
>>   var global = this;
>>   function g() { return global.x; }
>>
>>   // some other page's script takes references to f and g
>>   // browser navigates to a new page
>>
>>   var x = 2;
>>
>> Now, if the other page's script calls f() and g(), it will get  
>> different
>> results [...]
>
> Suppose that a browser allocates all JavaScript objects associated  
> with
> some unit of content [*], in an arena. When the browser navigates  
> away from
> that unit of content, the arena is deallocated; to preserve memory  
> safety,
> all references into it from objects that are still live will throw an
> exception.
>
> This behaviour has clear advantages for robustness against denial of  
> service
> from JavaScript code, both deliberate and inadvertent -- which is a  
> definite
> weak spot of current browsers, and a very common cause of complaint  
> from
> knowledgeable users. Is there any reason why it should be considered
> nonconformant?

This behavior has two problems:

1) Likely incompatible with the Web. Though Web sites apparently don't  
depend on ability to call older functions, they certainly do use  
objects originally allocated in other global objects and quite likely  
after the originating context has navigated. It's hard to quantify  
this since no browser has ever tried.

2) Makes implementation of back/forward caching (as present in Safari  
and Firefox) impractical; b/f cache fully restores a context that you  
navigated away from, including the live JavaScript object graph.

3) Has the same performance problems as the model of checking at  
function call boundaries, since at calls you'd have to check if your  
function has turned into a magical exception object. You are on record  
as not believing these, I will leave it to others to judge for  
themselves whether your "I'm quite sure" argument outweighs the  
experience of those who actually tried it and measured the results.

4) If the arena is truly deallocated rather than filled with magic  
exception objects, many additional checks must be inserted each time a  
value reference is used in almost any way, to check whether it is a  
reference into a deallocated arena. This would likely be a significant  
perf hit as well.

5) As far as I can tell, this violates the ECMA spec even more than  
the current HTML5 solution; the ECMA spec does not include the concept  
of reachable values turning into exception-throwing zombies.

6) It has poor properties for reliability and integrity of ECMAScript  
programs. Your code may have a perfectly good string or object stored  
away. But depending on where it originally came from, that reference  
can suddenly go bad.

> [*] Possibly a frame, or consecutive sequence of navigated frames with
>    the same origin. What is the minimum granularity for a "unit of  
> content"
>    for this would be compatible with the current web?

A unit of content of one page is almost certainly incompatible with  
the Web. A series of frames with the same origin would likely also be  
incompatible, since it is quite likely an initially empty frame may be  
used as a helper before navigating elsewhere. Not only that, but it  
would be bizarrely arbitrary if your object references from another  
frame go dead or not depending on whether the frame navigates to same- 
origin or non-same-origin content. Either way, problems 2-5 remain.

I don't think we need to try to redesign how browsers do navigation  
here. I don't see any justification provided for preferring your  
approach to what HTML5 specifies.

Regards,
Maciej



More information about the Es-discuss mailing list