- From: David Bruant <bruant.d@gmail.com>
- Date: Sat, 15 Dec 2012 01:14:30 +0100
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: public-script-coord@w3.org
Le 13/12/2012 19:37, Boris Zbarsky a écrit : > On 12/13/12 12:24 PM, David Bruant wrote: >> When a script in a page has access to its global object, this object is >> a WindowProxy. In this case, under which conditions can the underlying >> window object change? (and that change be observable by the same script, >> of course) > > When the window is navigated or document.open() is called. > > Here's a simple testcase that shows the underlying window changing: > > test2.html: > <script> > var self = window; > var foo = 1; > var f = function() { alert(foo); alert(self.foo); } > </script> > > test.html: > > <iframe src="test2.html"></iframe> > <script> > window.onload = function() { > window.f = frames[0].f; > f(); > var i = document.querySelector("iframe"); > i.setAttribute("onload", "f()"); > frames[0].location = "about:blank"; > } > </script> > > This alerts 1, 1, 1, undefined in at least Safari, Opera, Firefox. Wow! Thank you very much for having shown this. I would have never thought of doing this. > >>> That's not ok, unfortunately, because for security reasons we must be >>> able to define things that look like non-configurable properties on a >>> window. >> By "we", you mean "implementors" and that's fine. Only web authors won't >> be able to define their own non-configurable properties. > > I don't see how that's OK. "we" as in implementors are using the same > APIs to define our properties... Specifically not. Implementors can define Window objects while authors can't for instance. It means that implementors have access to primitives that web authors don't. That's just one example of how "implementor APIs" are different than authors APIs. In our case, implementors can instantiate the objects in ways that authors can't. David
Received on Saturday, 15 December 2012 00:14:59 UTC