Changes

The goal of the Electrolysis project (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.

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

==Contributing== 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]. * Update Link to all open e10s bugs: http://is.gd/QripTz** Please check the open bugs for duplicates before filing a current nightlynew bug.* We strongly recommend you create a Link to file new profile!e10s bug: http://is.gd/aTza8A* Set * Please include the string "e10s" in the browserbug summary so we can more easily track your bug.tabs.remote preference  Most bugs in e10s occur because code in the chrome process tries to trueaccess data in a content process.* As All of Firefox 30 set 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.tabscontentWindow</code>, <code>browser.remotedocShell</code>, or some variation of them.autostart Often, these property accesses will generate errors in the console, which makes these bugs fairly easy to true detect. MDN has a good introduction to always enable e10s; otherwise, create a new e10s windowuseful for both Firefox and add-on developers: https://developer.* Restart Firefoxmozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox

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

The ideal way to solve these problems A list of tested add-ons (compatible and incompatible) is with [httpsavailable at http://developerarewee10syet.mozillacom.org/enSome popular add-US/docs/The_message_manager the message manager]. Any code ons that touches data in the content process should run in a content script. Content scripts communicate are currently broken with chrome by message passing. Often, it's fairly easy to partition code into content and chrome portions and use message passing to communicate.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* Bugzilla Tweaks/BugzillaJS: {{bug|972507}}* HTTPS Everywhere: {{bug|1014986}}* Tree Style Tabs: {{bug|1042680}}* 1Password: {{bug|1042195}}* NoScript://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.{{bug|1058542}}