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

[Ian Hickson]

On Wed, 24 Dec 2008, Maciej Stachowiak wrote:
> On Aug 5, 2008, at 2:12 AM, Ian Hickson wrote:
> > 
> > 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.

Agreed. (The above is what Opera did in my testing at the time. I haven't 
checked to see if this has changed in recent builds.)


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

Thanks for the feedback, this is very useful.

(The above model is IE's model.)


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

I've now specced this, since it has better performance characteristics 
than the "frozen scripts" model I had previously specced. (It also has 
more interoperable implementations and one of the vendors who does not do 
this has indicated that they would like to move to such a model.)

I haven't mentioned the 'this' behavior, so right now |this !=== window|, 
which breaks the invariant that there is no way to actually get hold of a 
reference to the Window object itself (as opposed to the outer WindowProxy 
object that forwards to the inner Window object). This requirement would 
be a violation of ECMAScript 3.1, so if we could get that changed in 
ES3.1, that would be great. Failing that, it should probably be in the 
WebIDL JavaScript binding section.

Note: This is pretty hairy stuff, so I would appreciate close review of 
the recent checkin to make sure it matches reality.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'