Plugins must be out-of-process when content processes are enabled
Benjamin Smedberg
never really stated explicitly, is that all plugins must be run in a
plugin process, and cannot be run "in-process". This has the following
implications:
On Mac we will not be able to run plugins which use the Carbon event
model or quickdraw graphics model. This really only affect x86, not
x86-64, since none of these plugins were made for x86-64 and all new
plugins use the cocoa event model and newer graphics models.
On Linux, we will not be able to run plugins which use the xt drawing
model. We know of the following plugins which may still use it: the VLC
plugin, the (ancient) Acrobat plugin for Linux, and "602plugin.so" (I'm
not actually sure what this is). If these are considered important, we
could probably finish implementing OOPP support for Xt plugins, but my
hunch is these are so uncommon or old that we don't need to worry about
them.
On every platform, we will have to run Java out-of-process. Currently a
set of bugs related to bad behavior by the Java plugin (displaying modal
dialogs which block the event loop), and weird hangs involving window
messages, cause us to run the Java plugin in-process on all platforms.
Many of these hang issues will *probably* no longer be relevant when we
have separate chrome and content processes, but we cannot be sure of
this until it is implemented.
As a workaround, it will still be possible to turn off content
processes, and in this case it should still be possible to run plugins
as they do today. This workaround will probably be removed eventually,
but not any time soon.
--BDS
Mike Shaver
On Fri, Aug 26, 2011 at 11:47 AM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:
> One of the changes which is implied by content processes, but we've never
> really stated explicitly, is that all plugins must be run in a plugin
> process, and cannot be run "in-process".
I didn't see that implication coming. Why couldn't plugins run within
the hosting content processes?
Mike
Mike Hommey
> One of the changes which is implied by content processes, but we've
> never really stated explicitly, is that all plugins must be run in a
> following implications:
>
> On Mac we will not be able to run plugins which use the Carbon event
> model or quickdraw graphics model. This really only affect x86, not
> x86-64, since none of these plugins were made for x86-64 and all new
> plugins use the cocoa event model and newer graphics models.
>
> On Linux, we will not be able to run plugins which use the xt
> drawing model. We know of the following plugins which may still use
> it: the VLC plugin, the (ancient) Acrobat plugin for Linux, and
> "602plugin.so" (I'm not actually sure what this is). If these are
> considered important, we could probably finish implementing OOPP
> support for Xt plugins, but my hunch is these are so uncommon or old
> that we don't need to worry about them.
Apparently, the gxine plugin uses Xt, too.
Mike
Benjamin Smedberg
> [just to .platform]
>
> On Fri, Aug 26, 2011 at 11:47 AM, Benjamin Smedberg
> <benj...@smedbergs.us> wrote:
>> One of the changes which is implied by content processes, but we've never
>> really stated explicitly, is that all plugins must be run in a plugin
>> process, and cannot be run "in-process".
> the hosting content processes?
* We have identified multiple content processes as a requirement for
desktop Firefox (so that some content can be isolated from other content
causing big pauses)
* Plugins expect that they will not have multiple instances running
simultaneously (at least in Firefox)... many of them don't synchronize
on-disk data stores which can lead to all kinds of weird corruption.
In the next phase, there will also be the reason of having a security
sandbox on content processes which cannot be applied to most plugins.
For engineering reasons, I'd like to avoid trying to support plugins
loading in a content process: it will add significant complexity to code
which is already too complex: the asynchronous layer tree updates
combined with native widgets in another process would make the number of
testing codepaths huge.
BDS
Gervase Markham
> On Linux, we will not be able to run plugins which use the xt drawing
> model. We know of the following plugins which may still use it: the VLC
> plugin, the (ancient) Acrobat plugin for Linux, and "602plugin.so" (I'm
> not actually sure what this is).
Have we reached out to the developers of those plugins? (Not saying it's
your job... :-)
Gerv
Benjamin Smedberg
--BDS