Le 12/12/2012 20:49, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:39 AM, David Bruant <[email protected]
<mailto:[email protected]>> wrote:
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant
<[email protected] <mailto:[email protected]>> wrote:
The WindowProxy object returned as the 'contentWindow'
property of iframes never changes; whatever you do when
changing the @src, always the same object is returned.
However, based on whether the @src is changed, the
WindowProxy proxies to a different Window instance.
I bumped into this myself just recently while attempting to
implement virtualized navigable iframes in Caja — I need to
emulate exactly this behavior.
Do you have a pointer to the code for that, just out of curiosity?
I haven't made it public yet, but it's just the obvious implementation
of an (old-style, as implemented in Firefox/Chrome) proxy with a
switchable “target”.
Interesting. As I said, target-switching won't be possible in direct
proxies.
The best option I see at the moment would be that a WindowProxy
refuses to commit, but a Window does. That is, code operating on
'window' within the iframe can still Object.defineProperty, but
from the outside every property of Window appears to be
configurable. This is what I have implemented in my current draft.
Let's say that the window has a non-configurable, non-writable
property, what happens to Object.getOwnPropertyDescriptor on the
WindowProxy? Does it throw? (I would be fine with this behavior,
but I'm just wondering)
It returns a descriptor which is identical except that it claims to be
configurable.
Direct proxies invariant checks would make such a "lie" about
configurability impossible. The engine would throw if you try to pretend
a non-configurable property is configurable. See
http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies#invariant_enforcement
Attempting to actually reconfigure it using defineProperty would throw.
On the other hand, it seems that in browsers either 'window' is
also the same (!) proxy, or === invariants are broken, or the
WindowProxy is acting as a membrane:
> f.contentWindow === f.contentWindow.window
true
I think it's a membrane. The HTML5 spec [1] makes pretty clear
that the window property isn't a Window, but a WindowProxy.
HTML5 experts will know better, but I think no one ever
manipulates directly a Window instance, there is always a
WindowProxy mediating the access. Of course, the implementation is
free to optimize this mediation.
The disturbing thing about "window instanceof WindowProxy", if you
will, (given that it accurately reports its mutability) is that since
window is the global environment, it means that the global environment
cannot have immutable things. Of course, SES actually establishes a
new environment (using 'with') for secured eval.
One idea would be that different handlers are used based on the context.
Different handlers would encode whether to create non-configurable
properties.
If the WindowProxy instance has been obtained through accessing the
global of your environement, you can add non-configurable properties.
If the WindowProxy has been obtained with iframe.contentWindow then you
can't create non-configurable properties.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
