[whatwg] Code defined for one document called after that document is no longer the one being displayed
mjs at apple.com
Wed Dec 24 12:05:38 PST 2008
On Dec 22, 2008, at 8:41 PM, Ian Hickson wrote:
> 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
>> 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
>> 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
>> object, which changes with each navigation, leading the method to
>> the original global object in its scope chain, but the new one if
>> uses the 'window' object. (In this environment, 'this' at the top
>> 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,
>> results are slightly different when navigating top-level windows
>> instead of frames.)
>> These results were derived from:
>> 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
>> 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
>> 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.
I just replied to your earlier email on the topic, which I missed
before. I would be against this change, due to likely performance cost.
More information about the whatwg