Firefox crashes rendering large html table (20,000+ rows)

Question

I understand that rendering a table this large is pushing the limits of any browser. However, I was curious as to why a table that is significantly large (20,000+ rows) crashes Firefox, while all other browsers render it relatively quickly.

I am using ASP.NET and writing the table html directly to the buffer with Response.Write. I initially thought that maybe I was generating some malformed html so I decided to recreate the table with a gridview. This proved to slow down Firefox even more, but had only a slightly slower render time in other major browsers.

Firefox creates the first (approximately) 10,000 rows just fine. The problem is after that, it very slowly adds the remaining rows until the application becomes unresponsive, while using an increasing amount of memory (300MB+). Internet Explorer only uses about 30MB.

I am using the most current version of Firefox and all of my add-ons are disabled while testing. Also, I removed all css and javascript from the page.

Is this a known problem with firefox? Has anyone else experienced this? What steps can be done to fix the problem or at least start troubleshooting?

EDIT I know having this many table rows on a page is a horrible UI design practice. Thanks for everyone who pointed this out, but that wasn't my question. To further clarify I was just curious as to why this works in all browsers except Firefox.

Answer 1

You might want to use pagination to sort that out :) I imagine my poor old laptop would die if Firefox tried to render 20k rows of tables. And it is a core2 with 4gb ram :P

Answer 2

try defining the table with a fixed width

<table style='table-layout:fixed'>

This will allow the browser to render the table without it trying to recompute the width on each new row addition.

[UPDATE]

I am not sure what your data looks like but I can do

<table style='table-layout:fixed'>
<tr><td style="width:150px;"></td><td style="width:150px;"></td><td style="width:150px;"></td><td style="width:150px;"></td><td style="width:150px;"></td></tr>
<%
    for (int ix = 0; ix < 30000; ix++)
    {
        Response.Write("<tr>");
        Response.Write("<td><img src='stickman1.bmp'></td>");
        Response.Write("<td>" + RandomString() + "</td>");
        Response.Write("<td><img src='stickman2.bmp'></td>");
        Response.Write("<td>" + RandomString() + "</td>");
        Response.Write("<td><img src='stickman3.bmp'></td>");
        Response.Write("<td><a href='#' onclick='blah();'>stick man!</a></td>");
        Response.Write("</tr>");
    }

 %>
 </table>

within Firefox 3.0.11. Although it takes awhile firefox will display it. It consumed 239MB of ram. RandomString() just returns a string of between 0 - 22 characters.

Answer 3

EDIT: Going by what you've revealed in your comments I'd suggest the issue is more likely to be with your data than with the table. You'll have to perform some tests using different data, elements and layout techniques to establish where the issue is. I'd especially look for:

• object, iframe or native elements (including form elements).
• duplicate id attributes
• unescaped entities
• tags in the data stream, especially </td>, </tr> and </table>
• colspans

hmmm.. seems like an indication you aren't using valid html (not closing rows or something). Run a subset of your table through a validator.

table-layout:fixed (per Jack's answer) should be rendering up until it crashes. It seems like it doesn't know something about the table in advance (like its width). Try setting width to a pixel value and use col elements.

<table style='table-layout:fixed; width:800px'>
  <col style="width:200px">
  <col style="width:600px">
  <tr>
     ...

Answer 4

Is it possibly something to do with your data? I just whipped up a simple ASP.NET page that creates a 50k row table and firefox renders it just fine.

protected void Page_Load(object sender, EventArgs e)
{
    StringBuilder sb = new StringBuilder();
    sb.Append("<table><tbody>");
    for (int i = 0; i < 50000; i++)
    {
        sb.Append("<tr><td>My Name</td><td>[email protected]</td></tr>");
    }
    sb.Append("</tbody></table>");
    Response.Write(sb.ToString());
}

Answer 5

I would suggest using Pagination for a dataset that size. ExtJS has a very nice GridPanel, which is easy to implement (you can look at the source code of the examples for guidance), and if you want something not so "extreme" (as in, it doesn't change the look-and-feel of the table), jQuery has some AJAX Pagination stuff as well.

Answer 6

Another thought

How long does the information take to send? Is it buffered on the server-side? Could be to do with firefox's connection handling rather than rendering.

Answer 7

I think a big part of the problem is that Firefox (at least previous versions, this may have been fixed by the time this message gets read) tends to use a lot of memory all by itself even when nothing major is happening.

Loading a huge amount of data would mean it requires even more memory and CPU resources than it normally does, and it normally demands quite a lot from the system. So if the amount of data was enormous, it could use the whole resources and Firefox is polite enough to give up rather than crash the computer.

I would guess the performance would vary if you try this on a very low-end system versus a high-end system with lots of memory and fast CPU.

Of course it also depends what you mean by crash. The precise meaning of crash is that it stops working and quits, whereas you could be talking about it just hanging (it stops working but does not quit) in which case it is possible that it is still working but struggling to render the page before you lose patience.

If you manually close Firefox before the page is rendered, it does not technically count as a crash, simply a hang or that the user has not been patient enough to wait for the page to load (of course there is a limit to anyone's patience!).

Answer 8

I have the same issue. Basically Firefox scrolls very slow when the table is shown (30 rows and about 50 columns). As soon as the table is not visible anymore, the browser scrolls fast again. So I guess it is a display rendering or update problem.