Last Comment Bug 156493 - Browser should tolerate plug-in (plugin) malfunctions, like with a separate (own) process
: Browser should tolerate plug-in (plugin) malfunctions, like with a separate (...
Status: RESOLVED FIXED
[PL2:P1][Threading/Process]
: dataloss, meta, topembed-
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
: P3 major with 71 votes (vote)
: mozilla2.0
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 43106 59653 62460 176280 185839 187469 193429 196046 214596 220568 226843 242914 246484 250496 266653 270543 273602 280913 286717 290828 294327 320696 322997 325512 333424 334853 345642 350146 350820 351473 352995 358885 401809 403030 405206 448370 457950 460527 471327 486636 533866 538100 (view as bug list)
Depends on:
Blocks: 253117 advocacybugs 102474 grouper multicore
  Show dependency treegraph
 
Reported: 2002-07-09 10:53 PDT by rubydoo123
Modified: 2013-03-24 15:17 PDT (History)
128 users (show)
jst: blocking1.9.2-
shaver: blocking1.8.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description rubydoo123 2002-07-09 10:53:00 PDT
meta bug to track the separation of browser and plug-ins
Comment 1 rubydoo123 2002-07-09 10:54:38 PDT
*** Bug 62460 has been marked as a duplicate of this bug. ***
Comment 2 rubydoo123 2002-07-09 10:56:41 PDT
*** Bug 43106 has been marked as a duplicate of this bug. ***
Comment 3 rubydoo123 2002-07-18 12:29:47 PDT
*** Bug 59653 has been marked as a duplicate of this bug. ***
Comment 4 Tom Mraz 2002-08-03 10:03:56 PDT
This doesn't seem to be a truly meta-bug - there are no bugs this one depends on...
?
Comment 5 Christian Reis 2002-08-14 12:47:56 PDT
bug 58937 is related to this (though probably not blocked by it). beppe, had
time to look into this a bit more?
Comment 6 Marek Z. Jeziorek 2002-09-13 09:51:01 PDT
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Comment 7 saari (gone) 2002-10-14 15:48:04 PDT
Are we going to sign up for this? Beppe?
Comment 8 rubydoo123 2002-10-16 12:02:03 PDT
Not for a while, we need to do a lot more digging than what we have up to this
point. We also need to understand how this could work across platforms.

Moving to future until we better understand the impact
Comment 9 rubydoo123 2002-12-05 16:16:45 PST
The decision was to not do separate processing. Rather, at least on windows is
to follow the sub-classing work Andrei (169071). This bug remains open for Mac
and Linux work.

This would require extensive work from layout.

Removing topembed+
Comment 10 rubydoo123 2002-12-12 15:40:47 PST
reassign
Comment 11 Marc Bejarano 2002-12-16 17:26:30 PST
beppe: i'm not sure i understand bug 169071 and how that relates to this bug. 
would subclassing keep mozilla from crashing if, say, the quicktime plugin puked?

tia,
marc
Comment 12 rubydoo123 2002-12-17 09:03:18 PST
yes, that is exactly what it is supposed to do, the subclassing "wraps" the
plug-in as to insulate the browser application from bad calls, etc.
Comment 13 Peter Lubczynski 2002-12-17 11:03:00 PST
Structured exception handling with subclassing will only help crashes in the
window proc on Windows.

Since Quicktime usually crashes in another thread, that likely won't stop it
from bringing down the browser not to mention other plaforms.

This is a meta bug. There is lots of work that this would depend on, like
synchronization, plus lots of toolkit stuff to get the plugin to paint in the
browser and browser events to go to the plugin.

I was looking through the Windows Platform SDK lately and was wondering if
|SetUnhandledExceptionFilter| or |AddVectoredExceptionHandler| in XP would help
catch crashing in other threads?
Comment 14 Peter Lubczynski 2002-12-17 11:48:58 PST
*** Bug 185839 has been marked as a duplicate of this bug. ***
Comment 15 Matthias Versen [:Matti] 2003-01-02 10:16:09 PST
*** Bug 187469 has been marked as a duplicate of this bug. ***
Comment 16 Matthias Versen [:Matti] 2003-02-14 18:56:48 PST
*** Bug 193429 has been marked as a duplicate of this bug. ***
Comment 17 John Malmberg 2003-02-14 19:13:50 PST
A bug in a plug-in can crash the browser.

All calls to entry points to plug-ins should be set up with signal handler to
intercept errors and terminate the plug-in function instead of allowing the
entire browser to crash.

A diagnostic should be displayed when a plug-in hits a fatal error.

As part of the test procedure to verify the browser operation, a set of
plug-ins, one for each entry point that can be called should be made.  These
plug-ins should make an illegal memory access.  The browser should not crash.

There are many bug reports in Bugzilla about plug-in's crashing the browser, but
 the fixes seem to be concentrating on the specific plug-in, instead of fixing
the common vulnerability in the browser.
Comment 18 Francois Gouget 2003-02-14 21:28:38 PST
> All calls to entry points to plug-ins should be set up with signal handler
> to intercept errors and terminate the plug-in function instead of allowing
> the entire browser to crash.
[...]
> As part of the test procedure to verify the browser operation, a set of
> plug-ins, one for each entry point that can be called should be made.  These
> plug-ins should make an illegal memory access.  The browser should not crash.

This will not protect Mozilla from a plugin that incorrectly overwrites valid
browser memory. The only way to get real protection from flaky plugins is to run
them in a separate process and have robust handling of the interprocess
communication channel on Mozilla's side.
Just my 2c.
Comment 19 Matthias Versen [:Matti] 2003-03-05 10:38:27 PST
*** Bug 196046 has been marked as a duplicate of this bug. ***
Comment 20 Aleksander Adamowski 2003-08-11 01:24:26 PDT
*** Bug 214596 has been marked as a duplicate of this bug. ***
Comment 21 Marc Bejarano 2003-09-26 13:09:39 PDT
is anybody actively working on this?
Comment 22 Matthias Versen [:Matti] 2004-04-18 09:15:44 PDT
*** Bug 220568 has been marked as a duplicate of this bug. ***
Comment 23 Matthias Versen [:Matti] 2004-04-18 09:15:52 PDT
*** Bug 240852 has been marked as a duplicate of this bug. ***
Comment 24 Brian 'netdragon' Bober 2004-04-21 06:10:24 PDT
I mentioned in my bug that although Acroread isn't actually freezing, when you 
try to exit it, it brings up a dialog to the background asking you whether you 
want to exit. Therefore, it seems like it is freezing. Until you disable this 
dialog, you get the idea that Acroread is freezing Mozilla.
Comment 25 WD 2004-06-12 12:30:14 PDT
*** Bug 246484 has been marked as a duplicate of this bug. ***
Comment 26 Aleksander Adamowski 2004-06-30 07:52:54 PDT
Hopefully with the new plug-in interface (as announced here:
http://developers.slashdot.org/article.pl?sid=04/06/30/1258204) will not be
plagued by this issue.
Comment 27 Brian 'netdragon' Bober 2004-07-05 10:19:10 PDT
I again had an issue with this bug. This time it was java_vm bringing down. Bug
102474 depends on this, as mentioned in
http://bugzilla.mozilla.org/show_bug.cgi?id=102474#c14
Comment 28 Marc Bejarano 2004-07-16 12:47:14 PDT
re: comment #26, it looks to me like the new stuff is just a set of extensions
to the old API and doesn't enforce separation of browser and plug-ins.  we're
still going to be stuck with this plague...

i don't think there's anything about the current API that keeps one from
separating the browser from the plug-in.  it's just a lot of work that nobody
with the requisite skills seems willing to take on.
Comment 29 Olivier Cahagne 2004-11-17 23:26:49 PST
*** Bug 270543 has been marked as a duplicate of this bug. ***
Comment 30 Brian 'netdragon' Bober 2004-11-29 00:54:34 PST
See also bug 230017
Comment 31 Kevin Brosnan 2004-12-07 12:59:08 PST
*** Bug 273602 has been marked as a duplicate of this bug. ***
Comment 32 Tim Rørstrøm 2005-02-04 10:44:26 PST
*** Bug 280913 has been marked as a duplicate of this bug. ***
Comment 33 Nickolay_Ponomarev 2005-03-07 18:38:23 PST
*** Bug 266653 has been marked as a duplicate of this bug. ***
Comment 34 Matthias Versen [:Matti] 2005-04-18 13:30:12 PDT
*** Bug 290828 has been marked as a duplicate of this bug. ***
Comment 35 Braden 2005-05-09 14:52:51 PDT
*** Bug 176280 has been marked as a duplicate of this bug. ***
Comment 36 Braden 2005-05-09 14:54:37 PDT
This would seem to need bug 242530 in order to maintain scriptability in a
general way.
Comment 37 Matthias Versen [:Matti] 2005-05-16 04:33:57 PDT
*** Bug 294327 has been marked as a duplicate of this bug. ***
Comment 38 Kevin Brosnan 2005-07-14 11:39:12 PDT
*** Bug 226843 has been marked as a duplicate of this bug. ***
Comment 39 Kevin Brosnan 2005-07-14 12:20:49 PDT
*** Bug 242914 has been marked as a duplicate of this bug. ***
Comment 40 Mike Connor [:mconnor] 2006-01-05 14:14:08 PST
bumping to core noms
Comment 41 Daniel Mota Leite 2006-01-07 21:59:30 PST
maybe moving the plugin to a external process, its possible, as we can see with this layer for x86_64 firefox being able to run x86 plugins

http://www.gibix.net/projects/nspluginwrapper/

for now this "proxy" isnt gpl, but (i hope) it will be in the future
at least the idea seens a good one to change as little as possible the plugin interface but still enable the plugins to crash (and like nspluginwrapper, enable x86 plugins support to other platforms)

Comment 42 Ilya Konstantinov 2006-01-10 04:11:08 PST
> i don't think there's anything about the current API that keeps one from
separating the browser from the plug-in.  it's just a lot of work that nobody
with the requisite skills seems willing to take on.

Actually, through the current plugin API (unlike the Netscape 4 plugin API), you can get the Service Manager object, and from that, you can request a whole lot of possible XPCOM services. To replicate this environment in a separate process, we'll need bug 242520 fixed.
Comment 43 Braden 2006-01-10 08:05:30 PST
Bug 242530, you mean.

And yes, it's possible. I've done it on Linux. And RealPlayer does it on Linux, too, I believe. But doing it cross-platform with a scriptable plug-in is a whole lot of work without bug 242530.
Comment 44 Ilya Konstantinov 2006-01-10 08:29:21 PST
What is "possible"? You can declare that the service manager and the DOM are not accessible to the plugin -- and simply not offer that feature to plugins anymore. Most plugins, which aim for compatibility with the lowest common denominator -- Netscape 4, Konqueror, Opera -- might still work, as they don't rely on the Mozilla-specific plugin goodies.
Comment 45 Braden 2006-01-10 11:13:38 PST
Anything's possible. I could conceivably implement code such as would resolve bug 242530 in my plug-in. It would be a lot of work and no other plug-in would be able to see the benefit. So, better that go in the browser.

Resolving bug 242530 would give plug-in developers the tools to create out-of-process plug-ins. But once that code is in place, it also becomes possible to move the plug-in harness itself out-of-process, which means *any* plug-in could be run out-of-process.
Comment 46 Peter Weilbacher 2006-01-15 10:16:09 PST
*** Bug 320696 has been marked as a duplicate of this bug. ***
Comment 47 Jesse Ruderman 2006-04-10 06:36:36 PDT
*** Bug 333424 has been marked as a duplicate of this bug. ***
Comment 48 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-04-18 10:48:23 PDT
Not a blocker: too invasive for 1.8.1.
Comment 49 Justin Kerk 2006-04-20 13:12:58 PDT
*** Bug 334853 has been marked as a duplicate of this bug. ***
Comment 50 Derick Eisenhardt 2006-04-20 13:23:36 PDT
As a follow up to bug 334853, which has been marked as a dulicate...The attachment created during the crash seems to have been automatically deleted or something. Perhaps it has already been submitted to you somehow? But, I don't have it anymore.

Also, I've posted a related bug to the VLC developers if it is of any interest.
http://forum.videolan.org/viewtopic.php?p=61712
Comment 51 Frank Wein [:mcsmurf] 2006-05-02 14:16:41 PDT
*** Bug 325512 has been marked as a duplicate of this bug. ***
Comment 52 Justin Kerk 2006-05-02 15:22:59 PDT
*** Bug 250496 has been marked as a duplicate of this bug. ***
Comment 53 Wayne Mery (:wsmwk, NI for questions) 2006-05-08 11:19:47 PDT
where does bug 230017 fit in dependencies?
Comment 54 Sylvain Pasche 2006-05-08 11:36:26 PDT
(In reply to comment #53)
> where does bug 230017 fit in dependencies?
> 

But 230017 is about running plugins in another thread. It is a possible way to achieve the goal of this bug, but may not be a sufficient.
Comment 55 Marc Bejarano 2006-07-24 20:45:14 PDT
*** Bug 286717 has been marked as a duplicate of this bug. ***
Comment 56 :Ehsan Akhgari 2006-08-14 09:37:30 PDT
Does XPCOM support anything equivalent to M$ COM out-of-proc servers, where the COM servers run inside a separate process, and the transfer of data between the interfaces living in the two processes in handled by COM (a process known as marshaling)?

If yes, then maybe this can be used to solve this bug?
Comment 57 Braden 2006-08-14 16:20:26 PDT
It does not. That's what bug 242530 is about.
Comment 58 Henrik Skupin (:whimboo) 2006-09-07 12:53:13 PDT
*** Bug 350820 has been marked as a duplicate of this bug. ***
Comment 59 Henrik Skupin (:whimboo) 2006-09-07 12:54:54 PDT
*** Bug 351473 has been marked as a duplicate of this bug. ***
Comment 60 Henrik Skupin (:whimboo) 2006-09-07 12:57:06 PDT
*** Bug 345642 has been marked as a duplicate of this bug. ***
Comment 61 Henrik Skupin (:whimboo) 2006-09-07 12:58:36 PDT
*** Bug 350146 has been marked as a duplicate of this bug. ***
Comment 62 Henrik Skupin (:whimboo) 2006-09-16 13:41:31 PDT
*** Bug 352995 has been marked as a duplicate of this bug. ***
Comment 63 Matthias Versen [:Matti] 2006-10-31 17:19:36 PST
*** Bug 358885 has been marked as a duplicate of this bug. ***
Comment 64 Laszlo Mocsar 2006-12-03 17:19:08 PST
Don't know if it helps, but here are the Event Properties of a such Firefox crash on WinXP:

Faulting application firefox.exe, version 1.8.20061.1023, faulting module jpinscp.dll, version 5.0.60.5, fault address 0x00007f3a.

It's a java malfunction, always at the same address.
Can someone check it?
Comment 65 timeless 2006-12-04 06:18:28 PST
lmocsi@gmail.com: this bug has a summary, it should be clear that your comment is not appropriate for this bug. find or file a different bug.
Comment 66 Marc Bejarano 2007-06-06 10:53:36 PDT
*** Bug 322997 has been marked as a duplicate of this bug. ***
Comment 67 Enrico Weigelt 2007-06-28 06:13:17 PDT
Hi folks,

some time went by since anything happened here ...
I had a short look at nspluginwrapper. It's now under GPL and seems to compile
fine (not tested running it yet).

If it's stable, I dont see any valid reason not including it into mozilla and
replacing the current plugin loader by it.


BTW: for longer terms, using 9P2000 instead of the (not yet documented) 
socket protocol would make it more open and easier to handle. In the spirit
of Plan9 plugins so can rund virtually anywhere.


Comment 68 Sylvain Pasche 2007-06-28 08:26:03 PDT
(In reply to comment #67)
> I had a short look at nspluginwrapper. It's now under GPL and seems to compile
> fine (not tested running it yet).
> 
> If it's stable, I dont see any valid reason not including it into mozilla and
> replacing the current plugin loader by it.

GPL license is not compatible for inclusion inside Mozilla (see http://www.mozilla.org/MPL/mpl-faq.html). But the author could still relicense it.
Comment 69 Kevin Brosnan 2007-10-30 17:54:43 PDT
*** Bug 401809 has been marked as a duplicate of this bug. ***
Comment 70 timeless 2007-11-08 09:48:15 PST
*** Bug 403030 has been marked as a duplicate of this bug. ***
Comment 71 Matthias Versen [:Matti] 2007-11-24 08:18:24 PST
*** Bug 405206 has been marked as a duplicate of this bug. ***
Comment 72 Osma Ahvenlampi 2008-01-02 08:57:21 PST
A related data point: Apparently since forever, Shockwave Player has suffered from a bug which causes it to randomly stop processing events (freezing the UI, but not the process) on multi-core computers due to a mis-implemented monitor. It can be worked around by setting the CPU affinity of Firefox to just one core. Should out-of-process plugins be implemented, a white/blacklist of plugin quirks would also be useful...
Comment 73 timeless 2008-07-29 05:37:16 PDT
*** Bug 448370 has been marked as a duplicate of this bug. ***
Comment 74 Aaron Lawrence 2008-09-10 15:49:56 PDT
So, now Google Chrome is out and using a separate process for plugins. Not sure about IE8. This may become a hot topic.
Comment 75 Braden 2008-09-10 16:08:52 PDT
Plug-in scriptability no longer depends on XPCOM; so this doesn't need to depend on bug 242530 anymore. (Which is not to say that XPCOM-based IPC is the wrong solution; just that it isn't obviously the right one.)
Comment 76 Matthias Versen [:Matti] 2008-10-01 05:08:27 PDT
*** Bug 457950 has been marked as a duplicate of this bug. ***
Comment 77 L A Walsh 2008-10-01 12:33:10 PDT
I'm not sure this bug is the appropriate place to put "Bug 457950".  I wasn't so concerned with a plugin crashing the browser (though that is a concern), I was more concerned that a plugin (Adobe flash) running in one window, wants to use all of the CPU.  That's fine.  I have 4.  But in a separate window, I am still "automatically" limited to only running on the 1 used processor.  I have 3 unused processors that can be used to browse or whatever -- but because the one window that's running flash is using such a high level of CPU, Adobe Flash keeps emitting error messages that a "script" (the flash script, I guess) is hogging the CPU (it is -- it's playing a hi-def movie that's barely being kept in sync -- probably a poor implementation by nbc.com), but I want to allow it to have its own CPU -- and keep browsing in *other* cpu's.  

When a plugin is using 80% of 1 cpu (as in my bug), the adobe flash player detects the high Cpu usage and high latency and brings up warning messages.  There isn't a CPU crisis -- it's just 1 cpu that's busy.  Why can't those plugins get a separate thread ?  Maybe __at least__ allow other WINDOWS to use other CPU's -- That's the bug.  When firefox is already using 100% of one cpu, it still blocks another instance of firefox from starting to run on another cpu.  It forces all windows to the same cpu.  

Why not make access to the profile protected with 'locks' and/or shared memory to hold a common state?  

This is the biggest value of Googles new browser over Firefox -- you can bet MS will have IE be multithreaded, but I saw Google's browser release being a direct competition to Firefox because FF is limited to 1 thread.  They are both open source -- they can both converge to a similar feature set -- but Google's browser isn't based on mono-threaded code so it can expand.  FF is stuck.
I could easily upgrade my system to eight cores -- but what would be the point?  I can't even make due with 4 cores, yet I am very often CPU bound in 1 core due to Firefox's stuck implementation.

In fact -- I don't require that the browser stay up if a plugin crashes -- that's far less common of an occurrence for me.  What is common is that every day, every FF window and tab are run in a small quarter-sized compartment in my computer because FF is so poorly written.

Why was it written as single threaded in the first place?  Seems like poor design from the start.  By default, code should be re-entrant and only non reentrant by special exception or necessity.  This has been a problem since the beginning, yet it keeps getting put off to some vague nebulous future.

What's the problem -- as even IE will supposedly run on separate cores (not sure if that was referring to future or now)?

But if bug 457950 doesn't require the browser to "not crash" when a plug-in crashes, is it really the same bug as this one?
Comment 78 Anthony DiSante 2008-10-01 12:50:55 PDT
Google is doing the right thing with Chrome, by putting every tab/plugin in its own process.  And Microsoft is doing the same in IE8.  Hopefully the Firefox team will come to their senses and do the right thing here.  This bug is 6 years old, so clearly this kind of user feedback isn't especially important to the Firefox team; hopefully pressure from the competition will be treated a little more seriously.
Comment 79 JoSH Lehan 2008-10-01 22:02:47 PDT
It is my sincere hope that when Google Chrome is completely open-sourced for all operating systems, the Chrome and Firefox teams can come to an agreement.

Firefox 4.0 = Combining the best features of Firefox 3.x and Google Chrome!

Top of the list would have to be this bug.  You can tell a lot of people want this feature, because it's among the top things Google Chrome advertises as being improvements.
Comment 80 :Aryeh Gregor (working until September 2) 2008-10-02 16:30:50 PDT
(In reply to comment #77)
> I'm not sure this bug is the appropriate place to put "Bug 457950".  I wasn't
> so concerned with a plugin crashing the browser (though that is a concern), I
> was more concerned that a plugin (Adobe flash) running in one window, wants to
> use all of the CPU.

The issue is different from the user perspective, but the solution is identical: run plugins in their own process.  From a development perspective it's the same request.

Yes, you could solve your problem by using only threads, not processes, but that's unlikely to happen precisely because it doesn't solve the security problem, whereas using separate processes *would* help to solve the multicore utilization problem.

> There isn't a CPU crisis -- it's just 1 cpu that's busy.  Why can't those
> plugins get a separate thread ?

They can.  That's what this bug requests.  It will just take a considerable amount of development work.

FYI, this is not being ignored, IE8 and Chrome have gotten Mozilla talking about process-per-tab (and I guess -per-plugin too).  See some discussion here, at least on process-per-tab:

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/06b9aade0a0ee360/830bbe3487eb91ae

But I get the impression that it's going to take a lot of work to implement.
Comment 81 Matthias Versen [:Matti] 2008-10-17 15:41:15 PDT
*** Bug 460527 has been marked as a duplicate of this bug. ***
Comment 82 Matthias Versen [:Matti] 2008-12-28 08:04:55 PST
*** Bug 471327 has been marked as a duplicate of this bug. ***
Comment 83 Kevin Brosnan 2009-04-03 00:29:07 PDT
*** Bug 486636 has been marked as a duplicate of this bug. ***
Comment 84 Johnny Stenback (:jst, jst@mozilla.com) 2009-07-22 16:53:27 PDT
There's work underway to do this, but it won't be done for 1.9.2.
Comment 85 Worcester12345 2009-09-04 09:30:49 PDT
If you want, I can test it using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090903 SeaMonkey/2.0b2pre ID:20090903004335 if you give instructions.
Comment 86 Kevin Brosnan 2009-12-09 16:20:17 PST
*** Bug 533866 has been marked as a duplicate of this bug. ***
Comment 87 Jakub 'Livio' Rusinek 2009-12-10 08:31:47 PST
From what I noticed, nspluginwrapper installed by default even on non-64-bit, does this currently.

When Flash Player goes bye bye, Firefox is still working. Like in Opera, refresh is required to make it back.
Comment 88 Richard Neill 2009-12-10 15:43:09 PST
Ah. Therein lies the confusion. The problem for me isn't that flash crashes; it's that flash is running (and that background tabs don't suspend it). Consider several windows with perhaps 50 tabs. Each of them may have an instance of the flash player. The firefox CPU usage hits 100%, firefox slows to a crawl, and the OOM killer eventually clobbers firefox.
Comment 89 Aleksander Adamowski 2009-12-11 02:41:44 PST
Richard, you are introducing confusion into the matter. What you need in described situation is a flash blocking extension, like https://addons.mozilla.org/en-US/firefox/addon/433.

It will solve your problem completely.

This bug is about a significant architectural rework of Mozilla's browser plugin subsystem, regardless of whether we're talking about Flash, Java applets, or VRML renderers.
Comment 90 Kevin Brosnan 2010-01-05 23:26:45 PST
*** Bug 538100 has been marked as a duplicate of this bug. ***
Comment 91 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-01-13 13:25:33 PST
This bug is being worked on for a release that should come shortly after Firefox 3.6. That work is being tracked in bug 539055 / bug 531142.
Comment 92 Evengard 2010-02-01 12:55:45 PST
There is another problem with it...
Enabling the separate process for the plugins in the latest trunk cause the plugins to freeze...
They just begins to execute, but after some seconds they just won't react!
This behaviour is with Flash Player (with nspluginwrapper) and mplayer-mozilla... Probably others also...
Comment 93 Jo Hermans 2010-02-01 13:14:52 PST
Evengard, it's not even alpha quality yet - that's why it's only available in the 3.7a1pre builds (nightly builds). You're probably seeing bug 542263 or bug 543303.
Comment 94 Evengard 2010-02-01 14:01:26 PST
I don't think it is really those bugs, because turning it off the plugins works just fine...
Comment 95 timeless 2010-06-29 01:38:57 PDT
This was fixed with the release of Firefox 3.6.4.
Comment 96 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-06-29 09:28:07 PDT
To be clear, it's only partly fixed on Firefox 3.6.4:
 * only a specific list of plugins are out-of-process (silverlight, flash, and quicktime)
 * out-of-process support in 3.6.4 is only on Windows and Linux (not Mac)

However, on mozilla-central: 
 * all plugins are out-of-process
 * it works on Windows, Linux, and Mac

So based on the state on mozilla-central, the resolution in the previous comment that this bug is FIXED is correct, since bug resolutions reflect what's in mozilla-central.  The current situation on mozilla-central will hopefully be what ships in Firefox 4.
Comment 97 Marcelo 2010-07-01 15:10:07 PDT
I'm running Firefox 3.6.6 on Linux (Kubuntu 10.04 64 bits) and it still freezes when flash freezes. All windows must be terminated when flash freezes.
Comment 98 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-07-01 15:28:20 PDT
Is the flash plugin loading through some file other than libflashplayer.so ?  

Because only libflashplayer.so is whitelisted (see comment 96).  The whitelisting happens through the line:
pref("dom.ipc.plugins.enabled.libflashplayer.so", true);
in defaults/pref/firefox.js (which, on Ubuntu, is in /usr/lib/firefox-3.6.6).
Comment 99 Marcelo 2010-07-01 17:13:07 PDT
Thanks for the info, David. How do I verify that?
In about:plugins, I see:

Shockwave Flash
File: npwrapper.libflashplayer.so

Does this mean that the file through which flash is loaded is npwrapper, which is not whitelisted? Can I whitelist it? If yes, do I need to whitelist "npwrapper" or "npwrapper.libflashplayer.so"?

Thanks
Comment 100 timeless 2010-07-07 03:01:32 PDT
marcelo, and everyone else:
Bugzilla is *NOT* a support forum.

please do not ask questions in resolved bugs.

for support, please visit http://support.mozilla.com

fwiw, you would have to whitelist the entire filename, not just some random substring.
Comment 101 Marcelo 2010-07-07 10:00:24 PDT
timeless, the bug is not resolved for me in Firefox 3.6.6 and comment #96 says it should be starting in version 3.6.4. I'm trying to determine if the bug is indeed fixed or not.
I'm not asking general support questions.
Comment 102 Unknown W. Brackets 2010-07-09 20:12:39 PDT
Marcelo, the bug is fixed.  If there's a problem for you, it's most likely that the 64bit Linux installs which use a 32bit plugin wrapper for Flash are not whitelisted yet.

That smells strongly of a separate bug.  It may already exist, and it may really belong with Kubuntu/Ubuntu (which have packaged the flash plugin as such.)  If it's Mozilla's territory, and there's no bug yet, then you should probably file a new one depending on this or some such.

In any case, trying to determine how to use the about:config prefs for this is definitely support, so seems like that belongs where timeless said.

-[Unknown]
Comment 103 David Spector 2013-03-24 15:17:10 PDT
Bug 176280 was marked as a duplicate of this one (156493). For that reason, I'm reporting a new instance of that bug here. It's a bug where the Java fphover package causes infinite warning boxes.

I just experienced this problem again, many years after the previous report, when visiting www.chakraplein.nl/allin_taylor.htm. I am running Java 1.7.0 (the latest). Firefox 19.0.2, Windows XP Home SP3, computer otherwise running well. I have already also entered this info at bug 176280.

In my opinion, the problem should be fixed (in Mozilla) because it looks exactly like malware (a phishing attempt to get the user to click OK to gain access to install malware). If someone can replicate this report, I recommend it be fixed since it gives the appearance of being a serious bug (it isn't really a serious problem, but unsophisticated users may not realize that, because it makes the browser stop responding).

Note You need to log in before you can comment on or make changes to this bug.