direct_proxies "problem"

Boris Zbarsky bzbarsky at
Wed Jan 9 07:02:43 PST 2013

On 1/9/13 5:24 AM, David Bruant wrote:
>> When later getting that node out of the DOM with .firstChild, what
>> should be handed back?  The proxy that was passed in, the JS object
>> that proxy was wrapping, something else (e.g. an exception is thrown)?
> The principle of least surprise would say the proxy that was passed in

That's actually not that great either.  If you're handing out proxies as 
membranes, and the caller of .firstChild should be getting a different 
membrane than the caller of appendChild had, you lose.

> Also if you wrap untrusted code in a membrane [1], you don't want this
> untrusted code to be handed the actual target, but the wrapped object
> (so the proxy).

If you want membranes you have to be able to pick the right membrane 
when handing out the object from any WebIDL method/getter, basically.

> Proxies expose the guts of algorithms applied on objects (exact sequence
> of internal methods with arguments).

Yes, true, for purposes of ES stuff.

> it would be equally true for browser objects

I'm not quite sure what this part means.

> Since these guts aren't specified in ECMAScript semantics

Again, not sure what that means.

The way the DOM works in practice right now, if one were to implement it 
in ES, is that each script-exposed object is just a normal ES object 
with some getters/setters/methods on its proto chain.  There is also a 
bunch of state that's not stored in the objects themselves, and a Map or 
WeakMap from the objects to their state, depending on the 
implementation; the GC issues are a bit complicated.  The 
getters/setters/methods work on this out-of-band state, for the most 
part (there are some exceptions; e.g. for the 
[PutForwards] case, though that may not match UA behavior well enough; 
we'll see).

So in this view, passing in a proxy should not work, because it can't be 
used to look up the out-of-band state.

Now if you happen to have access to engine-level APIs you can unwrap the 
proxy and use the target to index into the Map... but at that point I 
agree that you've left ES semantics land.

Now maybe you're arguing that the above model is wrong and there should 
be some other model here.  I welcome you describing what that model is. 
  But the above model, I believe, is fully describable in ES semantics 
(and in fact dom.js does exist).

> I agree with Andreas about the convenience for web developers [2] but I
> doubt it would be practical to have it in the short term both because of
> under-specification and implementation complexity.

Agreed, at this point.

> Let's wait for a combinaison of 1) authors using proxies, 2)
> implementors move forward on WebIDL compliance

Of course the more investors invest in a rewrite of their DOM stuff, the 
less likely they are to want to change it.

So if we think we should be changing things somehow in the future, and 
have a good idea of what those changes will look like, the better it is 
to lay the groundwork now.  Rewriting the binding layer for a browser is 
a pretty massive project, and there's a limit to how often UAs want to 
do it.  ;)


More information about the es-discuss mailing list