The JSM loader use-case pre-populates an NSVO with properties such as __URI__. This patch adds a new jsfriendapi ExecuteInNonSyntacticGlobal that allows environment to be in-outs. This allows allocating the environment before execution and setting properties. The environment is also returned out to allow executing other scripts in same context or looking at bindings. NOTE: The |this| binding is still the global and not the NSVO. I'm working on follow-up patches to untangle that.

Depends on Bug 1394490 to be able to set |this| to NSVO.

Comment on attachment 8902927 [details] Bug 1395360 - Factor out ExecuteInNonSyntacticGlobalInternal https://reviewboard.mozilla.org/r/174658/#review180680 ::: js/src/builtin/Eval.cpp:457 (Diff revision 4) > +{ > + RootedObject varEnv(cx, NonSyntacticVariablesObject::create(cx)); > + if (!varEnv) > + return false; > + > + RootedObject lexEnv(cx, LexicalEnvironmentObject::createNonSyntactic(cx, varEnv, varEnv)); We need to add this to the non-syntactic lexical environments map for the compartment, like we do when calling ExecuteScript with an env chain, or the component loader won't be able to resolve exported lexical symbols when loading modules: http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/js/src/jsapi.cpp#3569 http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/js/src/jscompartment.cpp#588 http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/js/xpconnect/loader/mozJSComponentLoader.cpp#315-332

Pulling review request. It was premature before we have the JSM bug working since it is the only consumer of this API change. Sorry :(

Putting new attempt up for review now. This works with the JSM shared global patch and that build has been stable for my daily browser for a couple days.

Comment on attachment 8902927 [details] Bug 1395360 - Factor out ExecuteInNonSyntacticGlobalInternal https://reviewboard.mozilla.org/r/174658/#review182588 ::: js/src/builtin/Eval.cpp:454 (Diff revision 5) > - MutableHandleObject envArg) > + HandleObject varEnv, HandleObject lexEnv) > { > CHECK_REQUEST(cx); > assertSameCompartment(cx, global); > + assertSameCompartment(cx, varEnv); > + assertSameCompartment(cx, lexEnv); There are overrides so that you can say: assertSameCompartment(cx, global, varEnv, lexEnv);

Comment on attachment 8903758 [details] Bug 1395360 - Add ExecuteInNonSyntacticGlobal to jsfriendapi https://reviewboard.mozilla.org/r/175506/#review182592 ::: js/src/builtin/Eval.cpp:498 (Diff revision 6) > envArg.set(lexEnv); > return true; > } > + > +JS_FRIEND_API(JSObject*) > +js::CreateNonSyntacticGlobal(JSContext* cx) I don't think it's a good idea to call this a "NonSyntacticGlobal". It really isn't a global; at best it's an object that acts kind of like a global. And "non-syntactic" as a qualifier won't help anyone figure out the distinction... I'd be happier with `js::NewJSMEnvironment(cx)`. Any name better than that is just gravy.

Pushed by tcampbell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d89ac77cac51 Factor out ExecuteInNonSyntacticGlobalInternal r=jorendorff https://hg.mozilla.org/integration/autoland/rev/d731723c09f7 Add ExecuteInNonSyntacticGlobal to jsfriendapi r=jorendorff

https://hg.mozilla.org/mozilla-central/rev/d89ac77cac51 https://hg.mozilla.org/mozilla-central/rev/d731723c09f7