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. `._.-(,_..'--
(,_..'`-.;.'
