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(scriptfunction 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
