Open Bug 1190679 (webext-oop) Opened 9 years ago Updated 1 year ago

[meta] Run WebExtensions out of process

Categories

(WebExtensions :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

mozilla45

People

(Reporter: billm, Unassigned)

References

(Depends on 14 open bugs, Blocks 2 open bugs)

Details

(Keywords: meta, perf, Whiteboard: triaged, [we-enterprise])

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.
Priority: -- → P2
Bill, is this bug about running the background pages OOP or more than that?
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.
Component: Extension Compatibility → WebExtensions
Product: Firefox → Toolkit
I'd like to work on the extensions; assigning this to myself. :)
Assignee: nobody → echen
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.
Flags: needinfo?(echen)
Summary: Run open extensions out of process → Run WebExtensions out of process
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.
Flags: needinfo?(echen) → needinfo?(wmccloskey)
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
Flags: needinfo?(wmccloskey)
(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.
Depends on: 1202478
Blocks: webext
Severity: normal → major
Priority: P2 → P1
Unassigning myself as I am not able to work on this in short term.
Assignee: echen → nobody
Flags: blocking-webextensions+
Assignee: nobody → wmccloskey
Iteration: --- → 45.1 - Nov 16
OS: Unspecified → All
Hardware: Unspecified → All
Version: 34 Branch → unspecified
Iteration: 45.1 - Nov 16 → 45.2 - Nov 30
Target Milestone: --- → mozilla45
Whiteboard: triaged
After chatting with Bill, we decided to move this to post 48, but before we implement any APIs beyond Chromes implementation.
Flags: blocking-webextensions+ → blocking-webextensions-
Depends on: 1287209
Depends on: 1287210
Alias: webext-oop
Depends on: 1288276
Depends on: 1288279
Depends on: 1305216
Depends on: 1305217
Depends on: 1306110
Depends on: 1317101
Depends on: 1320395
Depends on: 1323845
webextensions: --- → +
Blocks: 1318174
Depends on: 1334557
Whiteboard: triaged → triaged, [we-enterprise]
Depends on: 1339144
Assignee: wmccloskey → kmaglione+bmo
Depends on: 1356317
Depends on: 1353060
Depends on: 1357486
Depends on: 1357487
Depends on: 1357490
Depends on: 1357729
Whiteboard: triaged, [we-enterprise] → triaged, [we-enterprise][qf:meta]
Depends on: 1362457
Depends on: 1355239
Depends on: 1361661
Depends on: 1365660
Blocks: webext-perf
Whiteboard: triaged, [we-enterprise][qf:meta] → triaged, [we-enterprise][qf:meta][qf:p1]
Depends on: 1369559
Depends on: 1370131
Depends on: 1372917
Depends on: 1375490
Depends on: 1379046
Depends on: 1379508
Depends on: 1380156
Depends on: 1380290
Depends on: CVE-2017-7816
Depends on: 1380622
Depends on: 1380646
Depends on: 1381023
Depends on: 1381086
No longer depends on: 1380646
No longer depends on: webextensions-startup
Depends on: 1381097
Depends on: 1381212
Depends on: 1381337
Depends on: 1381321
Depends on: 1381344
Depends on: 1380294
Depends on: 1381810
Taking off webextensions+ and qf:p1. We've got out of process running on Windows which is the main quantum flow target. We'd like to get out of process working on OS X and Linux, but those will likely come after 57. The bug for turning on out of process on windows was bug 1357486.
webextensions: + → ---
Whiteboard: triaged, [we-enterprise][qf:meta][qf:p1] → triaged, [we-enterprise][qf:meta]
Depends on: 1382271
Depends on: 1382228
Depends on: 1380109
No longer depends on: 1323845
No longer depends on: 1381212
Depends on: 1385403
Depends on: 1385548
Depends on: 1385736
Depends on: 1385880
Depends on: 1384078
Depends on: 1387386
Depends on: 1388336
I also had a problem with <select> drop down menu showing but not working in sidebar. Tomislav suggested setting 'extensions.webextensions.remote' to false and after reloading the extension, the drop down menu worked fine in the sidebar. I am using FF56.0b1 The default 'extensions.webextensions.remote' is true and users will not be expected to change it.
Depends on: 1389496
Blocks: 1389495
Depends on: 1390445
Depends on: 1392210
Depends on: 1393150
Depends on: 1394208
Blocks: 1394240
Depends on: 1395898
Depends on: 1394807
Depends on: 1397210
Priority: P1 → --
Iteration: 45.2 - Nov 30 → ---
Keywords: meta
Priority: -- → P2
Depends on: 1390276
Depends on: 1403965
Keywords: perf
Depends on: 1411285
Depends on: 1415860
Depends on: 1419285
Depends on: 1417043
Depends on: 1418394
Depends on: 1418655
Depends on: 1423817
Depends on: 1422187
Depends on: 1433879
No longer depends on: 1370131
Depends on: 1408756
Product: Toolkit → WebExtensions
Component: Untriaged → General
Assignee: kmaglione+bmo → nobody
Summary: Run WebExtensions out of process → [meta] Run WebExtensions out of process
Depends on: 1560835
Priority: P2 → P3

I suppose that bug 1513656 should be considered a regression.

Performance Impact: --- → ?
Whiteboard: triaged, [we-enterprise][qf:meta] → triaged, [we-enterprise]
Performance Impact: ? → ---

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Type: defect → enhancement
Severity: -- → N/A
Depends on: 1827085
You need to log in before you can comment on or make changes to this bug.