533866 - Flash plugin appears to run as part of the firefox process (so can't killall npviewer.bin)

Status: VERIFIED DUPLICATE of bug 156493

Description

[Richard Neill]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.9.2b4) Gecko/20091124 Firefox/3.6b4

It seems that the flash plugin now appears to run inside the firefox process, rather than as a separate process. In 3.0, when flash used to hog all my CPU,
I could "killall npviewer.bin". However, in 3.6b4, there is no separate flash process running to kill (even pstree shows firefox has no children). 

Flash is definitely running - I can hear 3 separate youtube tabs all fighting to be heard!

Workaround for now: remove the flash plugin from firefox, and use konqueror as a dedicated flash-browser.

Reproducible: Always

Actual Results:  
This makes firefox slow to a complete crawl, and crash within a few minutes.

Comment 2

[timeless]

so, you probably had a 64bit firefox and a 32bit flash plugin which the system managed by using a pluginwrapper (which is not a mozilla.org component). it sounds like your distro has upgraded you to 64bit flash. This isn't really our fault....

Comment 3

[Richard Neill]

Thanks - that explains the confusion. Normally, I use 64-bit firefox (with the 32-bit flash plugin). But I just downloaded the mozilla.org build of FX 3.6b4, which is 32-bit. Hence the npviewer.bin went away, and thus my confusion.

But seriously though, why should the flash plugin run inside firefox's process? That seems bad to me. If I click on a link for, say, a wmv file, it is opened in a new window by a separate player. Can't we do that with flash too?

Otherwise, embedded flash adverts can completely wreck firefox's stability.
It seems to me that the plugin wrapper is an improvement over a native configuration.

Comment 4

[timeless]

roughly speaking, it's much easier to implement plugins in process, that's how netscape created them, and that's how they were in netscape for hrm, 15+ years?

recently, opera, chrome, and now safari have moved plugins out of process, and we're in the process of doing so as well, which is covered by the bug to which yours is marked as a duplicate.

it's nontrivial work, sure it's better for stability, but... well...

put another way, the plugin wrapper you were using is buggy, i can point to a handful of crashes that are related to it. worse, the feedback when your wrapper died was so bad that people complained to us about it (otherwise i wouldn't even know it exists) - and it wasn't at all our fault! so, it's not just a matter of moving plugins out of process, it's handling all the cases to make things work well. -- that includes being able to send reports to the plugin vendors so that they can fix their bugs (which can be security vulnerabilities, so it's not like moving the plugins out of process means we don't have to care about them).