direct_proxies "problem"

Tab Atkins Jr. jackalmage at gmail.com
Tue Jan 8 13:23:49 PST 2013


On Tue, Jan 8, 2013 at 12:40 PM, Andrea Giammarchi
<andrea.giammarchi at gmail.com> wrote:
> So, I am playing with FF 18 and I have this behavior:
>
> var a = new Proxy([], {});
> console.log(a instanceof Array); // true
> console.log(Array.isArray(a));   // true
> console.log({}.toString.call(a));// [object Array]
>
> Function.apply(null, a);         // anonymous()
>
> Cool uh? there's no way to tell that a is not actually an array but rather a
> proxy: awesome!!!
>
> Now I go in that dark place called DOM:
>
> var n = new Proxy(document.createElement("p"), {});
> console.log(n instanceof HTMLElement);// true
> console.log({}.toString.call(n));     // true
> document.body.appendChild(n);
> // Error: Could not convert JavaScript argument arg 0
> [nsIDOMHTMLBodyElement.appendChild]
>
> Is this meant? 'cause it looks lik ewe have half power here and once again
> inconsistencies ... thanks for explaining me this.

As Francois points out, this is a known problem.  DOM objects don't
live solely in JS - they tend to have C++ backing classes that do a
lot of the heavy lifting.  Your average JS object, without such C++
support, simply won't work with the JS methods that, when they call
back into C++, expect to see the DOM C++ classes.

This is a problem elsewhere, too - Web Components really wants to make
it easy to subclass DOM objects, but we've had to twist ourselves into
knots to do it in a way that alerts the C++ side "early enough" that
it can create the new objects with appropriate backing C++ classes.

It can potentially be solved by efforts like moving the DOM into JS,
which browsers are pursuing to various degrees, but it's a hard
problem on the impl side.  Meanwhile, there is unforgeable magic
behind DOM objects, and nothing we can really do about it.

~TJ


More information about the es-discuss mailing list