2300 - Large table makes Gecko die

Status: VERIFIED WORKSFORME

(Core :: Layout: Tables, defect, P2)

Description

[saari (gone)]

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.

Comment 1

[leger]

Setting all current Open/Normal to M4.

Comment 2

[Paul MacQuiddy]

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

Comment 3

[karnaze (gone)]

Moving to M6

Comment 4

[karnaze (gone)]

Moving to M8

Comment 5

[Daniel Roberts]

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

Comment 6

[karnaze (gone)]

Moving to M9.

Comment 7

[Daniel Roberts]

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

Comment 8

[karnaze (gone)]

Moving to M11

Comment 9

[Daniel Bratell]

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

Comment 10

[karnaze (gone)]

Moving to M13.

Comment 11

[Daniel Roberts]

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?

Comment 12

[Matthew Tuck [:CodeMachine]]

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.

Comment 13

[Christine Hoffman]

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