Closed Bug 557340 Opened 10 years ago Closed 10 years ago
Allow non-chrome-privileged Components
.utils .Sandbox instances to exist in separate processes
For Jetpack, we'll need to be able to execute semi-privileged extension code in their own sandboxes, which should be able to exist in separate processes. Authority will be provided to them via CPOWs/reverse-CPOWs (see bug 557259) that are effectively injected into the sandbox via require().
Summary: Allow unprivileged Components.utils.Sandbox instances to exist in separate processes → Allow non-chrome-privileged Components.utils.Sandbox instances to exist in separate processes
I think you could file this as "create a jetpack process type and make it work". Currently we're using content processes, but that's definitely incorrect. However, I think we need to look at this a little. Currently you have a JS scope for the jetpack itself (a sandbox scope), and you have a JS scope for the jetpack implementation (a chrome scope). I think for multi-process you're going to need a third scope: jetpack process: Jetpack itself jetpack process: jetpack implementation code that needs to run in the jetpack process firefox process: jetpack implementation code that needs to run in the firefox process Also remember that the jetpack process isn't going to be using XPCOM.
This was resolved by bug 556846, so I'm marking it as duplicate.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 556846
You need to log in before you can comment on or make changes to this bug.