This is a tracking bug for making Mozilla run plugins out of process. The rough outline of how we're attempting to do this is as follows.
We're going to ease in to this problem slowly, as it's a very tricky thing to do right across platforms. Chrome does this today, but only in a shipping version on Windows. We'll be sharing as much code as we can with Chrome, and we may selectively run plugins out of process to begin with, and only on select platforms, i.e. only flash on Windows to begin with, or whatever plugin we pick. Ideally we'll be able to share most of the remoting code with Chrome rather than re-inventing that wheel. Once this work is off the ground we'll be looking at running the plugin process(es) in lower rights mode too, and that'll require significant API changes for plugins to work right when run in lower rights mode, not to mention us needing OS APIs to start processes in lower rights mode, on all platforms.
More details and followup bugs to follow...
Can we start with a list of items/bugs that describe what we would like to accomplish with out of process plugins?
Konqueror has been doing that for a while, AFAIK, and two usually quoted benefits they get from it is running 32-bit plugins on 64-bit browser builds and not crashing the browser when the plugin crashes.
There's a thing called "nspluginwrapper" that does out-of-process plugins -- it's primarily aimed at being able to execute 32-bit plugins on a 64-bit browser under Linux, it's not especially reliable, and I have no idea how it works, but it might be worth cribbing for ideas?
do we want to add things like bug 348170 for possible test cases to check the implementation against? remove from dependency if not.
I maintain nspluginwrapper in Fedora. Nspluginwrapper runs NPAPI plugins as separated processes and calls NPAPI functions by custom RPC interface (based on network sockets). Main drawback of the approach is that address space of browser/plugin is separated so nspluginwrapper does not support plug-in scripting, getting NPNVDOMWindow/NPNVDOMElement (by plugin) and some other.
In the process, of making plugins/addons and tabs as different process, I think it would also be interesting to ensure this processes have appropriated security level, if possible.
It's already stated in https://wiki.mozilla.org/Content_Processes#Goals
For Windows, it would use BIBA model introduces by Internet Explorer on Vista (bug 266533)
On Macosx, it would be the 10.5 sandboxing tools (bug 387248)
On Linux, it could be a good idea to provide some AppArmor/Selinux policies or something else to get good security (maybe related bug 319913 & bug 506693)
Else, it's a really promising evolution.
Some 'spare time' reading (if we are re-writing everything and want 'the Kitchen Sink'):
Obviously we would change / limit the functionality to suit our needs.
The above could assist with things like Firebug, Video / Audio / Flash Capture, ntop for Windows, Snort, and other Web Interface Programs, including this nightmare 'Audio on more than one Tab' https://bugzilla.mozilla.org/show_bug.cgi?id=334987 .
This bug has served it's tracking purpose and we're no longer using it.