Firefox developer preview brings out of process plugins

Mozilla has released Mozilla Developer Preview 3.7 alpha 2.

It’s necessary to first talk about the name. I think this is the first time Mozilla is using this kind of quirky name for a development release, which reflects it is still not clear what we have here or when we’ll have it. The main goal for this release is to test the out of process plugin (OOP) architecture that allows plugins to run on their own process, improving overall Firefox stability and security.

A few weeks ago, Mozilla announced OOP would come as a minor update (code named Lorentz) to the current 3.6 branch. This developer preview however comes from the trunk (Mozilla’s main development code repository) as OOP hasn’t being ported to the branch yet.

OOP is available only on Windows and Linux at this time and you can see it in action via Windows’ process manager where every running plugin is listed as mozilla-runtime.exe. For example the screenshot below shows Silverlight, Flash, and Foxit Reader running in three different processes. Also note that even as I’m playing two YouTube videos and have several PDFs opened at the same time only one process is created for each plugin. So yes, it means if a plugin instance  crashes, all instances do as well.

Windows system monitor showing out of process plugins behavior

Here’s how it looks when a plugin (Foxit Reader here) crashes. As you can see the rest of the page is there, as is Firefox. Just the plugin area is grayed out and you can click on a link to have the page reloaded.

FoxitReader plugin crash

As Mozilla’s Benjamin Smedberg explains, it is possible to force a frequently crashing plugin in process (along with Firefox code) by creating an advanced preference like dom.ipc.plugins.enabled.nppdf32.dll and setting it to false, replacing the last part with the appropriate plugin library name.

I hope this could happen automatically, so if Firefox detects a % of crashes above a certain threshold (say 30%) it will automatically set the preference and save users a headache or two.

Also worth noting in this release are the first steps of the big Windows theme update which looks very good so far.

Also the bugs that prevented correct tab preview from Windows 7 task bar on Firefox 3.6,  seem to be ironed and it works perfectly now.

However, these last two features will most likely come as part of Firefox 4.0 as planned.

13 thoughts on “Firefox developer preview brings out of process plugins”

  1. Hey is that additional memory that is used (the 60K+ instance), or would that just typically have been added to the total firefox.exe uses?

    Have you dived into (the early stages of) DirectWrite and Direct2D yet?
    http://weblogs.mozillazine.org/asa/archives/2010/02/direct2d_landed_in_f.html

  2. Great but… Toolbar buttons with borders??? It seems Mozilla designers like Windows 95 style.

  3. The extra memory is probably not much more at all — typically task managers present memory in an information poor way. That is, 60k might be what that process is taking up, if it were the only process running and if all the files it has open were read and forced into memory (as well as any other mapped memory). Anyway, the point is, adding another mozilla-runtime isn’t nearly as much overhead as you might guess from looking at task manager. And even having one isn’t much, since it probably shares a large footprint with the firefox process.

  4. if you called it flash-runtime.exe then stupid FF users would stop blaming memory leaks on you, FF!

    1. I agree, better if the process name is something like mozilla-plugin-PLUGINNAME.exe or firefox-plugin-PLUGINNAME.exe

  5. Calling the process mozilla-runtime.exe doesn’t seem that intuitive. What about the more descriptive mozilla-plugin.exe?

  6. [q]Also the bugs that prevented correct tab preview from Windows 7 task bar on Firefox 3.6, seem to be ironed and it works perfectly now.[/q]
    They seem to be ironed out but they are not. The preview works but the right click menu does not work. This means that you can’t maximize, move etc.

  7. Thanks Anonymous Cow.

    jrk
    “Toolbar buttons with borders???”
    What do you mean borders? The title bar close, minimize, etc buttons?

  8. Ken, by toolbar buttons I mean toolbar buttons. 🙂 Reload, home etc. No native app in Windows has borders around button icons (when you are not hovering over it).

    unfortunatelly, Firefox 4 mockups show Mozilla following Opera’s lead in developing exotic interfaces.

  9. Nice, that crashed plug in graphic is reminiscent of the “sad mac” one would get on old macs when something crashed.

    I’m still curious what kind of user testing, if any, is going in to the Firefox 4 user interface changes.

    Oh, and there’s nothing wrong with good old Windows 95: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8.1.23) Gecko/20090825 SeaMonkey/1.1.18

  10. I’m running FFox 3.7a4 pre. I too had 3 mozilla-runtime processes actively leaking memory.

    But it’s not the Shockwave plugin.

    It’s Macromedia Shockwave for Director Netscape v10.1.1.16 along with RealPlayer Version Plug-in 6.0.12.1348 and RealPlayer G2 LiveConnect-enabled Plug-in (32-bit) 6.0.11.2240.

    I disabled these 3 but let Shockwave alone and my memory usage is back under control.

Comments are closed.