https://wiki.mozilla.org/Content_Processes

The core team who will be working on this project is currently myself, bent,
jdrew, jduell, and bz. If you'd like to volunteer to be part of this core
team, please let me know! We'll definitely be bringing in others as needed.

In order to keep the problem well scoped, we have decided to focus first on
the responsiveness and stability aspects of multi-process, and defer
security sandboxing to a future phase.

There are a lot of unknowns in this project, but I'd like to call out
several in particular:

== Chrome content touching content DOM ==

We'd like to get a list of all the places UI code (chrome) touches content
DOM or JS. At this point we want to get a sense of how frequent this kind of
access is, and what kinds of data it actually needs.

This is because we'd like to avoid having to implement wrappers which expose
arbitrary JS objects or XPCOM objects from the content process to the chrome
process. Instead, all accessses would hopefully be asynchronous. But since
this involves rewriting chrome code, we'd like to scope the problem before
making any decisions.

I can think of at least the following places which touch content from chrome:

* context menus
* session store
* find in page
* snapshots of content (tab previews)

--BDS

On 5/5/09 8:36 AM, Benjamin Smedberg wrote:

Cheers,

Shawn

(this was supposed to go to dev-platform.  my bad)
On 5/5/09 8:52 AM, Shawn Wilsher wrote:

 From a technical point of view, this is incredibly interesting. I would
like to discuss accessibility related issues. Currently most users of
our accessibility API are in-process, so what this means for
multi-process needs to be worked out. I think part of this conversation
will inevitably look beyond the phase of chrome/content separation.
Questions arise, like will the chrome process broker the information
from content(s)? Or do we want another model.

I don't know if it makes sense for me to be part of the core team, but I
want to be as much in the loop as possible.

cheers,
David

On 5/5/09 11:36 AM, Benjamin Smedberg wrote: