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
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
Apparently, the gxine plugin uses Xt, too.
Mike
* 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
Have we reached out to the developers of those plugins? (Not saying it's
your job... :-)
Gerv
--BDS