Comment 107 for bug 226470

Getting back on topic (firefox/mozilla heap memory usage is a separate problem from the untitled window problem) [1].

This comment is to confirm that in Epiphany (with has no NoScript option so Javascript is enabled), even somewhat moderate browser usage (VirMem ~735 MiB ResMem ~481 MiB) can trigger rather frequent untitled windows if one subjects the CPU to even moderate non-browser loads. The two specific URLs are the NY Times home page [2]) and a recent CNN news article [3]. I suspect both of these sites, like many news sites, are on auto HTML refresh and/or Javascript managed page reloads, e.g. "window.location.reload(true)" or some equivalent. They seem to trigger page reloads (and popup/refresh the untitled windows) at least once an hour [4].

Someone who is skilled in HTML/Javascript needs to write a test program [5] which attempts to swamp the CPU (and/or network) with page reloads (increasingly shorter times between page reload requests should do it). Open up a couple of hundred pages (tabs) with refreshes every 1-5 seconds and I'm reasonably sure the problem will reveal itself. I would hazard a guess that this type of stress testing of various asynchronous browser features on various operating systems has not been done.

I would note that given my limited investigation of the window redraw (delete + draw) code thus far I do not believe a patch involving suspending or producing errors on window operations during a destroy window would be that difficult (and it could be applied back to version 2.0.0.X as part of the ongoing security upgrades). But it should be developed by someone who really understands how the code works and not by someone like me.

1. I'm sure there are more than a few bugs active regarding Firefox memory usage (I filed a few myself). If anyone runs across them, they may want to post the references to them here and to this topic in the most closely related. There is a relation between these bugs because as Firefox is used for long periods of time extensive numbers of window management data structures are allocated by gtk/gdk/glib causing heap fragmentation. The more fragmented the heap is the more CPU time (and paging) will be required to execute a "Delete Window" operation and the more likely an asynchronous operation on the window will be triggered during the deletion operation (thus leading to the window unexpectedly destroyed error).
2. http://www.nytimes.com/
3. http://politicalticker.blogs.cnn.com/2007/08/04/tancredo-bomb-muslim-holy-sites-first/
4. I am unsure whether Epiphany is using the same window management code as is found in the mozilla sources or simply code which involves similar gdk/gtk/glib functions for the reload/redraw window operations. This may open the question as to whether this is a Mozilla problem or a system library problem -- it ultimately revolves around what operations should be permitted on windows slated for destruction and whether the application or the libraries should manage that.
5. I'm not going to reread all of the comments on this bug but I think I may have encouraged/suggested this in my comments 2 months ago (June '07).