Labs/Jetpack/OOP/PlatformStatus: Difference between revisions
(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...") |
No edit summary |
||
| Line 13: | Line 13: | ||
* load a javascript file into the remote process | * load a javascript file into the remote process | ||
* send and receive message to/from the remote process | * send and receive message to/from the remote process | ||
[https://bugzilla.mozilla.org/show_bug.cgi?id=542242 | [https://bugzilla.mozilla.org/show_bug.cgi?id=542242 bugzilla] | ||
[https://wiki.mozilla.org/Content_Process_Event_Handlers Documentation] | [https://wiki.mozilla.org/Content_Process_Event_Handlers Documentation] | ||
| Line 19: | Line 19: | ||
==== Additionnal future or not already used features ==== | ==== Additionnal future or not already used features ==== | ||
* Cross process object wrapper (Implemented, not used) | * '''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. | These "CPOW" allow to access to attributes and functions of content objects with transparent wrappers, directly from the chrome process. | ||
[https://bugzilla.mozilla.org/show_bug.cgi?id=cpow | [https://bugzilla.mozilla.org/show_bug.cgi?id=cpow bugzilla] | ||
[https://wiki.mozilla.org/Electrolysis/CPOW Documentation] | [https://wiki.mozilla.org/Electrolysis/CPOW Documentation] | ||
* Handles (proposal) | * '''Handles''' (proposal) | ||
Add a way to send handles across processes in order to avoid having to build some objects registries on both processes. | Add a way to send handles across processes in order to avoid having to build some objects registries on both processes. | ||
[https://bugzilla.mozilla.org/show_bug.cgi?id=562414 First bug] | [https://bugzilla.mozilla.org/show_bug.cgi?id=562414 First bug] | ||
[https://bugzilla.mozilla.org/show_bug.cgi?id=572685 Second bug] | [https://bugzilla.mozilla.org/show_bug.cgi?id=572685 Second bug] | ||
These handles may replace CPOW, as said in [https://bugzilla.mozilla.org/show_bug.cgi?id=564382 this bug] | |||
==== Multiple process in firefox, explained ==== | ==== Multiple process in firefox, explained ==== | ||
[[File:Firefox-oop.jpg]] | [[File:Firefox-oop.jpg]] | ||
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. | This chrome window open a tab via a <browser remote="true" /> XUL tag. | ||
So it | 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. You mainly have message manager object appearing on it. | |||
What does it change from a classic <browser /> node ? <br> | |||
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 | 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.<br> | ||
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. | 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. | ||
Revision as of 21:57, 1 March 2011
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
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.
- 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.