Today we released the first Mozilla Developer Preview containing multi-process plugins. Firefox is now safe from plugin crashes, on Windows and Linux.
Where Do I Get It?
How Can I Help?
Warning: the developer preview is alpha-quality and may contain bugs. If you are willing to browse on the wild side, please download and use the preview build as your day-to-day browser. Visit web pages which use plugins. We have done a fair bit of testing with the most popular plugins such as Flash and Silverlight, but there are many less popular plugins which may not be tested at all. If you don’t know what plugins are installed, go to Tools / Add-Ons / Plugins.
If you encounter any crashes, please make sure you submit the crash reporter and try to provide a detailed comment about what you were doing at the time of the crash.
If you encounter any unexpected behavior, please file a bug, including the following information:
- The website you were visiting
- Plugin information copied from about:plugins
- Expected and actual behavior
- Whether the behavior is fixed when you change the IPC preference (see below).
How Does It Work?
The Mozilla Developer Center has an article describing the underlying architecture: there is a shim layer which acts like a plugin in the browser process and a browser in the plugin process. Function calls are translated into RPC messages passed between the two processes.
One of the key pieces of technology we’ve developed to make message passing more reliable is IPDL. IPDL is a language which precisely describes the messages that can be passed between processes, and allows developers to define a state machine and error handling conditions for messages and resources shared across processes. IPDL layers on top of an IPC stack that Mozilla copied from the Chromium codebase. For instance, this protocol describes the messages associated with a plugin instance on a web page. Each message may be delivered asynchronously, synchronously, or with RPC semantics.
- What happens when a plugin crashes?
- When a plugin crashes, the Mozilla crash reporter kicks in and submits the crash report to Mozilla. Then we replace the plugin display with the crashed-plugin UI. When you reload the page, we restart the plugin process.
- Why don’t you reload the plugin automatically?
- We thought about this: however, web page scripts often have state associated with a plugin. If we reload the plugin without reloading the entire page, those scripts will have unexpected state and can get very confused. Overall, it causes fewer problems for the user to simply refresh the page.
- What’s the name of the plugin process?
- The name of the plugin process in the Windows task manager is mozilla-runtime.exe (mozilla-runtime on Linux).
- Why is mozilla-runtime using so much memory?
- In general, our automated tests show that Mozilla actually uses less overall memory than it did previously. However, there are some measurement issues which may cause problems: memory which is shared between the two processes, such as mapped memory segments and code, may be counted twice. The Chromium project has had similar problems accurately measuring and presenting memory usage information. If there are particular pages or plugins which show a regression in memory usage, please file a bug!
- What about Mac?
- MacOS presents some unique challenges: the traditional drawing and interaction model for plugins is very difficult to do across processes. We are working on Mac support for multi-process plugins, and hope to have a preview of this work available soon.
Multi-process plugin behavior can be controlled from preferences:
- Each plugin can be controlled independently. For example, if Acrobat is causing problems, you can run it in-process by setting the pref dom.ipc.plugins.enabled.nppdf32.dll to false. The filename should be lower-case.
- dom.ipc.plugins.enabled (true)
- This controls the multi-process behavior for all plugins which don’t have a specific pref set as above.
After these preferences are changed the browser must be restarted.