What is the use case for this? Obviously you already get the context in a call. If you did need it, you could assign it as a property to the returned proxy object since you passed it in.

Hi dmethvin,

In my specific use case, a dictionary exists containing a list of callbacks (all proxies) that fill specific elements with content. The dictionary maps content id's to each callback. Elsewhere in the code (a recent addition) a content id exists for which I need an element. Using the dictionary I can get the callback to fill the element, but I need a handle to the element itself.

Your suggestion would definitely work, but for now I've implemented a different mechanism for mapping content id's to elements. I still think this would be a useful addition to jQuery.

Hi dmethvin,

In my specific use case, a dictionary exists containing a list of callbacks (all proxies) that fill specific elements with content. The dictionary maps content id's to each callback. Elsewhere in the code (a recent addition) a content id exists for which I need an element. Using the dictionary I can get the callback to fill the element, but I need a handle to the element itself.

Your suggestion would definitely work, but for now I've implemented a different mechanism for mapping content id's to elements. I still think this would be a useful addition to jQuery.

This creates a side channel—any code that can reach this .context property can also maliciously modify any writable or configurable properties, which in turn allows access to potentially sensitive references that would otherwise be out of reach.

Well in this case, the patch is only saving the .context as a property of the proxy but it is still using the original closure variable in the call.

Putting the context on the object, even if it can't be modified, doesn't seem like a good idea if it would leak information not generally needed by the caller. If the creator of the proxy wants to share the context it can certainly do so by adding the property to the object after creating it.