Labs/Jetpack/OOP/PlatformStatus

Current cross process capabilities

Remote browser and Message manager

Fennec already used multi process capabilities since its very beginning. It's not well known, but Firefox 4 already ship the same platform capabilities! You can already use the same API that is using Fennec to provide multi process features:

<xul:browser remote="true" />

Firefox use this xul component to display web content and Fennec have the remote attribute set to "true". This attribute enables a remote browser component in a disctinct process. For now, there is only one distinct process that contains all tabs and all plugins, this process is called plugin-container.

Message manager

Then you will need to communicate with this remote process/browser. Message manager API is the main component that allow to :

• load a javascript file into the remote process
• send and receive message to/from the remote process

bugzilla Documentation

Additionnal future or not already used features

• Cross process object wrapper (Implemented, not used)

These "CPOW" allow to access to attributes and functions of content objects with transparent wrappers, directly from the chrome process.

bugzilla Documentation

• Handles (proposal)

Add a way to send handles across processes in order to avoid having to build some objects registries on both processes. First bug Second bug
These handles may replace CPOW, as said in this bug

Multiple process in firefox, explained

On the left, you have a chrome browser window, living in the main firefox process. This chrome window open a tab via a <browser remote="true" /> XUL tag. So it create a browser node inside the browser window and another part, its "inside" is managed by a remote browser in the plugin-container process, along with plugins and all remote browsers.

What does it change from a classic <browser /> node ?
A lot! Because you won't have the majority of properties and methods on this browser object (url, docshell & al). You mainly have message manager object appearing on it.

So a chrome script from main process use message manager to load browser-actions.js script in the remote browser context and send a "load" event with an url to load.
This event is catched by browser-actions script from remote process, which will simply call docShell.loadURI function in order to load the expected website.

Multi-process big picture

Here is a very big picture of what going on between jetpack OOP experiment available here: Jetpack OOP github page This diagram mainly highlights different sandbox and their location and how they communicate.