Proxying Native Objects: Use case

David Bruant bruant.d at
Thu Jan 31 08:46:03 PST 2013

Le 31/01/2013 17:26, François REMY a écrit :
>> I think such a getter notation exists in WebIDL to formalize scars from
>> the past (like HTMLCollection) rather than to be used in new APIs
> Yes and no. For exemple, something alike is envisionned to support custom properties in CSS. Something like:
> = true;
>      // set the my-custom-property custom CSS property
How is this not future-hostile?
Do you have a link to where people are discussing this?

>> However, off top of my head, I don't see a main restriction to call
>> .dispatch with a proxied event as argument. I'm not enough expert of
>> this topic; people who are in how the APIs are used and implemented will
>> better tell whether it's appropriate to accept a proxy.
>> I'll post to public-script-coord to talk about that.
> Thanks, that's a good idea. But you didn't comment on the possibility to simply turn any object into a proxy using
Indeed, sorry.
Turning any object into a proxy is a no-go, because it means that things 
are aren't observed suddenly have to be observed and that anyone can 
insert arbitrary code in the middle of any operation on any object. It's 
pretty bad both for security and probably for performance too.

I think having dispatchEvent accepting proxies is the easiest thing to 
do in your case.

If creating proxies for exotic objects become a real thing, maybe each 
exotic type can define its own reduced version of proxies like:

     document.createProxiedElement('string', proxiedElementHandler)

The power proxiedElementHandler could be arbitrarily reduced by the spec 
of createProxiedElement. It could allow creating reduced "proxies" that 
can be inserted in the DOM without providing full abusive power than 
have the bad consequences for selector matching. It's possible in 
theory. In practice, I don't believe it'll happen :-s


More information about the es-discuss mailing list