direct_proxies "problem"

Andrea Giammarchi andrea.giammarchi at gmail.com
Sat Jan 12 14:28:15 PST 2013


did you read anything I have been written in this thread or you have a
short memory ?

I am strongly recommending to throw an error the moment an object cannot be
proxied . I don't want to detect node and proxied node, I don't want DOM
node to be allowed to be the first argument of the Proxy.

I don't want create 50 line sof code that demonstrates isDOMProxy is
possible because you all know it is right now so, I am just waiting for the
verdict about this **issue** because if this is meant ant won't change, the
fact we can do new Proxy(HTMLElement), I want write about this **problem**
and inform developers and library authors we gonna have bad time if a proxy
leaks anywhere in a program.

thanks for any outcome

br


On Sat, Jan 12, 2013 at 1:40 PM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 12/01/2013 21:58, Andrea Giammarchi a écrit :
>
> that is a (quick/imperfect/asexample) way to detect a proxy while I
> understand these should not be detectable.
>
> {} and [] also return true to your test, but they're not proxies. You
> cannot use an imperfect test to prove a point.
> As I (and others now) said, the DOM, in order to be self-consistent (and
> have performance in operations like selector matching) can only use objects
> it created through HTML parsing or methods like document.createElement. It
> will refuse any other object, proxy or not. With tree manipulation methods
> (like appendChild), the only relevant test you can be making is "is this
> object a DOM created genuine node?". This rules out *any* object. This
> includes proxies to node
>
>
>  Consider that as conditional check after node instanceof Element in
> order to know if that node is usable or not as DOM element.
>
> Object.create(Element.prototype)?
>
>
>  There, a way to simulate an isProxy method and it does not matter if
> that's silly ... is possible
>
> The possibility to use proxies in the DOM tree was ruled out because of
> the selector matching use case. If you have a solution to put proxies in
> the DOM tree without ruining selector matching perf, you will be listened.
>
> David
>
>
>
>
> On Sat, Jan 12, 2013 at 11:24 AM, Brendan Eich <brendan at mozilla.com>wrote:
>
>> This is silly.
>>
>> I can use the closure pattern to vend objects that do not satisfy the
>> internal constraints the DOM imposes on some of its objects. No proxies in
>> sight.
>>
>> So why is the method you wrote named "isDOMProxy" and whatever in the
>> world does it have to do with Proxy?
>>
>> /be
>>
>> Andrea Giammarchi wrote:
>>
>>>  and in both cases you would have ...
>>>
>>> Proxy.isDOMProxy = function (node) {
>>>   try {
>>>     document.documentElement.appendChild(node);
>>>     document.documentElement.removeChild(node);
>>>     return false;
>>>   } catch(gotcha) {
>>>     return true;
>>>   }
>>> };
>>>
>>> that's why I have talked about inconsistencies all over at the very
>>> beginning of this thread :)
>>>
>>> br
>>>
>>>
>>>
>>>
>>>
>>>
>>>   On Sat, Jan 12, 2013 at 10:26 AM, Nathan Wall <nathan.wall at live.com<mailto:
>>> nathan.wall at live.com>> wrote:
>>>
>>>     Nathan wrote:
>>>     >
>>>     > Hey Tom, I think you missed my point. The point was that in
>>>     David and Boris' discussion they agreed that the DOM should throw
>>>     if it is given a Proxy in `appendChild`. That sounded to me like
>>>     it presumed that the DOM had a magical ability to distinguish
>>>     between DOM objects and their proxies. That seemed to contradict
>>>     the point David made that Proxies should not be distinguishable
>>>     from their targets (e.g. the no `Proxy.isProxy` decision). If real
>>>     DOM had a way to determine if something was a proxy (with a target
>>>     of a *real* DOM node) and throw but there was no way for an
>>>     emulated DOM (in a non-DOM environment) to determine if an object
>>>     was a proxy with a target to an emulated DOM node or just a plain
>>>     emulated DOM node, then the DOM has magical abilities that the
>>>     emulated DOM can't have. That was my concern.
>>>     >
>>>     > David's reply works, though, I think. He stated that since you
>>>     have to create DOM nodes using a method of the DOM itself
>>>     (`document.createElement`, `document.createTextNode`), then
>>>     emulated DOM could track all objects created and compare them
>>>     against objects passed into `appendChild`, and since a proxy would
>>>     have a different object identity from its target, the emulated DOM
>>>     would have a way to distinguish proxies from their targets.
>>>     >
>>>     > Nathan
>>>
>>>
>>>     In short, if real DOM can throw when given a proxy of a real DOM
>>>     node, fake DOM should also be able to throw when given a proxy of
>>>     a fake DOM node.
>>>     _______________________________________________
>>>     es-discuss mailing list
>>>      es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>>     https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>>
>
>
> _______________________________________________
> es-discuss mailing listes-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130112/a2c7b5be/attachment-0001.html>


More information about the es-discuss mailing list