- From: David Bruant <bruant.d@gmail.com>
- Date: Tue, 25 Dec 2012 01:36:06 +0100
- 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 23:53, Boris Zbarsky a écrit : > On 12/24/12 2:36 PM, David Bruant wrote: >> Scripts inside the new document think they are in a fresh browsing >> context if I understand correctly. > > No. There is only one browsing context. Browsing contexts don't even > change across navigations. > > Scripts created after the open() will see a new ES global. Scripts > created before the open() keep seeing the old one as their global. I thought the global changed. document.open Step 14 suggests that the Window object changes... unless it's referring to the Window "constructor" and not the window instance as I understand it? >> 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. > > With s/context/global/ yes. Or of course script from outside the > navigation context altogether. > >> 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) > > Navigation doesn't change the browsing context. It creates a new > Window (which is the ES global) and new Document. Yes. It mixed up all terms in my head. Sorry about that. I was talking about navigation all along; assuming a new form of navigation preserving the document identity could exist. But I was wrong apparently. I thought the global changed, but it doesn't seem to. >> 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) > > No, the script that called open() needs to keep running against the > old global. Not doing that breaks things, last I checked. > > Consider this testcase: > > <script> > var x = 1; > window.onload = function() { > document.open(); > document.write(x); > document.close(); > } > </script> Hmm... Playing with this example a bit more I've found that Gecko and Chrome deviates in their behavior. Gecko only preserves the lexical environment for the functions in the pre-document.open scripts and deletes the binding to the global object while Chrome preserves the binding to the global object. See: <script type="text/javascript"> var x = 31; y = 37 window.onload = function(){ var l = localStorage; document.open("text/html"); console.log('opener context x', window.x, window.y); console.log(x, y); console.log("storage", l === window.localStorage); document.write('<script>console.log("new document context x", window.x, window.y); console.log(x, y)</scr'+'ipt>') document.close(); }; </script> Said differently, both preserve the WindowProxy, but Gecko changes the underlying Window while Chrome doesn't apparently. Chrome doesn't seem to change the localStorage object. I fail to observe the step 14 in Chrome including the "change all the prototypes" part, so I guess it's not web-crucial. Maybe an opportunity to reconsider the "every prototype of every object has to change on document.open" by changing the document.open spec? It could be re-spec'ed as the same thing without step 14. I think it would save a lot of trouble. What do you think? David
Received on Tuesday, 25 December 2012 00:36:35 UTC