84466 - Page takes > 60s to render; many list elements are missing

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Drew Ronneberg]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; rv:0.9.1+)
Gecko/20010607
BuildID:    2001060706

This page will hang mozilla for greater than 60 seconds when rendering. There
are about 4 list elements per day. If you scroll down to January 22, 2001 (and
earlier dates), many of the list elements (links to stories) are not rendered.

Reproducible: Always
Steps to Reproduce:
1. go to web page
2.
3.

Actual Results:  Slow render time;  don't see links to many stories with dates
earlier than Jan 22, 2001

Expected Results:  Acceptible render time.  All links should be rendered

Comment 1

[Aaron Kaluszka]

The performance issue is a DUP I think.. the <li> is something else though..
Confirming Win2K/2001060620trunk
OS->All

Comment 2

[David Einstein]

Attachment: This demonstrates the problem

Comment 3

[David Einstein]

The HTML on this page is less than flawless.  If you remove all of the
unterminated <font size=+1> tags. the page appears to render correctly but still
not rapidly. I believe that adding some of the missing <UL> start tags would
probably help the loading speed, Mozilla is very confused.  Someone should tell
them to fix their HTML.

Comment 4

[David Einstein]

The problem with the badly rendered <li> elements is that after a certain point
CNavDTD::WillHandleStartTag gives up returning kHierarchyTooDeep (after it has
stacked 100 <font=+1><b> pairs.  Whether this is a good thing or a bad thing is
debateable.
The speed problem does seem to be probably a duplicate of bug 56854.
Someone should mark this bug NEW or DUP.
I have sent a note to Scientific American. Is there an evangelical boilerplate
somewhere? 

Comment 5

[Chris Petersen]

Confirming in the June 13th build. Several bullet items are missing text.

Comment 6

[Aaron Kaluszka]

*** Bug 87668 has been marked as a duplicate of this bug. ***

Comment 7

[Jens-Uwe]

From bug 87668:
enter the following in the URL bar after the page finished to render:
javascript:alert(document.documentElement.innerHTML.length);
and the browser answers you: 1472353

I heard this is the namber of bytes after parsing and converting back to HTML.
Since the original source code is only 100K long, this is IMHO way too much.

Comment 8

[Drew Ronneberg]

Just a updating note.  Mozilla (Build 2001092403) no longer loses list items. 
The  page does appear to render correctly but the performance is still very poor.

Comment 9

[R.K.Aa.]

There are several hundred links on the page - or more.
What remains of this bug is a dup of bug 77460.

Comment 10

[Jesse Ruderman]

Are you sure?  Bug 77460 happens on bug lists because the search sidebar 
recognizes bug lists as a search-results page and tries to reparse the page.  I 
doubt Mozilla comes with code for reparsing the sciam page.

Comment 11

[Diego Biurrun]

*** Bug 104627 has been marked as a duplicate of this bug. ***

Comment 12

[Diego Biurrun]

OS --> All as per duplicates on Linux. Adding 4xp keyword, Netscape 4.77 loads
the page in a flash.

Comment 13

[anthonyd]

not a table specific bug, reassigning to core owner.

Comment 14

[Kevin McCluskey (gone)]

Using 200112903 build on WINXP. The testcase loads, but is scrolls slower at the
bottom of the document (it scrolls very quickly near the top of the document).
The URL (http://www.scientificamerican.com/news) scrolls very slowly.  My guess
is the   code for painting alot of <LI>'s needs to be optimized or the badly
nested <LI>'s are defeating painting optimizations.

Comment 15

[basic]

this page is slow because of the way moz handles block elements (in this case
<ul>) that appear ilegally in <font> and <b> when in quirks mode. Moz insert
<font> and <b> elements in each <li> I think. Something is really wrong here.
Someone should take a good look at how the DOM tree of this page looks like in
DOM inspector and see what is going wrong with the code. There are lots of extra
<font> elements to say the least.

Comment 16

[Kevin McCluskey (gone)]

Moving to mozilla1.1. Engineers are overloaded!

Comment 17

[R.K.Aa.]

*** Bug 147713 has been marked as a duplicate of this bug. ***

Comment 18

[nemo]

Scientific American got rid of the old news page, put in a new searchable
layout!  Woohoo!
If this is considered symptomatic of a problem, and not just an Evang bug
misplaced, perhaps it ca be closed?

Comment 19

[nemo]

er.  if this is not a demonstration of a problem, but an evang bug...

Comment 20

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 21

[Diego Biurrun]

The page layout has changed, this is no longer a problem ---> WORKSFORME.

Comment 22

[Diego Biurrun]

The testcase still takes around 20 seconds to load, Opera loads it in a flash,
so I'd say the problem is still present, REOPENING.

Replaced http://www.scientificamerican.com/news in the URL for the testcase as
the site has changed its layout and now works fine.

Comment 23

[mmc]

The testcase runs in a flash for me (win XP).

Comment 24

[Drew Ronneberg]

It works for me too. I'll just close it as FIXED.

Comment 25

[José Jeria]

Shouldnt it be WORKSFORME?

Comment 26

[Jason Bassford]

Either WORKSFORME or moved to Evangelism.  I'll take the "easiest" of the two
paths, since nobody's been able to demonstrate what was wrong with the page or
what got fixed.

Comment 27

[Jason Bassford]

->WORKSFORME