706041 - Proxy's don't work the way we'd like them to for the addon-sdk

Status: RESOLVED DUPLICATE of bug 703537

(Core :: JavaScript Engine, defect)

Description

[Eddy Bruel [:ejpbruel]]

In the addon-sdk we organize all our code into modules. Each module is defined within a separate sandbox. We use proxy's to expose objects between sandboxes. From our point of view, however, these proxy's are nothing but an implementation detail, and we would like to be able to treat them as if they were the actual object.

Now consider the following code:
var sandbox = Components.utils.Sandbox("http://www.example.com/");
Object.isFrozen(Components.utils.evalInSandbox('Object.freeze({})', sandbox));

The behavior we'd expect here is that Object.isFrozen returns true, because the object being proxied has been frozen inside the sandbox. The semantics of proxy's are such, however, that they can be unfrozen even when the object being proxied to isn't, so Object.isFrozen returns false. Moreover, freezing a proxy doesn't actually freeze the object being proxied to. Rather, it calls the fix trap on the proxy, and uses the property descriptor map returned by that trap to create a new object that will constitute the frozen proxy.

I hope this example illustrates why the current behavior is problematic for our purposes. Having said that, is there any chance that we could change this behavior to more closely approach the behavior we'd like? If not, could somebody please explain why this change would be problematic?

Thanks in advance for your feedback!

Comment 1

[David Bruant]

Is it a dup of bug 674195 ? For that matter it just got resolved :-)

Comment 2

[Eddy Bruel [:ejpbruel]]

Well, not really. bug 674195 had to do with Object.freeze not throwing even when a proxy couldn't be frozen (because it's fix trap returned undefined). This behavior occurs on Firefox 8 but not on the nightly, so I consider that resolved. The other issue had to do with Object.isFrozen returning false on a proxy to a frozen object. Imho that was a separate issue, so I opened a separate bug for it.

Comment 3

[David Bruant]

[:ejpbruel] from comment #2)
> (...)
> Imho that was a separate issue, so I opened a
> separate bug for it.
It is indeed.


(In reply to Eddy Bruel [:ejpbruel] from comment #0)
> The behavior we'd expect here is that Object.isFrozen returns true, because
> the object being proxied has been frozen inside the sandbox. The semantics
> of proxy's are such, however, that they can be unfrozen even when the object
> being proxied to isn't, so Object.isFrozen returns false. Moreover, freezing
> a proxy doesn't actually freeze the object being proxied to. Rather, it
> calls the fix trap on the proxy, and uses the property descriptor map
> returned by that trap to create a new object that will constitute the frozen
> proxy.
> 
> I hope this example illustrates why the current behavior is problematic for
> our purposes. Having said that, is there any chance that we could change
> this behavior to more closely approach the behavior we'd like? If not, could
> somebody please explain why this change would be problematic?(In reply to Eddy Bruel 
The old proxy proposal (http://wiki.ecmascript.org/doku.php?id=harmony:proxies) did not allow proxies to be frozen (specifically, it was not possible to make them non-extensible).
For that reason, when calling Object.freeze on the proxy, 2 things could happen:
1) the proxy looses its proxy power and becomes a frozen object
2) the call throws a TypeError and the proxy keeps its power and remains extensible (and non-frozen in our case)

This is what is implemented in Firefox.

Since, we've been discussing a lot on es-discuss and a new proposal came out of these discussions and different influences: http://wiki.ecmascript.org/doku.php?id=strawman:direct_proxies

These proxies will act differently than the previous ones. First, these proxy will be initialize not only with a handler, but also with a target object. The proxy and the target will share some internal properties (like [[Class]], [[Prototype]], [[Extensible]]) and most invariants that were guaranteed on target will also be guaranteed on the proxy.

Direct proxies aren't currently implemented. It seems to me that by design of direct proxies, your bug will go away by implementing (and using) direct proxies. I set the dependency accordingly.

Comment 4

[Eddy Bruel [:ejpbruel]]

I'm closing this bug, since it essentially has become a duplicate of bug 703537. I've moved all dependencies on this bug over to the other one.