Open Bug 665810 Opened 8 years ago Updated 4 years ago

Allow creation of BackstagePass globals from JavaScript

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

People

(Reporter: kmag, Unassigned)

Details

Currently, the only way to create a full-fleged global into which to load scripts, from JavaScript, is via the Cu.Sandbox. While these function well for their intended uses in sandboxed code, such as Jetpack plugins and user scripts, the new global, unlike those created by Cu.import, resides in its own compartment.

For privileged code, this means that objects that pass into and out of code for these compartment is wrapped in needless proxies. I can't say much for the performance impact of these proxies, but they have other drawbacks, including the inability to wrap E4X objects and therefore pass them in and out of Sandboxes. I've personally also had other issues, in using Mozmill, where any attempt to use evalInSandbox when a sandbox was anywhere in the call stack resulted in the code being evaluated with a primitive JS version.

It would therefore be beneficial for code such as the Add-on Manager and MozMill to be able to create non-Sandbox globals, similar or identical to those used by Cu.import, into which to load their code via means such as the subscript loader.

As a corollary of this bug, it would be useful to be able to load code into these and other objects with the evalInSandbox function, or another function which similarly allows the specification of the JavaScript version and source file names and line numbers. If necessary, I'll file for this separately.
> resides in its own compartment

JS is moving to a 1-1 identification of compartments and globals, so as long as you're creating a new global you will always be creating a new compartment in the very near future.  See bug 650353.
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.