[Bug 5850] JS global object

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5850





--- Comment #11 from Adam Barth <w3c@adambarth.com>  2008-07-16 18:48:29 ---
> Does JS define that, e.g., "document" in
> a closure refers to the document object from the global scope at the time the
> function is compiled / closure is evaluated?

JavaScript has no notion of "at the time."  Each closure has a static scope
chain that terminates in a global object.  The objects in this scope chain
never change and names are resolved relative to this scope change.  The tricky
bit is if the browser wants to reuse the global object for the contents of the
frame after navigation.  If it does this, the scope chain for these closures is
screwed up.

> Is it clear when/whether you
> obtain the value of window.String to handle a function doing "x".toString() ?

Yes.  They specify when and how to resolve names against the scope chain.

> So, how much do I need to define here?

One approach is to follow the design that Sam implemented in WebKit:

1) Each browsing context has a window object which also serves as the global
object for JavaScript.  This is the normal way of thinking about JavaScript
contexts.

2) Whenever any script gets a pointer to a window object, they instead get a
pointer to a "window shell."  The window shell masquerades (using magic) as the
window object currently occupying a fixed frame.  (The one exception to this
rule is that the scope chain itself uses the real window/global object).

3) When a frame navigates, the new document gets a new window/global object. 
The window shell is re-used, but now masquerades as the new window/global
object (no longer as the old one).

The whole reason to this mess is so the following code works:

var win = frames[0];  // win now points to this frame's window shell
win.location.href = "http://newlocation.com/";
// Frame zero now contains a new window/global object, a new document, etc.
// ... time pass ...
alert(win.document.body.innerHTML);  // This is the document from the new frame
// because the window shell switched over to pretending to be the new
window/global object.

> If so, then I don't know that we have to say anything really, except to make
> sure we define that all the built-in objects get renewed as well when the list
> of added properties is poked at.

I don't think this is the right approach.  You don't want to be mutating the
window/global object.  In order to get things right you need a new
window/global object for each browsing context.  The window shell lets scripts
hold pointers to the "outside" of a frame (so they get the current contents
whenever they ask for it).

I think this approach covers all the observed behavior, except for the behavior
of "location."  That's because "location" is magical and actually refers to the
frame (not the window or document of which it is a property.)


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 16 July 2008 18:49:03 UTC