Future plans for "Out of the process add-on"'s

[Irakli Gozalishvili]

Hi Folks,

As you might already have heard, [electrolysis](https://wiki.mozilla.org/Electrolysis) effort has been suspend in order refocus on other responsiveness issues (See for details: https://groups.google.com/forum/#!msg/mozilla.dev.planning/4q7SW89MjQY/7f1KConKZLEJ). We held a meeting to discuss impacts of the above mentioned decision on our plans of supporting electrolysis (Out of the process add-ons). We discussed pros and cons of this:

Out of Process Add-ons:

There are plugin process and add-on processes. Plugin processes are there to save the browser from a plugin crash. Add-on processes are there to run JavaScript, while they are not strictly necessary to stop the UI from blocking (long hangs get caught by the long-running script detector, but short hangs don't get caught by that detector), that's only visible way to prevent scripts from hanging the browser for a short period of time (which is a source of browser responsiveness issues).

Pros:

• Much of the add-on code runs in a separate process so cannot hang the UI for short periods of time.
• Has security benefits because we only need to provide what they need to add-ons in the add-on process.
• Gets around the problem with blocking file I/O.

Cons:

• Even with add-on processes some part of the add-on will run in the main process (pagemods) and can hang the UI from there.
• Makes the APIs more complicated than they need to be.
• The e10s code would likely need to be maintained by us.
• Since E10S work is suspended no XPCOM e10sification is expected, which means we would have to do lots of message passing to do anything XPCOM related.
• Windows 8 Metro may not support additional processes.
• Performance and memory costs.

Further thoughts:

• Is e10s likely to come back? What design decision do we make based on the current positioning.
• Async APIs are better for forwards compatibility but more complex.
• Sticking with async APIs is complicated for add-on developers.
• Could diverge from the existing e10s APIs now to do our own more streamlined thing.
• Need better performance measurements for Jetpack.
• What are our main priorities and how does e10s fit into it?
• Do threads give us similar benefits without the same overhead?
• Performance-wise probably.
• Not stability-wise but maybe that isn't as important to us.

Future direction:

• Continue work on keeping the platform separated allowing for out of process / thread / worker support.
• Start taking some measurements the performance of the platform.
• Consider whether to start work on a prototype for running add-ons in their own thread.

Actions

• Mossop to start working on performance tests for the platform.
• Eddy to gather any final useful numbers from the OOP prototype.

If you think there is something on the cons / pros side that has not been listed above please let us know! 

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France