122976 - page takes 100% CPU and never finishes loading

Status: RESOLVED DUPLICATE of bug 81993

(Core :: Layout, defect, P2)

Description

[Vinay Badami]

http://www.wkap.nl/prod/s/IFIP

takes 100% CPU and never finishes loading.
IE behaves well.

Under the debugger whenever i break, it seems to be doing a reflow.
I got to this bug since this was reported under bug 120012.

I do not believe that this has anything to do with networking but is reflow related.

Comment 1

[Karl Johan Kleist]

Reporter:

- Please always specify which "Build ID" you're using.
- Use severity level "critical" when Mozilla hangs.
- Please also add the keyword "hang".

I can reproduce this, using 2001 01 30 03 with Windows 2000.
Mozilla sucks cpu, and eats memory at a rate of c:a 50 kB per second.

Comment 2

[Vinay Badami]

Using a local build of the tip - maybe a couple of days old.

Comment 3

[Sitsofe Wheeler]

I see this problem too - Linux 20020201. 100% cpu is chewed up and the page
looks like it will be displayed but then a reflow occurs and only scrolling down
shows up the rest of the page.

The page is displayed without problem in Konqueror.

As a side note, the page seems to contain an invalid utf-8 character in it and
the HTML is absoloutely dreadful...

Comment 4

[Kevin McCluskey (gone)]

Don, please try loading the URL in the bug after you have fixed the image tiling
performance bug. 

Comment 5

[Vinay Badami]

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

Comment 6

[Kevin McCluskey (gone)]

Page does not hang on WinXP using build 2002020512 and it completely loads. It
is slow to load, and it is slow scrolling after it loads.

Removing hang keyword. Added perf keyword. Moved to Moz1.1

Comment 7

[Markus Hübner]

this seems to be related to bug 124178 (there also win-xp hangs!)

Comment 8

[dcone (gone)]

Once I get this loaded.. which is a pain.. it updates just fine.  I think the
background tile/scrolling part of this is fixed.  I am reassigning back to kevin
so he can dup or triage it to the loading person.. or a DHTML person.  I also
think this is related to or a dup of bug 124178.

Comment 9

[Kevin McCluskey (gone)]

Bulk moving Mozilla1.1 bugs to future-P2. I will pull from this list when
scheduling post Mozilla1.0 work.

Comment 10

[Markus Hübner]

The page doesn't stop loading on build 2002030604 in win-xp

Comment 11

[Markus Hübner]

Using build 2002041903 on win-xp,1.1ghz,512ram this page really hogs the cpu.
Looks like it will be displayed but then a reflow occurs and only scrolling 
down shows up the rest of the page. Changed via Taskmanager to another 
application but never was able to get back. Had to kill via Taskmanager.

Comment 12

[Sitsofe Wheeler]

OS->All

Comment 13

[José Jeria]

URL does not seem to be available anymore.

Comment 14

[Markus Hübner]

tested this today - same as in comment #11.
using trunk build 2002081612.

Comment 15

[John Christopher Jones]

I believe this is the same bug as can be observed at http://blog.mynx.com ...
it's currently moving to http://www.mynx.com as I write this, and that will be
the new address.

http://www.wkap.nl/prod/s/IFIP demonstrates a far more aggressive behavior.

http://www.mynx.com uses MovableType, PHP, CSS, and a mixture of XHTML (layout)
and HTML 3.2 (inserted blog content).  Changing the DOCTYPE does not appear to
have any effect.

The most suspicious thing besides the DOCTYPE is how the background is assembled.

html { background: url('images/bg.jpeg') top left repeat-y }
body { background: url('images/top.jpeg') top left no-repeat }

bg.jpeg is a 1x1600 jpeg, or there abouts.

Comment 16

[Kurt Weinschenker]

Hmmm.  Checked the two sites in comment #15 under Mac OS 9.2.2 with Mozilla
trunk build 2002103008.   mynx.com loaded without problems. 
http://www.wkap.nl/prod/s/IFIP , billed as demonstrating 'far more aggessive
behavior' took several minutes to load, but did not, repeat not, hang Mozilla.

I could leave Mozilla for the finder without hassle.  Over a dial-up connection,
I could see where someone might think Mozilla was hanging, though.

Comment 17

[Carine Held]

Reproduced in 1/08/03 Trunk build for Linux. The page in the URl did take
several minutes to load, but never totally hangs and does finish loading
eventually. This is a combination of a slow server and a weird graphic.  I think
there is a very tiny graphic being tiled and that is what is causing the delay...

Comment 18

[Andrew Schultz]

the page has 1 unclosed <font> tag for each "volume".  Closing each of the tags
cuts the page load time from 6 minutes to 22 seconds.  Removing the <font> tags
cuts it down to 14 seconds.

All times are on my P-II 450 MHz running Mozilla trunk 20030419 under Linux.

this would seem to be a dupe of bug 81993 or bug 61684

Comment 19

[Andrew Schultz]

marking dupe of "Mozilla almost hangs on this page with <FONT> tags not closed"

*** This bug has been marked as a duplicate of 81993 ***