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.

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.

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

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.

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

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.

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

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