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:
- The plugin-crash UI is not finished. The current UI is just a non-localized dialog so that we can get crash reports from nightly testers. This will be changed soon!
- On Windows, tearing/repainting issues when scrolling, bug 535295
- On Linux, compiz effects and Flash don’t work together on some systems, bug 535612
- On Windows, selecting “Print” option in Flash may lock up Firefox, bug 538918
- On Windows, hulu won’t switch to full-screen mode, bug 539658
- On Linux with GTK+-2.18 or later, GDK assertions and a fatal XError, bug 540197
- Firefox-process crashes at NPObjWrapper_NewResolve with silverlight and sometimes Flash, bug 542263
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.
If for some reason you need to disable multi-process plugins, set the pref dom.ipc.plugins.enabled to false.
January 27th, 2010 at 4:57 pm
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.
January 27th, 2010 at 5:01 pm
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
January 27th, 2010 at 5:55 pm
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?
January 27th, 2010 at 6:36 pm
Damnian, that sounds like https://bugzilla.mozilla.org/show_bug.cgi?id=539964. 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.
January 27th, 2010 at 6:58 pm
What’s the situation with Mac? Will OOPP happen there any time soon?
January 27th, 2010 at 7:20 pm
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.
January 27th, 2010 at 8:30 pm
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.
January 27th, 2010 at 8:34 pm
Great! Also, will this work across 32-64 and obsolete npviewer?
January 27th, 2010 at 9:50 pm
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).
January 27th, 2010 at 10:46 pm
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. :)
January 28th, 2010 at 2:50 am
“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.
January 28th, 2010 at 6:00 am
Also some strange interaction with Flashblock.
[Bug 542608] Audio No Video on flash sites
Phil
January 28th, 2010 at 10:33 am
Tobu, although crossing x86-64 and x86 is probably possible in the future, it is not currently implemented or planned.
January 28th, 2010 at 11:29 am
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!
January 30th, 2010 at 4:10 am
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.
January 30th, 2010 at 11:12 pm
Ben,
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.
February 2nd, 2010 at 6:50 pm
About the plugin-specific process naming: if using Windows, try replacing Task Manager with something better (Process Explorer, http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx).
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.
February 5th, 2010 at 12:29 pm
Ben,
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?
February 9th, 2010 at 5:56 am
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.
February 9th, 2010 at 5:15 pm
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.
February 17th, 2010 at 7:03 am
Now,
You have made Firefox very heavy. Now the Pre Alpha 2 Firefox 3.7 uses more memory than 3.6
February 17th, 2010 at 2:37 pm
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!
February 18th, 2010 at 6:58 pm
AFAIK there is a function called setproctitle (or alike) that can set visible process name to something much meaningfull like “AdobeFlashPlayer – youtube.com/movieNNN.swf”.
On Linux at least ;-)
Thank you and keep up the good work!
February 26th, 2010 at 9:08 pm
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. :)