Le 12/12/2012 20:44, Alex Russell a écrit :
Window interceptors (as we call them in the browser world) are simply
nuts. We simply shouldn't be terribly interested in re-creating this wart.
I'm not sure I understand your point. Do you mean that emulating them in
pure ECMAScript should be an exception to the "emulate DOM" proxy use case?
David
On Wednesday, December 12, 2012, David Bruant wrote:
Le 12/12/2012 20:29, Kevin Reid a écrit :
On Wed, Dec 12, 2012 at 11:19 AM, David Bruant
<[email protected] <javascript:_e({}, 'cvml',
'[email protected]');>> 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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
