228146 - freezes, high CPU usage

Status: RESOLVED DUPLICATE of bug 532998

(SeaMonkey :: General, defect)

Description

[Tom Jac]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6b) Gecko/20031208 MultiZilla/1.5.0.4h
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6b) Gecko/20031208 MultiZilla/1.5.0.4h

freezes, high CPU usage

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Mathew McBride]

WFM 2003120523 Linux (tinderbox build)

Comment 2

[Mitch]

Works for me. Solairs with cvs 20031208.

Comment 3

[Robert Accettura [:raccettura]]

Ok, I see this one with 1.6b

THere are so many things wrong with this page I don't know where to begin.  You
can start by viewing the source on one of those small frame's on the bottom
left.    Bad HTML all over, including typo's.

Someone should look into this particular page:

http://new.heimat.de/home/bibdat/isdat.htm

Which appears to be the one with the issue.  When I view source, I only see a
small part (and the window freezes again).

I'm personally not sure what's wrong.  Perhaps someone else could shed some insight.

Comment 4

[Mitch]

This is a ridicuously large webpage 1.7MB of a single line in textarea
widget. Plain bad html programming. 

  $ wc -l isdat.htm 
       7 isdat.htm
  $ ls -lh isdat.htm 
  -rw-r--r--   1 mitch  staff       1.7M Nov 29 08:52 isdat.htm

Your browser will take a white to download that amount of data let
alone render it.

Comment 5

[Robert Accettura [:raccettura]]

I said there was bad HTML.

I'm on a LAN, so page size can be deceving sometimes for me (depends on the
connection).  Didn't check personally. 

I'm guessing, based on that analysis, and a second look, we can mark this as
invalid, but I'll let someone else make that call.  I'm endorsing "INAVALID",
despite "NEW" being my running partner last time around.

Comment 6

[guanxi]

confirming webpage size problem.

Looks like INVALID gets the nomination in a landslide, but can he beat out DUP?

Comment 7

[(no longer active)]

This is actually a real performance problem, for which I filed a separate bug.  Let's dupe this against that one.