Multi-Process Plugins on By Default

Out-of-process plugins (OOPP) are now on by default in mozilla-central! Starting tomorrow morning, the mozilla-central nightly builds will load Flash and all other plugins in a separate process by default (on Windows and Linux). The Electrolysis team would love for people to test any plugins on their system, especially less-popular plugins.

Since we are moving relatively quickly with multi-process plugins, there are a few known issues to be aware of:

If you discover crashes while running nightlies, please make sure you submit them, and check about:crashes for the crash ID and signature. We could use help making sure plugin-related crashes and instability are filed and tracked by searching for signatures here and filing bugs in the Core:Plug-Ins component.

If your browser hangs, you can probably recover by killing the mozilla-runtime process in the Windows task manager or via `kill` on Linux. If you are a developer with a debugger, please use the Mozilla symbol server and get stacks for both the Firefox process and the mozilla-runtime process and file a bug.

In some cases, it may be useful to the Electrolysis developers if you obtain a plugin log, which is a log of calls made between the plugin and the browser. Instructions for obtaining the log are available here.

I am very excited that we’ve made it this far, and I look forward to our next milestone release, which will backport these changes to the 1.9.2 release in preparation for Firefox Lorentz.

Flash in a separate process

If for some reason you need to disable multi-process plugins, set the pref dom.ipc.plugins.enabled to false.

