Last Comment Bug 1190679 - (webext-oop) Run WebExtensions out of process
(webext-oop)
: Run WebExtensions out of process
Status: NEW
triaged, [we-enterprise]
:
Product: Toolkit
Classification: Components
Component: WebExtensions: Untriaged (show other bugs)
: unspecified
: All All
P1 major with 13 votes (vote)
: mozilla45
Assigned To: Bill McCloskey (:billm)
:
: Andy McKay [:andym]
Mentors:
Depends on: 1253748 1302702 1323845 1334557 1339144 1202478 1224105 1287004 1287007 1287010 1287209 1287210 1287977 1287978 1288276 1288279 1305216 1305217 1306110 1317101 1320395
Blocks: webextensions-chrome-gaps 1318174 1199718 webext1.0
  Show dependency treegraph
 
Reported: 2015-08-03 20:03 PDT by Bill McCloskey (:billm)
Modified: 2017-02-13 10:34 PST (History)
23 users (show)
amckay: blocking‑webextensions-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: 45.2 - Nov 30
Points: ---
Has Regression Range: ---
Has STR: ---
+


Attachments

Description User image Bill McCloskey (:billm) 2015-08-03 20:03:53 PDT
Besides setting the remote=true attribute on the browser elements used for extensions, we'll need to move the API-injected code to the other process (via content scripts or something). We'll also need platform support to ensure that all the <browser> elements for a given add-on run in the same process.
Comment 1 User image [:fabrice] Fabrice Desré 2015-08-06 21:46:03 PDT
Bill, is this bug about running the background pages OOP or more than that?
Comment 2 User image Bill McCloskey (:billm) 2015-08-07 07:34:18 PDT
There are a couple different kinds of pages that would need to run out of process:
- background page
- browserAction popup page
- any tabs that are showing moz-extension: URIs

We have to move them all together since they can get references to each other's windows.
Comment 3 User image Edgar Chen [:edgar][:echen] 2015-08-09 20:55:55 PDT
I'd like to work on the extensions; assigning this to myself. :)
Comment 4 User image Bill McCloskey (:billm) 2015-08-19 12:15:58 PDT
I think this could be a lot of work, including some platform changes. Do you have a plan for this Edgar? Otherwise we should discuss the approach.
Comment 5 User image Edgar Chen [:edgar][:echen] 2015-08-19 21:11:15 PDT
I believe this is a huge work. And I am still in study stage (trying to get whole picture from bug 1175770). Do you have any suggestion where we should start with? Thank you.
Comment 6 User image Bill McCloskey (:billm) 2015-08-26 17:16:20 PDT
Sorry it took me a while to get to this.

The actual extension code will run in a content process. We'll do this using remote <browser> elements (and maybe remote moz-browser elements on b2g). The main process will load a process script into the extension process and the two processes will communicate using the process message manager.

We'll need some platform support to ensure that all these <browser> elements run in the same extension process. That could be an attribute on the <browser> DOM element. The <browser> elements that will need this attribute are for the background page, the browser action, and any page loaded with a moz-extension URI. For the latter, we'll need special handling in E10SUtils.jsm [1] on desktop to ensure that the page loads in the right process. I'm not sure how to handle that on b2g.

The ext-*.js scripts will have to be split into main process scripts and an extension process scripts. They'll communicate using the process message manager. Most API functions will probably just be forwarded to the main process, with their arguments sent using structured clone. However, there are some APIs that pass functions, so we'll have to do something special there.

The webRequest API will also need special handling. Right now it requires the request handlers to be synchronous, which won't be the case when the extension is OOP. I think we'll have to make it suspend the request until the extension makes a decision about whether to block.

I think the best way to get started here is to start using a non-remote browser element for the background page. Right now the code is loaded directly into a windowless docshell. If that works, then we can start moving some of the ext-*.js code to process scripts (as well as some of the related code in Extension.jsm, such as GlobalManager).

[1] http://mxr.mozilla.org/mozilla-central/source/browser/modules/E10SUtils.jsm#62
Comment 7 User image [:fabrice] Fabrice Desré 2015-08-26 18:33:16 PDT
(In reply to Bill McCloskey (:billm) from comment #6)
> Sorry it took me a while to get to this.
> 
> The actual extension code will run in a content process. We'll do this using
> remote <browser> elements (and maybe remote moz-browser elements on b2g).
> The main process will load a process script into the extension process and
> the two processes will communicate using the process message manager.
> 
> We'll need some platform support to ensure that all these <browser> elements
> run in the same extension process. That could be an attribute on the
> <browser> DOM element. The <browser> elements that will need this attribute
> are for the background page, the browser action, and any page loaded with a
> moz-extension URI. For the latter, we'll need special handling in
> E10SUtils.jsm [1] on desktop to ensure that the page loads in the right
> process. I'm not sure how to handle that on b2g.

On b2g we had a need to run different apps in the same process (for Tarako) and we did that by adding a parentapp attribute on <iframe mozbrowser>. The ContentParent uses this attribute at http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#1264

> I think the best way to get started here is to start using a non-remote
> browser element for the background page. Right now the code is loaded
> directly into a windowless docshell. If that works, then we can start moving
> some of the ext-*.js code to process scripts (as well as some of the related
> code in Extension.jsm, such as GlobalManager).

Right, that's what I'm fixing in bug 1198970 as part of getting webRequest to work.
Comment 8 User image Edgar Chen [:edgar][:echen] 2015-10-19 20:56:37 PDT
Unassigning myself as I am not able to work on this in short term.
Comment 9 User image Andy McKay [:andym] 2016-03-07 14:45:15 PST
After chatting with Bill, we decided to move this to post 48, but before we implement any APIs beyond Chromes implementation.

Note You need to log in before you can comment on or make changes to this bug.