One way is to change the class and make it global. This is just a matter of setting some flags in the JSClass. But each global object lives in an isolated compartment, and values must be "wrapped" when they are transferred between compartments. This can be tricky to accomplish if you have a lot of existing code.
Without knowing more about your current code, it's hard to make other suggestions. For example, is the code that's being run this way trusted or untrusted? Could these objects share a single copy of the builtins, or would that be bad? Would it work to use prototypal inheritance to make the non-globals *appear* to have all the builtins, rather than actually having them? -j On Thu, Jun 4, 2015 at 11:38 AM, <sahacst...@gmail.com> wrote: > In SpiderMonkey 1.8.0 we used call JS_InitStandardClasses(cx, > non_global_obj) to get a copy of standard built-in objects in the > non_global_object. > Later we used to pass this non_global_object inside JS_EvaluateUCScript so > that it gets treated as the "this" object and it used to have a copy of > built-in objects. > > Now we are trying to port to SpiderMonkey 24. But here > JS_InitStandardClasses seems not to work with non global objects. > > Our whole workflow is broken. Any solution? > _______________________________________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
