Search code examples
javascriptscopeclosuresbindanonymous-function

How to pass a Proxy object as context to a closure in javascript

Note: I now believe this question was based on assumptions about the javascript specification which are actually implementation specific.

I am attempting to build a runtime debugging hook system for a complex dynamic javascript application. A series of choices have let me to choose to use javascript Proxy and Reflect metaprogramming constructs to interpose function calls in the application I am debugging, wrapping all incoming functions arguments in Proxy/Reflect constructs.

The approach involves replacing high level application functions with Proxies and using traps and handlers to provide debugging functionality, ultimately passing arguments through to the application in a transparent way. All property get/set and function executions act as normal. However, by wrapping all objects and functions in Proxies allows tracing of the runtime.

I am installing this hook system into Chrome.

(Note: Please do NOT provide an answer suggesting a different methodology for debugging hooks - options have been evaluated extensively.)

The issue is that some javascript methods in the application invoke closures and pass "this" parameters. When "this" parameters are wrapped in a Proxy, the runtime fails to execute a closure, instead throwing an "Illegal Invocation" Exception.

I have tried reengineering the debugging hook system to not wrap arguments for some methods, or selectively wrap arguments. I have not been able to find a way to tell if an argument is intended to be used as a context, making code that tries this approach hardcoded to many possible methods and calling conventions. Ultimately this is too fragile to calling convention edge cases and requires too many case statements.

I have also removed the logic for wrapping arguments before passing them through. This removes the benefit from the debug hooking system, and so I have always reverted the logic to wrap all incoming arguments.

alert.apply(this, [1]);

p = new Proxy(this, {});

try {
    alert.apply(p, [1]);
} catch (e) {
    console.log(e);
}

This throws an "Illegal Invocation" Exception.

typeof this === 'object'
true

But it seems that contexts are objects just like everything else.

I expect that passing a Proxy() through to context should succeed in an invocation. Barring this, I would expect the type of a context to be specific enough to determine whether it should be wrapped in a Proxy() or not.

I have two questions.

(1) What are the semantics of context binding closures in javascript that would cause binding to a Proxy(context) to fail with an illegal invocation?

(2) What type of object are contexts, and how can a javascript method tell one apart from other javascript objects by inspecting its properties at runtime?

Solution

  • What type of object are contexts, and how can a javascript method tell one apart from other javascript objects by inspecting its properties at runtime?

    There is no special type. Every object can become a context by calling a method upon it. Most objects that will become a context of a method call do have that very method as an (inherited) property, but there's no guarantee.

    You cannot tell them apart.

    What are the semantics of context binding in javascript that would cause binding to a Proxy(context) to fail with an illegal invocation?

    When the method is a native one. In user code functions, the this context being a proxy doesn't make a difference, when you access it then it will just behave as a proxy.

    The problem is native methods that expect their this argument to be a native object of the respective type. Sure, those objects are still javascript objects, but they may contain private data on internal properties as well. A proxy's target and handler references are implemented through such internal properties as well, for example - you can sometimes inspect them in the debugger. The native methods don't know to unwrap a proxy and use its target instead, they just look at the object and notice that it doesn't have the required internal properties for the method to do its job. You could've passed a plain {} as well.

    Examples for such methods can be found as builtins of the ECMAScript runtime:

    But also (and even more of them) as host objects supplied by the environment:

    • window.alert/prompt
    • EventTarget.prototype.addEventListener/removeEventListener
    • document.createElement
    • Element.prototype.appendChild/remove/…
    • really just anything that's browser-specific
    • but also in other environments, like the nodejs os module

    I have tried unwrapping Proxies in the right places by coding in edge cases and by blanket/heuristic policies.

    I think the only reasonable approach would be to check whether the called function is a native one, and unwrap all arguments (including the this argument) for them.

    Only a few native functions could be whitelisted, such as most of those on the Array.prototype which are explicitly specified in the language standard to work on arbitrary objects.