[whatwg] Methods defined for one document called after that document is no longer the one being displayed
ian at hixie.ch
Sat Jan 31 02:27:59 PST 2009
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
> 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
Note: This is pretty hairy stuff, so I would appreciate close review of
the recent checkin to make sure it matches reality.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg