Electrolysis: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(mention "e10s" codename)
(Update wiki for people landing here from the e10s opt-in door hanger's "Learn More" link)
Line 1: Line 1:
==Goal==
==Goal==


The goal of the Electrolysis (known as "e10s" for short) project is to run web content in a separate process from Firefox itself. The two major advantages of this model are security and performance. Security would improve because the content processes could be sandboxed (although sandboxing the content processes is a separate project from Electrolysis). Performance would improve because the browser UI would not be affected by poor performance of content code (be it layout or JavaScript). Also, content processes could be isolated from each other, which would have similar security and performance benefits.
The goal of the Electrolysis project ("e10s" for short) is to run web content in a separate process from Firefox itself. The two major advantages of this model are security and performance. Security would improve because the content processes could be sandboxed (although sandboxing the content processes is a separate project from Electrolysis). Performance would improve because the browser UI would not be affected by poor performance of content code (be it layout or JavaScript). Also, content processes could be isolated from each other, which would have similar security and performance benefits.


Although the Gecko platform supports multiple processes, the Firefox frontend is not designed to use them. Work to make the frontend (including addons) support multiple processes was begun in early 2013. The [[Electrolysis/Roadmap|project roadmap]] has more details.
Although the Gecko platform supports multiple processes, the Firefox frontend is not designed to use them. Work to make the frontend (including addons) support multiple processes was begun in early 2013. The [[Electrolysis/Roadmap|project roadmap]] has more details.
Line 7: Line 7:
==Enabling Electrolysis==
==Enabling Electrolysis==


We're developing off of mozilla-central. Therefore, it's possible to enable Electrolysis right now in Firefox nightlies.
To enable or disable e10s, open Nightly's Preferences and check the "Enable E10S" checkbox. You will need to restart Nightly. Alternately, you can also toggle the ''browser.tabs.remote'' and ''browser.tabs.remote.autostart'' prefs to enable (true) or disable (false) e10s.


* Update to a current nightly.
==Contributing==
* We strongly recommend you create a new profile!
 
* Set the browser.tabs.remote preference to true.
The simplest way to help out is to file bugs when you find them. The tracking bugs are [https://bugzilla.mozilla.org/show_bug.cgi?id=fxe10s fxe10s] and [https://bugzilla.mozilla.org/show_bug.cgi?id=core-e10s core-e10s].
* As of Firefox 30 set browser.tabs.remote.autostart to true to always enable e10s; otherwise, create a new e10s window.
 
* Restart Firefox.
* Link to all open e10s bugs: http://is.gd/QripTz
** Please check the open bugs for duplicates before filing a new bug.
* Link to file new e10s bug: http://is.gd/aTza8A
** Please include the string "e10s" in the bug summary so we can more easily track your bug.
 
Most bugs in e10s occur because code in the chrome process tries to access data in a content process. All of the DOM objects for a XUL browser element, as well as its DocShell, live in the content process. Typical access paths are via <code>browser.contentWindow</code>, <code>browser.docShell</code>, or some variation of them. Often, these property accesses will generate errors in the console, which makes these bugs fairly easy to detect. MDN has a good introduction to e10s, useful for both Firefox and add-on developers: https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox


==What to Expect==
==What to Expect==
Line 19: Line 24:
Basic browsing should work as expected. Tabs that are loaded remotely (i.e., in a separate process) will have their title underlined. By default, only one content process is used. You can control this with the dom.ipc.processCount preference.
Basic browsing should work as expected. Tabs that are loaded remotely (i.e., in a separate process) will have their title underlined. By default, only one content process is used. You can control this with the dom.ipc.processCount preference.


For a list of known issues that people commonly run into, see https://etherpad.mozilla.org/e10s-known-issues
===Known Issues===
 
Known issues you might run into when testing e10s:
==Contributing==
* HTTP redirects don't always work: {{bug|997808}}, {{bug|1050869}}
 
* Printing does not work: {{bug|927188}}
The simplest way to help out is to file bugs when you find them. The tracking bugs are [https://bugzilla.mozilla.org/show_bug.cgi?id=fxe10s fxe10s] and [https://bugzilla.mozilla.org/show_bug.cgi?id=core-e10s core-e10s].
* WebRTC does not work: {{bug|849746}}
* Gmail login does not work if third-party cookies are always blocked: {{bug|1049299}}
* Accessibility does not work: {{bug|1029143}}
* Plugin click-to-play does not work: {{bug|899347}}
* Spell checker does not work: {{bug|1030449}}
* PDF.js does not work: {{bug|942707}}
* Middle-click, Open Link in New ... options doesn't work


Most bugs in electrolysis occur because code in the chrome process tries to access data in a content process. All of the DOM objects for a XUL browser element, as well as its DocShell, live in the content process. Typical access paths are via <code>browser.contentWindow</code>, <code>browser.docShell</code>, or some variation of them. Often, these property accesses will generate errors in the console, which makes these bugs fairly easy to detect.
===Add-ons Compatibility===


The ideal way to solve these problems is with [https://developer.mozilla.org/en-US/docs/The_message_manager the message manager]. Any code that touches data in the content process should run in a content script. Content scripts communicate with chrome by message passing. Often, it's fairly easy to partition code into content and chrome portions and use message passing to communicate.
A list of tested add-ons (compatible and incompatible) is available at http://arewee10syet.com. Some popular add-ons that are currently broken with e10s:


However, there are cases where it is awkward to partition code in this way. In these cases, it may be beneficial to use [https://developer.mozilla.org/en-US/docs/Cross_Process_Object_Wrappers cross-process object wrappers (CPOWs)]. CPOWs make it easy to transparently access content objects from chrome. The main drawback of CPOWs is that they are slow and they cause the chrome process to block, which can lead to jank. However, there are times when it makes sense to use CPOWs. For example, CPOWs are used to generate the menu items for the Firefox context menu. Creating the context menu sends a small number of CPOW messages since it doesn't touch the content document very much. And while the main event loop will be blocked while generating the context menu, users are unlikely to notice since they're just waiting for the menu to appear.
* Bugzilla Tweaks/BugzillaJS: {{bug|972507}}
* HTTPS Everywhere: {{bug|1014986}}
* Tree Style Tabs: {{bug|1042680}}
* 1Password: {{bug|1042195}}
* NoScript: {{bug|1058542}}


==Communication==
==Communication==
Line 41: Line 56:
* [https://etherpad.mozilla.org/E10s-meeting-notes Meeting Notes Etherpad]
* [https://etherpad.mozilla.org/E10s-meeting-notes Meeting Notes Etherpad]
* Historical Notes: [[Content Processes/Meetings|Meeting Agendas and Notes]]
* Historical Notes: [[Content Processes/Meetings|Meeting Agendas and Notes]]
* We are currently looking into a time that could work for Australian eastern timezone.
|-
|-
| IRC
| IRC
Line 126: Line 140:
==Reference==
==Reference==


* [https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox MDN: Working with multiprocess Firefox]
* [https://developer.mozilla.org/en-US/docs/The_message_manager The message manager]
* [https://developer.mozilla.org/en-US/docs/The_message_manager The message manager]
* [https://developer.mozilla.org/en-US/docs/Cross_Process_Object_Wrappers Cross-process object wrappers]
* [https://developer.mozilla.org/en-US/docs/Cross_Process_Object_Wrappers Cross-process object wrappers]
* [[Electrolysis/Archive | Archive of past content on this page]]
* [[Electrolysis/Archive | Archive of past content on this page]]
* [https://etherpad.mozilla.org/uYS8ZplOMU Electrolysis platform notes]
* [https://etherpad.mozilla.org/uYS8ZplOMU Electrolysis platform notes]
* [https://etherpad.mozilla.org/rRk4aEHkwC Notes on the Chromium IPC library]
* [https://etherpad.mozilla.org/rRk4aEHkwC Notes on the Chromium IPC library]
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhFRRYurPzRndHQwUVNscThIbFBsYmNRaU44LVlDdlE#gid=0 Addon Compatibility Test Results]
* [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AhFRRYurPzRndHQwUVNscThIbFBsYmNRaU44LVlDdlE#gid=0 Addon Compatibility Test Results]
* [http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIMessageManager.idl#13 IDL comments about Message Manager]
* [http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIMessageManager.idl#13 IDL comments about Message Manager]
* Tim Taubert's [http://timtaubert.de/blog/2011/08/firefox-electrolysis-101/ "Firefox Electrolysis 101"] blog post (2011)
* Tim Taubert's [http://timtaubert.de/blog/2011/08/firefox-electrolysis-101/ "Firefox Electrolysis 101"] blog post (2011)


Revision as of 07:41, 11 September 2014

Goal

The goal of the Electrolysis project ("e10s" for short) is to run web content in a separate process from Firefox itself. The two major advantages of this model are security and performance. Security would improve because the content processes could be sandboxed (although sandboxing the content processes is a separate project from Electrolysis). Performance would improve because the browser UI would not be affected by poor performance of content code (be it layout or JavaScript). Also, content processes could be isolated from each other, which would have similar security and performance benefits.

Although the Gecko platform supports multiple processes, the Firefox frontend is not designed to use them. Work to make the frontend (including addons) support multiple processes was begun in early 2013. The project roadmap has more details.

Enabling Electrolysis

To enable or disable e10s, open Nightly's Preferences and check the "Enable E10S" checkbox. You will need to restart Nightly. Alternately, you can also toggle the browser.tabs.remote and browser.tabs.remote.autostart prefs to enable (true) or disable (false) e10s.

Contributing

The simplest way to help out is to file bugs when you find them. The tracking bugs are fxe10s and core-e10s.

  • Link to all open e10s bugs: http://is.gd/QripTz
    • Please check the open bugs for duplicates before filing a new bug.
  • Link to file new e10s bug: http://is.gd/aTza8A
    • Please include the string "e10s" in the bug summary so we can more easily track your bug.

Most bugs in e10s occur because code in the chrome process tries to access data in a content process. All of the DOM objects for a XUL browser element, as well as its DocShell, live in the content process. Typical access paths are via browser.contentWindow, browser.docShell, or some variation of them. Often, these property accesses will generate errors in the console, which makes these bugs fairly easy to detect. MDN has a good introduction to e10s, useful for both Firefox and add-on developers: https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox

What to Expect

Basic browsing should work as expected. Tabs that are loaded remotely (i.e., in a separate process) will have their title underlined. By default, only one content process is used. You can control this with the dom.ipc.processCount preference.

Known Issues

Known issues you might run into when testing e10s:

Add-ons Compatibility

A list of tested add-ons (compatible and incompatible) is available at http://arewee10syet.com. Some popular add-ons that are currently broken with e10s:

Communication

Weekly Team Meeting Thursday at 2:00pm PT for 30 mins
IRC
  • Server: irc.mozilla.org
  • Channel: #e10s
Tracking bugs
Newsgroup/Mailing List
Project branch

People

Project Champion
  • Andreas Gal ( A )
High Level Oversight
  • Johnathan Nightingale ( I )
  • Gavin Sharp ( A )
Engineering Management
  • Brad Lassey ( R )
Project Management
  • Chris Peterson ( R )
QA
  • Juan Becerra (QA lead)
Development Team
  • Nicholas Alexander ( R )
  • Mike Conley ( R )
  • Felipe Gomes (Firefox front-end) ( R )
  • Blake Kaplan ( R )
  • William McCloskey ( R )
  • Jim Mathies ( R )
  • Allison Naaktgeboren ( R )
  • John Schoenick (plugins) ( R )
  • Tom Schuster ( R )
  • Tomislav Jovanovic (addon-sdk) ( R )
Other Teams
  • Accessibility: Alexander Surkov and Trevor Saunders (bug 646596)
  • Addon Developer Relations: Jorge Villalobos
  • Developer Tools: Rob Campbell (bug 875871)
  • IME: Makoto Kato (alternately, Masayuki Nakano) (bug 926798)
  • Jetpack: Dave Townsend
  • OMTC/Windows: Nick Cameron (bug 756608)
  • Printing: bz (bug 927188)
  • Plugins: Josh Aas (OS X), Karl Tomlinson (Linux)
  • Sandboxing: Brian Bondy, Sid Stamm (bug 925570)
  • WebAudio: Ehsan Akhgari (WebAudio works fine in e10s.)
  • WebRTC: Randell Jesup or Eric Rescorla. WebRtc is currently getting ready to go into B2G - mozGetUserMedia will be in 26/1.2, and PeerConnections will be in 28/1.3.
  • e10s tests: Mark Hammond

Here is what the letters following each name stand for, those higher on the list include all those below:

  • R = Responsible for deliverable, in most cases this is anyone writing code.
  • A = Accountable for the final decision making on some aspect of the project, often leadership that is not working on code but have go, no go decision making.
  • C = Needs to be consulted on key topics, often this would be for subject mater experts that need to be consulted but don't have decision making power.
  • I = Needs to be kept informed, those that just need regular status reports sent to them.

Reference

Meeting Notes

For latest meeting notes, see the Meeting Notes Etherpad.

Create a new weekly agenda from the template: <createbox> align=left type=create preload=Electrolysis/Meetings/0-0-0 default=2025-12-18 prefix=Electrolysis/Meetings/ </createbox>

Retrieved from "https://wiki.mozilla.org/index.php?title=Electrolysis&oldid=1014163"