Electrolysis/Archive

Building & Debugging

• Build and Run Instructions
• Tinderbox with automated build reports
• Debugging
• Frequently Asked Questions

Status

Out-of-process plugins (OOPP) has shipped in Firefox 3.6.4 in June 2010.

Out-of-process tabs for Fennec is utilized in the Mobile Firefox 4.0 betas, and will ship with the final version in March 2011.

Design Documents

• Electrolysis/Extension Compatibility
• Multi-Process Plugin Architecture
• Errors and Shutdown
• Cross-Process Object Wrapper (CPOW)
• Content Process Event Handlers
• Places that need Session History
• NPAPI Questions - Questions gathered from trying to remote various pieces of NPAPI
• Necko & electrolysis
• Remote Preferences design
• Multi-Process Jetpack design considerations
• Geolocation service changes
• XBL browser widget changes

Goals

Initial goals:

• Provide better application UI responsiveness
• Improve stability from slow rendering or crashes caused by content
• Improve performance, especially on multi-core machines

Potential future goals:

• Provide security enhancements by running the content process in protected or isolated modes.

Implementation

Individual Implementation tasks are being tracked in bugzilla using tracking bugs:

• Overall Electrolysis tracking
  • Plugins (OOPP) Tracking
  • Multi-Process Fennec tracking

Fennec OOP-Tabs Phase I (Done)

Get something hacked together as quickly as possible.

Fennec OOP-Tabs Phase II (In process)

Get the full set of Fennec features working with multi-process tabs. After phase II, we should be able to run the Fennec UI and pass tests.

Move all networking to the parent process. Currently the content process runs its own networking stack. Because it does not have a profile, this means that HTTPS websites don't work, cookies don't work, offline web apps don't work, etc. It also means that there is a separate memory cache for content and chrome requests.

Global history information. In order for link coloring to work correctly, as well as the awesomebar and other features, the content process must inform chrome when pages have been visited. The chrome process will maintain the places database and asynchronously inform the content process of the correct visited state for links.

Proxy any other necessary profile access to the parent process. Besides what is discussed above, the content process should have a read-only view of user preferences.

Docshell-related changes. The content process maintains its view of session history. In order for back/forward to work correctly, the chrome process must have some awareness of the session history state (done). If we need to support navigating to certain about: pages (about:config), the chrome process will need to render these pages and more advanced session history will need to be developed. Links/scripts which target named or new windows (target="foo" or target="_blank") need to forward those requests to the chrome process for the Fennec UI to open a new tab (done for single content process, more work needed for multiple content processes).

Focus handling: we are not sure that focus handling is always correct and that onblur/onfocus events are fired at the correct times.

Zooming/interaction: certain operations such as double-tapping use page information to perform their actions. These operations should retreive page information asynchronously if possible. The features affected are currently unknown.

Schedule Goal: 1-April-2010

Fennec OOP-Tabs Phase III: extensions/compatibility/performance

Extension compatibility: simple touching of content through .contentWindow/.contentDocument should work using CPOW wrappers, but such usage will cause extensions to block chrome on content. New APIs will allow extensions to register arbitrary event listeners within the content process itself and non-blocking handle that information in chrome. TODO: once CPOWs are in place, actually experiment with a few top extensions to see what pain points exist.

Ideally, make multi-process jetpack available as a first-class extension mechanism.

Measuring, tuning, and polish. Measure memory usage for both processes. Measure responsiveness (TBeachball) for the chrome process. Possible problems: duplicated font metrics or other graphics caches may use more memory than desirable.

After this phase, we should be ready for a release. UI responsiveness should be noticeably better. A single misbehaving website could still take down all the user's content, however.

Schedule goal: 1-July-2010, although it's not clear how this fits into gecko release schedules

Phase IV: Multiple content processes

• Run multiple content processes on-demand per tab/tabgroup/domain/whatever
• Graphics: figure out shared/separate image caches
• Graphics: figure out shared/separate font-metrics caches
• Hook up multiple process monitoring for users

Frankly once phase III is done, I expect this will be fairly quick and painless: the major risk is startup time and memory use regressions. As mentioned above, additional docshell work will be necessary to support session history which crosses process boundaries as well as link targeting which may cross process boundaries in some limited cases.

Future Phases

• Security sandboxing (involves removing the native widgets and event loop from the content processes)

Testing

The performance testing infrastructure is going to require some new features to deal with processes. In particular, we'll want to measure memory usage and Tbeachball for the chrome and any content processes separately.

Subprojects

The IPDL language is designed to help you more easily write safe code that talks across processes and threads.