A DOM use case that can't be emulated with direct proxies
bruant.d at gmail.com
Wed Dec 12 12:03:18 PST 2012
Le 12/12/2012 20:49, Kevin Reid a écrit :
> On Wed, Dec 12, 2012 at 11:39 AM, David Bruant <bruant.d at gmail.com
> <mailto:bruant.d at gmail.com>> 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 <mailto:bruant.d at gmail.com>> wrote:
>> 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 haven't made it public yet, but it's just the obvious implementation
> of an (old-style, as implemented in Firefox/Chrome) proxy with a
> switchable “target”.
Interesting. As I said, target-switching won't be possible in direct
>> 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)
> It returns a descriptor which is identical except that it claims to be
Direct proxies invariant checks would make such a "lie" about
configurability impossible. The engine would throw if you try to pretend
a non-configurable property is configurable. See
> Attempting to actually reconfigure it using defineProperty would throw.
>> 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.
> The disturbing thing about "window instanceof WindowProxy", if you
> will, (given that it accurately reports its mutability) is that since
> window is the global environment, it means that the global environment
> cannot have immutable things. Of course, SES actually establishes a
> new environment (using 'with') for secured eval.
One idea would be that different handlers are used based on the context.
Different handlers would encode whether to create non-configurable
If the WindowProxy instance has been obtained through accessing the
global of your environement, you can add non-configurable properties.
If the WindowProxy has been obtained with iframe.contentWindow then you
can't create non-configurable properties.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss