Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant <bruan...@gmail.com
<mailto:bruan...@gmail.com>> wrote:
A good question by Anne van Kesteren [1] followed by good remarks
by Boris Zbarsky [2][3] made me try a little something [4][5].
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 wish to point out that apparently iframe.contentWindow
does break quite a lot of "eternal invariants" [7] which isn't
really good news, because it questions their eternity.
Indeed!
Among alternatives I'm thinking of:
* define a new type of proxies for which the target can be changed
(either only as a spec device of as an actual object that can be
instantiated in scripts)
* change the behavior of WindowProxy instances when it comes to
doing things that would commit them to eternal invariants to throw
instead of forwarding. This solution may still be possible,
because it's unlikely that Object.defineProperty is widely used in
web content today. But this change should happen pretty fast
before content relies on it.
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)
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.
David
[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
