Comment 96 for bug 226470

Ok, Howard, sounds like a legitimate case of this bug. The reason that CPU usage or memory usage (and swapping) are critical is that to redraw *any* previously drawn window or tab requires destroying the previous window and all of the objects within it (this includes javascripts, GDK/GTK/GLIB "window object" structures, etc.) It is very complex, and therefore time consuming. It is also difficult to debug because the "destroy" (and memory deallocation) processes are usually not explicit in the code but are linked into the data structures and may be called in some very strange situations.

In a "light load" situation, window destructions will tend to run to completion in one operation (with no interference). In heavy load situations, particularly if large amounts of the heap are paged out, a delete operation may be suspended (freeing heap memory amy require scanning through much of a highly fragmented heap to find out how to insert the freed memory back into the free memory list). Window operations (window or sub-window "redraws") can also occur asynchronously -- through either HTTP, e.g.
  <meta http-equiv="REFRESH" content="#-seconds-delay">
or Javascript, using the setTimeout() functions and window.location.reload(true) when the timeout expires. Google mail may also use something similar to update the screen when ones remote mailbox content has changed.

It *would* be useful to know what URLs you have open when you see this happening as well as whether you think there are pages that happen to be doing some type of "auto-refresh". If you don't know all the pages, and you don't have privacy concerns send me your sessionstore.js file and I'll turn it into a list of URLs and try to track down the offending URLs.

It isn't that the URLs are really doing anything wrong -- it is that the Firefox/Seamonkey/GDK/GTK/GLIB code is allowing actions (e.g. derivatives of window refresh/redraw) to be added to the window event queue while it is in the process of being deleted.

I suspect there is no test case in Mozilla for a set of windows which attempts to bury the machine (e.g. 100% CPU and/or Swap usage based on nothing more than window refresh/redraw requests). If there were we probably would have resolved this bug long ago.

My statements still stand that there is a second, probably unrelated bug involving excessive CPU usage (I suspect this is due to poor management of "inactive" windows but haven't begun to investigate it yet). For example, I suspect a few hundred windows monitoring a few hundred active RSS feeds would drag the machine into the ground -- but it would not do so if the X utilization of visible vs. non-visible windows were managed properly.