Proxying built-ins (Was: [[Invoke]] and implicit method calls)

Mark S. Miller erights at
Wed Sep 25 12:47:35 PDT 2013

On Wed, Sep 25, 2013 at 7:13 AM, Boris Zbarsky <bzbarsky at> wrote:

> On 9/25/13 5:18 AM, Tom Van Cutsem wrote:
>> The auto-unwrapping doesn't break membranes, because membranes never
>> expose direct references to built-in functions (they only expose wrapper
>> functions, which can still do whatever interposition they want before
>> calling the actual built-in).
> I'd like to clarify this part a bit...  What happens when I take a
> built-in from one realm and .call() it on a proxy which is implementing a
> cross-realm membrane?
> In this situation, I will claim the right behavior is to throw if the
> cross-realm access is disallowed and to unwrap the proxy otherwise. This is
> the behavior SpiderMonkey implements or its cross-realm proxies, in fact.
>  But at the moment this is implemented via having a special brand on
> cross-realm proxies that indicates they're cross-realm proxies and giving
> cross-realm proxies's handler an extra "is it safe to unwrap your proxies?"
> hook.
> All of which is to say, maybe such a hook is needed in general?

Hi Boris, I don't understand what you mean by "in general". I think the
SpiderMonkey use of cross-realm membranes is a great use case for
membranes, and I don't understand why they need any special logic at all --
beyond the logic expressed by their handlers, which must include
revocation. These membrane handlers should be the only logic which express
the semantics of cross realm invocation, revocation, etc. Other membranes
across other boundaries express other things. I think this use case is a
good acid test of transparency, efficiency, and expressiveness across
membrane boundaries. Is there anything about the browser's inter-realm
interaction that cannot be expressed by browser-self-hosted vanilla

> -Boris
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list