I'm way behind on my knowledge of current spidermonkey, but maybe you could JS_DeepFreezeObject a copy of the standard classes and tack them on to your "this", either via inheritance as suggested, or maybe a JSNewResolveOp? (which is de-supported as of Spidermonkey 36 or so, so be careful).
Wes On 4 June 2015 at 13:48, Subhasish Saha <sahacst...@gmail.com> wrote: > On Thursday, 4 June 2015 22:36:28 UTC+5:30, Jason Orendorff wrote: > > 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, <Subhasish Saha> 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 > > > > > We cannot make the class global due the isolated compartment complications. > > We used to mark the global copies of the builtins as read-only so that > untrusted code is not able to modify them. But having single read-only copy > prevents Object.prototype.toString kind of overrides. > > Your suggestion "to use prototypal inheritance to make the > non-globals *appear* to have all the builtins" sounds like some possible > solution. Let me try that. > > Thanks! > _______________________________________________ > 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 > -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 _______________________________________________ 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