Atom Feed for Comments 24 Responses to “Multi-Process Plugins on By Default”

  1. Damian Says:

    I’m a bit surprised by this to be honest.

    One of the biggest issues I have it performance when the plug-in / Firefox window isn’t focused. Watching the Daily Show in a corner from the screen I have to keep clicking on the window for the video to catch up as it’ll eventually slow down or stop when I’m using some other application.

    It actually got to the point where only last night I decided to turn multi-process plugins off.

  2. Damian Says:

    Oh sorry, that comment sounded a little negative. Otherwise it’s been a great experience! And it’s fun watching Flash crash and not affecting Firefox :D

  3. Stuart Says:

    Wondering if in the final version instead of saying mozilla-runtime.exe it’ll somehow say “Flash” or “Silverlight” or the name of the offending plugin?

  4. Kurt (supernova_00) Says:

    Damnian, that sounds like I know the title says with the mouse over the video but a few people have seen it when the mouse isn’t over the video.

  5. njn Says:

    What’s the situation with Mac? Will OOPP happen there any time soon?

  6. Benjamin Smedberg Says:

    njn, we don’t have any code for mac yet, and it will not happen soon. The differences in drawing and event model on mac are significant enough that it’s being treated as almost a separate project.

  7. Benjamin Smedberg Says:

    Stuart, as far as I know there is no way to fake the process name that appears in the Windows task manager, and we need to have the same binary for all plugins, so no, currently we don’t plan to change the name.

  8. Tobu Says:

    Great! Also, will this work across 32-64 and obsolete npviewer?

  9. Robert Kaiser Says:

    Congrats to the e10s team for achieving that milestone!

    I hope we’ll be able to enable it in builds that don’t have a libxul config as well, i.e. in shared or statically linked builds, as we in SeaMonkey are for now confined to that (even though work is now progressing to change that).

  10. geeknik Says:

    Then at least change it to firefox-plugin.exe or something that matches up with the firefox.exe. :) mozilla-runtime.exe isn’t very descriptive. If I wasn’t a nightly tester/contributor and I saw that running on someone’s machine, I’d probably kill it. :)

  11. Ferdinand Says:

    “Benjamin Smedberg Says: Stuart, as far as I know there is no way to fake the process name that appears in the Windows task manager, and we need to have the same binary for all plugins, so no, currently we don’t plan to change the name.”
    But it would be better if it was named “firefox-plugin”. I love the separate plugin process. Especially because a small youtube movie uses 52% of 1 cpu core. And this is on a 3Ghz Phenom quad core. Previously this meant Firefox was 50% slower and I had to resort to using a second Firefox to watch videos in. It is also interesting to see that flash uses almost 100MB when I have multiple flash sites open.

  12. Philip Chee Says:

    Also some strange interaction with Flashblock.
    [Bug 542608] Audio No Video on flash sites


  13. Benjamin Smedberg Says:

    Tobu, although crossing x86-64 and x86 is probably possible in the future, it is not currently implemented or planned.

  14. Stuart Says:

    I agree that something with “plugin” in the name is better than “runtime” but I do wonder if there’s a way to fake the name; having people think “flash is using 100% of my CPU and 500Mb of memory!” is much better than thinking that something to do with firefox is doing so. I think that it’d really help in the promotion of the open web if people started to have negative associations with some of the un-open plugins…

    Only idea I have for actually achieving it: create a miniscule stub .exe file that is nothing but a wrapper making a single function call into a dll that has all the real code in it. And then actually create a new copy of that miniscule exe for each plugin!

  15. Samuel Tardieu Says:

    I don’t use Windows and don’t know whether processes can set their names, but I agree with Stuart that if this is doable this would have a much better educational impact on users if they can tie CPU and memory consumption to a particular plugin. Maybe this would be a good question for StackOverflow.

  16. cuz84d Says:

    I wonder what would happen if we disabled the network prioritization code for OOPP? Any thoughts? I’m seeing behavior after reading the comments here to make it seem like Firefox browser is focused, taking all the CPU, when the plugin is focused it taking all the CPU.. but they don’t work concurrent when IPC is enabled?

    Just a food for though.

  17. Matt Shoffner Says:

    About the plugin-specific process naming: if using Windows, try replacing Task Manager with something better (Process Explorer,

    Within Process Explorer, click ‘View’-> ‘Select Columns…’ -> make sure ‘Command Line’ box is checked.

    There’ll now be a ‘Command Line’ column from which one can determine the plug-in being used with each instance of mozilla-runtime.exe.

    Ex. “C:\Program Files\Minefield\mozilla-runtime.exe” –channel=5532.5b54c20.783371504 “C:\Windows\system32\Macromed\Flash\NPSWF32.dll” 5532 plugin \\.\pipe\gecko-crash-server-pipe.5532

    Admittedly not the cleanest but at least you’ll know which process to kill off.

  18. mr.troll Says:

    now the ff3.7 with mozilla-runtime almost always hangs, when the page is using swfobject.js for flash insertion. Will this bug be fixed in future?

  19. Giles Says:

    First things first — thanks for working on this excellent feature!

    Now on to the problem… I was finding that when Minefield opened up (with my previous 20-tab session ready-loaded), it was completely unresponsive; it appeared to be “live” — that is, the cursor switched to an I-beam when it was over text and an arrow when over the tabs — but clicking did nothing. I’ve done some digging, by starting 3.6, closing one of my tabs, exiting, restarting Minefield, checking for the problem, rinse and repeat, to see if there was a particular tab that was causing the problem. It looks like it’s happening when I have a PDF (displayed in the tab with Acrobat) and one other tab, the non-PDF one being active. Control-tabbing to the PDF tab seemed to unlock things briefly, but clicking back to the non-PDF tab from there seemed to break things more completely leaving the browser unresponsive. If I were to guess what’s happening, it would be that the Acrobat plugin is stealing the mouse events even when it’s not visible. Switching dom.ipc.plugins.enabled to false seems to fix the problem.

    I’m happy to file this in Bugzilla — let me know if you’d like me to — but I’m not sure of the best way to characterise it there.

    Cheers, and thanks again for what promises to be a great feature.

  20. Sahab Yazdani Says:

    I don’t think you want programs to be able to modify their name in the Windows Task Manager (or Sysinternals Proc Exp). It makes all that much easier for malware to masquerade as legitimate applications. Imagine one of those trojan horses saying its name is “outlook.exe” or something else that usually perpetually runs on a user’s machine. At first glance they seem legitimate and become really hard to clean-up.

  21. Chris Thomas Says:


    You have made Firefox very heavy. Now the Pre Alpha 2 Firefox 3.7 uses more memory than 3.6

  22. Benjamin Smedberg Says:

    Chris, how are you measuring? Our automated tests indicate that if you measure properly (don’t count shared memory twice) we’re actually using *less* memory than we were before. If you have a particular testcase that shows unexpected ballooning memory usage in one or the other process, please file it!

  23. Szycha Says:

    AFAIK there is a function called setproctitle (or alike) that can set visible process name to something much meaningfull like “AdobeFlashPlayer –”.

    On Linux at least ;-)

    Thank you and keep up the good work!

  24. Oskar Says:

    Why is Firefox with OOPP using more memory than 3.6?
    I can see in task manager that Firefox 3.7a2pre is using more memory than Firefox 3.6
    I hope that this memory “problem” can be fixed to use less memory.
    Keep doing good work. :)

Leave a Reply