155354 - Opening the page www.vr.fi/keskustelu/inter.htm will jam or crash mozilla.

Status: RESOLVED WONTFIX

(SeaMonkey :: General, defect)

Description

[Henrik Ingo]

... at least most of the time.

I'm not sure whether this is a problem in showing the page or something
happening with the network transfer.

I'll attach a recent copy of the page too.

Comment 1

[Henrik Ingo]

wow, what a fascist policy on attachment size! Ok, here is a copy of the page:

http://www.hut.fi/~hingo/tmp/mozillabugs%20-%20Inter%20rail%20-keskustelu.htm

Comment 2

[Henrik Ingo]

Again, my exact build is
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530

Comment 3

[greer]

WFM on Mozilla 1.0 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
and
yesterday's 20020701 Trunk build for windows.

Comment 4

[Matthias Versen [:Matti]]

wfm with win2k build 20020630..

Comment 5

[Andrew Schultz]

with linux build 20020701, Mozilla appeared did appear to hang duing page load.
 I fired up debug build to get a stacktrace and it did freeze for a bit, but
eventually rendered the page ok.  Binary build took > 2 minutes to load.

Henrik: if you wait long enough, does the page eventually load?

Comment 6

[Henrik Ingo]

In fact, yes it did. Approx 20 secs when loading from hard disk. (I could have
sworn I waited at least that long yesterday.)

I guess when you add a random network hiccup to that, it makes it look like
nothing is happening.

I also tried at work, same 1.0 build on win2000, and it also worked.

So, false alarm, calm down. Whether you want to tune something based on this or
just forget it is up to you.

Comment 7

[Henrik Ingo]

... oh, but now that I think of it, once it actually crashed all browser
windows. That one I haven't been able to repeat.

Comment 8

[Andrew Schultz]

did you get a talkback ID for the crash?

Comment 9

[Henrik Ingo]

No, everything just disappeared.

Comment 10

[Frederic Bezies]

WFM - Trunk build 2002081304 - WinXP.

Comment 11

[Benjamin Smedberg]

This is oviously a VERY long page, and I suspect that layout is doing
incremental reflows much too often for the amount of data on the page, and
because layout is not interruptable, the UI stops responding (See Bug 51202, Bug
67752)... the crash was probably caused by an out-of-memory condition or some
similar anomaly.  I am going to mark this bug WONTFIX because there are already
bugs files on the underlying issues.  If you continue to crash on this page and
can provide a talkback ID or a stacktrace, feel free to re-open this bug...
perhaps there is another problem lurking that can be fixed.