289111 - Page causes Firefox to burn lots of CPU and hang for a while

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Morten Primdahl]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; da-DK; rv:1.7.6) Gecko/20050321 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; da-DK; rv:1.7.6) Gecko/20050321 Firefox/1.0.2

If you go to
http://www.ejerlejlighedssalg.dk/template/ejerlejlighed/case/searchresult.asp?CaseStatusID=14&CaseStatusID=13&CaseStatusID=15&CaseStatusID=17
using Firefox, the browser will hang while using lots of CPU. The HTML source
uses lots of tables and some unorthodox values for the colspan attribute which
may be the reason for the FF behaviour

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.ejerlejlighedssalg.dk/
2. Click the "Søgning" button
3. Click the "Aktuelle sager" button

Actual Results:  
Browser hangs spending lots of CPU

Expected Results:  
Render the page quickly

Comment 1

[Ben Fowler]

See
Bug 54542 "Large tables are slow"
Bug 226243 "Very slow loading of 2MB file with a quite big table with lots of 
colspans"
Bug 168157 "Mozilla frozen during rendering"
Bug 252421 "Very slow table rendering"
Bug 141572 "Large table with many forms eats CPU / takes too long to load"
Bug 97927 "large tabled page causes UI to hang for > 1 minute"
Bug 148338 "Hangs on very large HTML tables (50.000 rows / 26.mb 
data) (nsCellMap::GetDataAt)"

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this a regression, or did it never work well?

Comment 3

[John T]

Was this page being loaded with dialup or some sort of broadband? Using
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050402 on dialup, this
page loaded for me about as fast as any other page.

Comment 4

[Gabriel Chadwick]

This works for me using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050405 Firefox/1.0+

Comment 5

[Boris Zbarsky [:bzbarsky]]

Given that the bug was reported with 1.7 and that it's not there on trunk (just
tested, and no CPU spike here either), I'm willing to bet that one of bernd's
numerous table-performance patches over the last year fixed this.