[whatwg] Methods defined for one document called after that document is no longer the one being displayed

[Maciej Stachowiak]

On Aug 5, 2008, at 2:12 AM, Ian Hickson wrote:

>
> I would like some input from browser vendors.
>
> Right now, if you navigate an iframe to a document, and take a
> reference to a method defined in that document, and then navigate that
> iframe to another document, and then call the method, browsers  
> differ in
> what they do.
>
> There are several behaviours:
>
> - In one browser, the Window object changes with each navigation,
>   and the global object is that object, and the method runs fine.

I believe this design is not compatible with the Web, as there are  
sites that take the Window object of another frame or window and  
expect it to remain valid across navigations.

> - In one browser, the method call fails, saying that methods can't be
>   called while the document that defined them isn't the active  
> document
>   of the browsing context whose global object is the method's.

I think adding checks for this condition at every JS-to-JS call  
boundary would be an unacceptable performance cost. This is a highly  
optimized code path in modern JITting implementations of JavaScript  
and I would be against slowing it down with extra checks just because  
the resulting behavior seems simple.

(Should the check also occur at native-to-JS or JS-to-native  
boundaries? That would lead to outright broken behavior as event  
listeners in inactive documents wouldn't fire even when events occur  
that should trigger them, and getElementById on inactive documents  
wouldn't work. It wasn't clear to me if you had either of those cases  
in mind.)

> - In one browser, the Window object acts as a kind of view on the  
> global
>   object, which changes with each navigation, leading the method to  
> see
>   the original global object in its scope chain, but the new one if it
>   uses the 'window' object. (In this environment, 'this' at the top  
> scope
>   returns the 'window' object, not the global object.)

This roughly describes the implementation internals of both Gecko- 
based and WebKit-based browsers with the latest version of the  
respective engines -- the so-called "split window" design. Modulo some  
of the details about the value of "this" (which could reasonably go  
either way), this would be the natural way for browsers adopting this  
design to behave, if they do not explicitly add additional checks.

>  - In one browser, the global object and the Window are the same,  
> but the
>   global object is totally wiped out with each navigation,  
> preventing the
>   method from accessing its global object's data. (In this browser,  
> the
>   results are slightly different when navigating top-level windows
>   instead of frames.)



>
>
> These results were derived from:
>   http://damowmow.com/playground/demos/global-object/004.html
>
> I propose to adopt the second behaviour above. It seems by far the
> simplest behaviour to define and implement. Are there any objections  
> to
> this? Given the lack of interoperability here, it seems like we aren't
> really constrained to pick something due to compatibility.
>
> The change would be that if a method is invoked when the script  
> execution
> context that the method was running in has a Document object that is  
> not
> the active Document object of its browsing context, then that method
> immediately throws an exception. Access to variables obtained from  
> such
> script execution contexts would be unaffected.
>
> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'