http://www.spies.com/Usage/daily.html This is a 1497K page that is all table. Gekco tries to handle it on Win32 but dies quickly. On MacOS, it never displays anything. I'd call this a table stress test.

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Moving to M6

Moving to M8

This is a very interesting case. It hangs on Linux, too. I am interested in following this one, too.

Moving to M9.

I think the URL speaks for itself as a test case; all you need is a VERY large table like this.

Moving to M11

This doesn't crash my current build (1999-09-23) on Windows NT but the UI is very unresponsive while getting the page.

Moving to M13.

With a November 5th build on Linux, this page doesn't crash on me either, although I agree the UI responsiveness could be better. But that's a different issue, so I suggest we spin off a new bug for it. Would the original reporter like to have this honor? (Please put me on the cc list if you do.) Also, somebody else want to verify besides me, just to make sure that this is in fact somehow mysteriously fixed?

Might it be that the recent memory usage reductions have made this go away, but not fixed the problem? Maybe a bigger table might tickle the crash still.

Using 11/16 builds, verifying WORKSFORME regarding the application crashing. However, opened up a new bug #19008 to deal with the performance.