Labs/Jetpack/OOP/PlatformStatus

From MozillaWiki
< Labs‎ | Jetpack
Revision as of 17:38, 1 March 2011 by Apoirot (talk | contribs) (Created page with "== Current cross process capabilities == === Remote browser and Message manager === Fennec already used multi process capabilities since its very beginning. It's not well known...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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

Implementation tracker in 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.

Implementation tracker on 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 There handles may replace CPOW, as said in this bug

Multiple process in firefox, explained

Firefox-oop.jpg Here 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 creates a remote browser in the plugin-container process, aside plugins and others 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. You mainly have message manager object appearing on it.

So one 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