Firefox, Safe From Plugin Crashes
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.
Common Questions
- 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.
Preferences
Multi-process plugin behavior can be controlled from preferences:
- dom.ipc.plugins.enabled.filename
- 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.
March 4th, 2010 at 5:52 pm
“Why don’t you reload the plugin automatically?”
I agree with the conclusion, but you missed a reason – it’s actually the same reason we don’t allow clusters to reboot failed nodes automatically.
If something in the web page causes the plug-in to crash onload, you may very well wind up executing for (;coredump;); — which might very well yield to machine usability problems, or a full disk if the crashes start when the user is not around to manually close the browser.
March 4th, 2010 at 6:33 pm
Could the process executable be renamed to something more descriptive like firefox-plugin? For the average user, I suspect mozilla-runtime doesn’t make it as clear what the process is actually doing.
March 5th, 2010 at 4:29 pm
[…] you want to know more about it, have a look at this post by Ben Smedberg who goes over how it works, what prefs you can set and how you can help test it. It would help us a […]
March 21st, 2010 at 8:28 am
What happens if the plugin deadlocks, rather than crashes? Does Fx
have a way to handle plugin processes which no longer seem to be
responding?
May 4th, 2010 at 2:07 pm
Hi,
I’m the main developer of Lightspark, a modern open-source flash payer implementation. As my plugin is not yet stable enough to be crashfree I’d like to support out of process execution for it. Everything seems to work, besides event handling. I’m using Xt to register an event handler and this runs fine in-process, but causes the plugin container to crash when run out-of-process. What would be the right way to do event handling in this context?
May 11th, 2010 at 11:33 pm
Alessandro, Mozilla currently has not implemented the old-style Xt embedding mechanism out-of-process. We strongly encourage you to update to the newer xembed mechanism, but we are going to implement the Xt backend in Firefox 4 for compatibility with the rest of the Linux plugins.