W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2012

Re: [dom] Need to describe the interaction of adoptNode with prototype chains

From: David Bruant <bruant.d@gmail.com>
Date: Mon, 24 Dec 2012 23:36:37 +0100
Message-ID: <50D8D8F5.4050404@gmail.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: Anne van Kesteren <annevk@annevk.nl>, www-dom@w3.org, Cameron McCormack <cam@mcc.id.au>, Bobby Holley <bholley@mozilla.com>
Le 24/12/2012 21:17, Boris Zbarsky a écrit :
> On 12/24/12 10:39 AM, David Bruant wrote:
>> What does observably survive to document.open?
> The "document" object itself.
>> Could it be possible to pretend that document.open is like a navigation
> You could, but the object identity of the "document" object doesn't 
> change, unlike with a navigation...
Only script that existed before the document.open can observe this.
Scripts inside the new document think they are in a fresh browsing 
context if I understand correctly. From the new document point of view, 
it "feels" like a navigation just occurred. Only the script from the 
previous context can tell the difference.

The current spec and implementations think of document.open as:
* before the call, you're in a browsing context
* after, you're in the same browsing context, but everything except the 
document identity has changed

What about thinking of it the following way:
* before the call, you're in a browsing context
* after the call, you're in a new browsing context (navigation) and some 
script from the previous browsing context has survived and runs *in the 
new context* (the context change happens during the document.open call)
** The only thing that the new context keeps from the previous context 
is the document object *identity*. All the rest is new
** The re-contextualized script may have kept references to the previous 
context with closures.

To further explain my point:
function f(){
     var a = "<h1>ya</h1>";
     var doc1 = document;

         assert(doc1 === document); // identity preserved
         document.innerHTML = a; // acting on the "new" document
     }, 1000);


Before the call to document.open, the script runs in some browsing 
context, declares an 'a' variable, etc. After the call, you're in a new 
browsing context. Everything has changed (except the document identity) 
around the script, but it keeps executing.
The new browsing context comes to existence with an opened document and 
a script being executed. In our case, this script starts with 
"document.write..." (I'm describing the runtime behavior here, not the 
script textual representation... which actually doesn't exist anymore in 
the new context)
I feel this script context change is "light-weight" compared to the 
current solution.

I don't know if such a script context change can be implemented in 
JavaScript. Caja can contextualize code using both 'eval' and 'with' 
[1]. I don't think it can change the context dynamically.
ECMAScript 6 will have dynamic module loading [2]. It might be possible 
to change the global dynamically (no with or eval involved this time ;-) 
) [3].


(look for compileExpr)
[2] http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders#loader_api
[3] https://mail.mozilla.org/pipermail/es-discuss/2012-December/027410.html
Received on Monday, 24 December 2012 22:37:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:01 UTC