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

[Ian Hickson]

On Thu, 15 May 2008, Jonas Sicking wrote:
> 
> Generally saying that "scripts won't run once you've navigated away from 
> a page" is wrong. For example I think that if you mutate the DOM of 
> document that has been navigated away from mutation-event handlers will 
> still fire. And UserDataHandlers will likely fire as described by spec.

The HTML5 spec now defines that once you navigate away, the scripts are 
frozen, meaning that scripts defined by the page itself won't fire. 
Scripts from other pages still will, though.


> Not to mention that there can still be script executing for a page when the
> page is navigated away from. For example:
> 
> var value = "hello nurse";
> onload = function() {
>   alert("i'm still the active page");
>   document.write("new page");
>   alert("I'm script running in the context of a page that has been " +
>         "navigated away from. See, |value| is still there:" + value);
> }

Right, per spec, that should work fine. (The complications are if this 
code then calls some script in another document -- then if that code calls 
back into this code, an exception will be raised. At least, per spec. I 
tried doing what IE does, but IE's behavior is wacky, the two asserts in 
this example both are true:

  document.open();
  document.write("<script>function b(w) { assert(w === window); w.w = window; }<\/script>");
  window.b(window);
  assert(window !== window.w);

...which makes no sense to me.


> [ inner windows and outer windows ]
> [...] Some of this stuff is there for web compat. Such as the fact that 
> this results in the code executing after the document.write above still 
> is able to access global variables that were defined before the call. 
> I.e. the |value| in the second alert still works.

Per spec, document.open() doesn't replace the Window object... In fact, 
right now even the global variables aren't ever nuked by document.open() 
per spec. It's not really clear to me when that should happen... The 
behavior of the browsers today is not interoperable at anything but a 
superficial level, and the low-level behaviors are all kinda weird (e.g. 
IE's behavior as described above). Of note, Safari doesn't seem to blow 
away the global variables:

   http://www.hixie.ch/tests/adhoc/dom/level0/document/open/008.html
   http://www.hixie.ch/tests/adhoc/dom/level0/document/open/009.html

Mozilla seems to handle 'var x' differently from 'window.x', though per 
the JS spec I can't find any justification for this (they should be the 
same except for the former having DontDelete set).


On Tue, 5 Aug 2008, 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.
> 
>  - 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.
> 
>  - 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.)
> 
>  - 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.

I've now done this.


On Tue, 5 Aug 2008, Aaron Boodman wrote:
> 
> By 'method' do you mean any function object, defined anywhere in that 
> window? For example, does document.getElementById count? Does the foo in 
> var myglobal = {foo:function(){...}}; ? What about getters?

I mean any code entry-point defined by a script. So lambdas yes, getters 
and setters yes, API methods no.

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