Gecko:SplitWindow
We need to split the window object into two objects. See bug 296639 for rationale and such, as well as for the JSExtendedClass note there.
Some fuzzy thoughts on how to do this:
We want to ensure that any time someone actually _asks_ for the window object they get the outer object (since we can't really tell whether they're asking from "inside" the window or not). That is, the mFlatJSObject on the XPCWrappedNative for the window should be the outer object. The inner object should only be relevant in the following cases, I think:
- Global object (or at least outermost scope object) for scripts that execute in the page.
- End of scope chain for all event handlers and such in the page.
- window property on the outermost scope
JS arch questions: Is it possible for script compilation to define properties (eg function compilation needs to) on some object other than the global object for the JSContext? If no, then it seems we have two choices: either have one JSContext per inner window object (and a separate JSContext for the outer? Or what?) or rely on forwarding of sets from the outer object to the inner (in which case we need to switch the inner before compiling any scripts in a newly loading document, which may be ok; we already call SetNewDocument before that point currently).
I'm sort of assuming we want to change as little of the current object graph as possible (say we don't want to add another C++ class sitting between nsDocument and nsGlobalWindow).
GC thoughts: the outer and inner should mark each other as long as the inner is the current inner for the outer. Once that stops being the case, the inner can't be reached from the outer (so no reason to mark in that direction). I think we need to keep marking from inner to outer because making a native method call on the inner needs to end up going to the XPCWrappedNative, hence we need to keep it alive. I guess this is one problem with the XPCWrappedNative's mFlatJSObject being the outer object...
--Bzbarsky 21:16, 4 Jun 2005 (PDT)
Answers to JS arch questions:
1. Yes. The global object of a context is just a convenient association, used by the DOM code in Mozilla classic and modern implementations. What ECMA-262 calls the "variable object" is the last object on the scope chain, which is found from the current frame (activation object). That outermost scope object has no necessary relation to JS_GetGlobalObject(cx).
2. On marking outer and inner: we have to avoid bad paths that lead from an old (back in history) inner to the outer to a different (current) inner. It would be good to find ways to check this with assertions or other kinds of proof aids. Same goes for any bad paths that use JS_GetGlobalObject(cx).
/be