Closed Bug 478976 (OOPP) Opened 15 years ago Closed 13 years ago
Electrolysis + plugins tracking
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.
Summary: Out of process tracking bug. → Tracking bug for out-of-process plugins
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? http://gwenole.beauchesne.info//en/projects/nspluginwrapper
do we want to add things like bug 348170 for possible test cases to check the implementation against? remove from dependency if not.
14 years ago
Depends on: 518924
Depends on: 519541
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.
Depends on: 521118
Depends on: 540935
Depends on: 542616
Depends on: 542915
Depends on: 543773
Depends on: 546797
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.
Depends on: 549888
Depends on: 552866
No longer depends on: 552866
14 years ago
Depends on: 543753
Some 'spare time' reading (if we are re-writing everything and want 'the Kitchen Sink'): Socket45 http://entropymine.com/jason/socket45/ NDISwrapper http://en.wikipedia.org/wiki/NDISwrapper GCC_Plugins http://gcc.gnu.org/wiki/GCC_Plugins 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 . Thanks, Rob
This bug has served it's tracking purpose and we're no longer using it.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.