Function.prototype.constructor is tamed in the host

[evanw]

We recently ran into a problem with the Realm shim. We're injecting the shim into our page via <script src="..."> and then using the Realm object. However, that causes Function to be tamed in the host page, which we weren't expecting to happen.

Recently we upgraded selenium-webdriver, one of our 3rd-party dependencies, that apparently now calls Function("...") to eval something. When the Realm shim is loaded, that no longer works. We end up getting TypeError: Not available when we call their driver.executeScript API call.

Is there a reason to tame Function in the host environment? We think we can work around it on our end by loading the Realm shim into a same-origin iframe instead, but I wanted to file this issue with you in case this behavior was unintended. I imagine this behavior will also trip up others trying to use the shim in the future.

[Jack-Works]

Also have this problem when developing WebExtension-shim

[erights]

I am not sure I understand which realm's Function constructor you mean. When you create a new root realm, the Function constructor of that realm is indeed tamed. By "host page", do you mean the realm from which you asked to make a new root realm, as opposed to the root realm created by such a call? If so, then this indeed surprises me and is likely a bug. Could you post a small piece of code that demonstrates the problem? Thanks.

[Jack-Works]

When you creating a new realm, the outside world (out of the sandbox)'s Function is polluted. And code relay on that can not work properly

[erights]

Ok, that is definitely a bug. Will investigate. Thanks all!!!

[Jack-Works]

A fix is available at 969f1fe

[ExE-Boss]

The correct fix is to delete this line in createCurrentUnsafeRec():

realms-shim/src/unsafeRec.js

Line 130 in 067bdd9

repairFunctions();

Turns out, that breaks makeCompartment().

[erights]

Before shutting down or transferring the realms shim, in addition to applying relevant improvements to the compartments shim (see endojs/endo#481) we should also migrate relevant outstanding open PRs and issues, such as this one.