397829 - Firefox can't handle long web pages created by the TRAC SVN source viewer due to large number of tbodies

Status: RESOLVED INCOMPLETE

(Core :: Layout: Tables, defect)

Description

[uwestoehr]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

Open this page with Firefox 2: http://www.lyx.org/trac/changeset/20551

-> Firefox needs ages to display

Open the same page with Internet Explorer 6 or 7 and the page is quickly be displayed and you can scroll without problems.

Reproducible: Always

Steps to Reproduce:
- Open this page: http://www.lyx.org/trac/changeset/20551

Firefox needs minutes to display the page consuming 100% CPU memory.

- When the page is displayed, try to scroll -> Firefox needs again 100%CPU-pover and is dog slow.

Comment 1

[uwestoehr]

What about this bug? I mean Firefox hangs often for me due to this and I'm forced to Use IE instead. So at least this bug should be confirmed.

Comment 2

[earthsound]

This WFM in firefox 3. 

Even though it WFM, that page is 5,284.68 KB in size!

Comment 3

[uwestoehr]

This bug is still in Firefox 3. When the pages is opened it takes ages where Firefox consumes 100% CPU power freezing my whole OS.

When I open the same page with IE 6 or 7, I don't have this problem.

That the page is huge is no excuse, at I have enough RAM to cache it and that is what IE does successfully and therefore without freezing.

Comment 4

[Tyler Downer [He/Him]]

This is a mass search for Firefox General bugs filed against version 3.0 that are UNCO and have not been changed for 200 days.

Reporter, please update to Firefox 3.6.10 or alter. Firefox 3.0 is no longer supported and is no longer receiving updates. After you update, please create a fresh profile, http://support.mozilla.com/kb/managing+profiles, and test to see if your bug still exists. If you still the bug, then please post a comment with the version you tested against, and the problem. If the issue is no longer there, please set the RESOLUTION to  RESOLVED, WORKSFORME.

Comment 5

[uwestoehr]

> please update to Firefox 3.6.10 or alter

The bug persists!
I would mark this bug CONFIRMED but I don't have the permissions to do that.

It is annoying that nody has a look at this bug to confirm this but I'm from time to time asked to update bug reports.

Comment 6

[Tim (fmdeveloper)]

Still occurs with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 ID:20110420140830 and Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110618 Firefox/7.0a1 ID:20110618030732

After the page is downloaded it pegs the CPU at 99% while it starts to render.

Expected for a page this size or a confirmed bug?

Comment 7

[Matthias Versen [:Matti]]

I get no content at the moment with that URL

Comment 8

[uwestoehr]

lyx.org is currently a bit slow, but works. To reproduce the bug just wait until lyx.org sent the content to Firefox. When Firefox is starting the rendering, it needs 99% CPU for ages to display the page.

I now also tested this issue with IE 7 and don't get the problem. But with IE 8 also get the page rendered very quickly, but can afterwards no longer scroll. However, all IE versions are able to render the page quickly.

Comment 9

[Matthias Versen [:Matti]]

moving to layout and confirming with  Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110626 Firefox/7.0a1 SeaMonkey/2.4a1 but this could be just a bad page layout

Comment 10

[(mostly gone) XtC4UaLL [:xtc4uall]]

Attachment: WinDbg Log

Some Windbg Log (broke 2x into it) loading a locally saved Copy of the URL.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: zipped-up version of the web page

Can I ask for a favor?  If the page is hard to get and you already have a local copy... attach it to the bug?  ;)

Comment 12

[Boris Zbarsky [:bzbarsky]]

A profile shows that, not surprisingly, all the time is spent in table reflow.  Scrolling is fast due to the row cursor, as expected (this didn't exist back when the bug was filed).

In particular, the time is largely spent in cellmap operations.  55% of the time is spent in nsTableCellMap::GetEffectiveRowSpan and another 20% in nsTableCellMap::GetEffectiveColSpan.

The issue there, I suspect, is that this page has almost 3000 tbodies and the cellmap is just not very good at handling situations with lots of tbodies.  If I switch to only having one tbody, the load time drops from 100s to 10s for me.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Bug 363698 has some similar analysis and a partial patch.  I guess I'll try to find time to make that "work" insofar as anything works in table-land....

Comment 14

[Alin Ilea, Desktop Test Engineering]

Marking this as Resolved > Incomplete since the last activity on this issue was 10 years ago and it might not be relevant anymore. Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.