A DOM use case that can't be emulated with direct proxies
bruant.d at gmail.com
Wed Dec 12 11:51:10 PST 2012
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?
> 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
>> 'bruant.d at gmail.com');>> wrote:
>> 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 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"  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.
>> 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
> I think it's a membrane. The HTML5 spec  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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss