240852 - All versions of mozilla for linux have horrible CPU starvation problems with flash and other plugins

Status: RESOLVED DUPLICATE of bug 230017

(Core Graveyard :: Plug-ins, defect)

Description

[elladan]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Galeon/1.3.13 (Debian package 1.3.13-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Galeon/1.3.13 (Debian package 1.3.13-2)

Mozilla's plugin architecture is fundamentally flawed, leading to numerous
horrible problems that show up especially badly on Linux.

In short, it's based on the idea of loading a third-party untested .so into
Mozilla's process space.  It then attempts to time-share rendering to this .so
internally, as well as sharing the X11 connection.  This results in plugins
which attempt to use a lot of CPU, such as animations (flash is the obvious
example) sucking up all of Mozilla's CPU, essentially freezing the browser.

The visible effect of this sort of thing is that the animation will continue,
but all Mozilla chrome and the web page fails to render, and Mozilla fails to
respond to any input or redraw events.  So, for example, you could open the page
referred to (www.nasa.gov) and then flip to another workspace.  When you flip
back, the NASA animation will be playing, but Mozilla will never render the UI
or the web page (if the web page had any content - nasa doesn't really). 
Sometimes, it will render the web page, but extremely slowly (as in, you can
actually watch it drawing pixels)

It actually gets worse.  Since the web browser isn't ever giving itself any CPU,
it can never respond to events from the plugin.  So, if you were to, say, click
on a link on the page, or in the plugin itself, the web browser will not
respond.  Basically, it appears completely frozen outside of the plugin, and
navigation on pages which contain flash is impossible.

This bug occurs CONTANTLY.  It has to be the most annoying problem with Mozilla
 (on Linux at least - the plugin model may clash less horribly with Windows) in
existence at the moment.

There are some workarounds, that are completely bizarre of course.

1. On some flash animations, it's possible to get a right click menu.  If you
select the option to zoom in or out, this may cause the plugin to pause briefly
and give the web browser time to respond.  You would think the play button would
let you just stop the animation, but usually it doesn't work.

2. Depending on the web browser UI you use, some aspects of the chrome may
respond in some situations.  For instance, the close tab buttons still work with
heavy delay in Galeon.  That is, if you can find them - they won't ever actually
draw.  When the flash page disappears, queued events such as navigation may be
issued.


A secondary problem with plugins is the fact that they make Mozilla trememdously
unstable.  Since they compiler/library versions they depend on are often
different from Mozilla's, they often crash or fail to even load.  Often a new
build of Mozilla will fail to start at all, and will typically not even give any
error message of any kind in this situation.  The only way I've found that's
effective in tracing these crashes is to either strace the binary and see what
it just opened, or delete all plugins and put them back one at a time.  This is
ridiculous.

Another side effect of this problem is that plugins, particularly flash, run
horrifically slowly.  An easy way to demonstrate this is to open several tabs on
www.newgrounds.com or the like, each with its own flash animation.  Even if the
animation isn't normally intense enough to starve the web browser, several of
them will be.  Now, just open a game on Newgrounds and examine the speed at
which flash renders - you'll quickly realize that in Mozilla, it goes in slow
motion, and goes slower the more tabs or windows there are!


The fundamental flaw here is that plugins should not execute as part of the
Mozilla process at all.  They should run inside of a sub process with its own
connection to the X server and communicate with Mozilla through IPC.  This way,
the Kernel's process scheduler could give them any needed amount of CPU, but
never enough to starve the web browser or other plugins.  In addition, Mozilla
should be able to easily catch erroneous IPC communications or a closed link, in
case the plugin crashes, which is very likely.  In addition, opening multiple
X11 connections will allow the X server itself to load balance, and will keep
the plugins and the browser from having to serialize.

The Konqueror web browser uses exactly this model, and its plugin support is
night and day compared to Mozilla.  Plugins never starve the CPU, the browser
never crashes due to them, it can load them at will without restarting safely,
they run MUCH faster, even if many of them run at once, etc.  In addition,
Konqueror has a plugin manager which allows to to locate plugins and change your
plugin paths, something Mozilla sorely needs.

Just to be clear here, the problem is not that the computer has insufficient
resources to render these pages.  It has plenty.  The problem is that Mozilla
cannot schedule and interlock with plugins in a fast or stable manner, and as
long as they run as part of the Mozilla process itself, this problem will
continue.  At best it might be mitigated with threading, but that would do
nothing to improve stability.

Reproducible: Always
Steps to Reproduce:
1. go to web page
2. notice the browser is frozen except for the flash animation
3. try clicking on stuff.  Notice it doesn't work.

Actual Results:  
Browser is cpu-starved and basically frozen

Expected Results:  
Browser should work fine and be responsive.  If the page contains exceptionally
cpu intensive plugins, it should still be fine and responsive, though perhaps
total responsiveness may be reduced when there's heavy CPU and graphics load.

Comment 1

[Theblueman]

I was able to repoduce by:
1. going to http://www.nasa.gov
2. Bring up an xterm window in front and move it around

In KDE Mozilla was frozen and X did not update the display for about 5-7 seconds.
In GNOME Mozilla froze and did not update X but only for about 2-4 seconds.

Comment 2

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 156493 ***

Comment 3

[elladan]

Bug 156493 makes no reference to CPU starvation issues, or the fact that this
bug causes the browser to because extremely sluggish or effectively hang about
once per hour on Linux.  That is not hyperbole, flash is that common.  Many
flash banner ads will trigger this bug and freeze the browser, making the
browser effectively randomly unstable when Flash is installed.

Note that in the CPU starvation case a plugin has done nothing wrong.  The
primary bug here is that Mozilla cannot tolerate a plug-in that does something
perfectly legal, such as use a lot of CPU while drawing its window.

Suggest you link the bugs some other way, since it's possible to fix the cpu
starvation issue with threads, even though it's a bad design.  It's not possible
to fix crashing with anything except a sub-process.

Comment 4

[Stefan Borggraefe]

*** Bug 231318 has been marked as a duplicate of this bug. ***

Comment 5

[Sanjay Pethe]

Hi,
I experienced Mozilla freezing up and hanging when I went to www.nasa.gov and
tried to go to the main NASA site from there (www.nasa.gov today is only a title
page with what appears to be a flash picture of Mars and links to several other
NASA sites). In short, I cannot visit the NASA sites at present using Mozilla
because of this hangup.

I am able to visit the sites using IE and Epiphany. Konqueror said I needed to
install flash and did not show it, though I could go the the next site.

This bug sounds as though it could be the cause of this, but I am not 100% sure.
Thanks.

Comment 6

[Sanjay Pethe]

PS - I am using Mozilla 1.6 on Fedora Linux build 2179.

Comment 7

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 230017 ***