Alex Russell wrote:
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.
Having a stable object identity for the window proxy, while navigating
the window through a series of page loads, requires this wart or an
equivalent one. Browsers came to this design the hard way. Without the
window proxy, with only one global object exposed (not just on the scope
chain), insecurity or else inefficiency ensues.
You could say the wart is having a stable object identity for an object
that proxies to more than one object over time (but not two at the same
time).
That is plausible, except that this use-case looks a lot like a membrane
use-case. Is there anything in the membrane literature where the
membrane wraps different objects over its lifetime?
/be
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
<bruan...@gmail.com <javascript:_e({}, 'cvml',
'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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss