A DOM use case that can't be emulated with direct proxies
bruant.d at gmail.com
Wed Dec 12 11:19:41 PST 2012
A good question by Anne van Kesteren  followed by good remarks by
Boris Zbarsky  made me try a little something .
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 thing this is something that can't be implemented with direct proxies.
Is this conclusion shared?
Assuming I'm not wrong in my analysis, now is time to wonder if the
direct proxy design should be change to make this part writable in
goal, something needs to be changed indeed.
If it's possible to relax this use case a little bit, following the
direct proxies model described some time ago , it would be possible
to do the following:
* Model WindowProxy objects as ES proxies
* Allow the UA to change the target of this proxy at will (which is very
close to what's actually done and spec'ed anyway)
I wish to point out that apparently iframe.contentWindow does break
quite a lot of "eternal invariants"  which isn't really good news,
because it questions their eternity.
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.
More information about the es-discuss