35762 - crashes browser (freeze) (M14 up to latest build)

Status: VERIFIED WORKSFORME

(SeaMonkey :: General, defect, P3)

Description

[Loren Cannon]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m14)
BuildID:    2000041308



Reproducible: Always
Steps to Reproduce:
1.try loading the URL
2.
3.

Comment 1

[Jeffrey Baker]

Can't reproduce this with Build 2000041309 on Linux.  Also, the provided URL
does not exist.

Comment 2

[Sean Richardson]

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

Comment 3

[Asa Dotzler [:asa]]

cannot reproduce this with 041308 build under NT.  The URL redirects to 
hemestead.com which works fine.  Reporter I'm resolving this worksforme.  If 
you can point us to the URL that causes the problem then please take a look at 
the bg writing guidelines and reopen this bug with more information.  Thanks.  
The bug writing guidelines can be found at http://www.mozilla.org/quality/bug-
writing-guidelines.html

Comment 4

[Blake Ross]

wfm also under win98, verifying

Comment 5

[Loren Cannon]

wrong url :
new url: http://www.homestead.com/breakdancingheavan/bdh.html

Comment 6

[Asa Dotzler [:asa]]

This doesn't crash me under NT but it does freeze the browser.  Tested with 
041409 build.  Anyone see anything ugly in that HTML?  Reopening and updating 
URL field.

Comment 7

[Loren Cannon]

does not crash browser anymore



html for this page suxx, displays blank

Comment 8

[Andreas Franke (gone)]

m14 and 2000-03-29 also freeze. m13 says "Error loading page...".
Extending summary.

Comment 9

[Andreas Franke (gone)]

Confirming bug, setting OS to all (I run PC/Linux, Mac is untested yet), 
and severity to critical.

I didn't manage to save the complete page locally. Neither wget nor 
the Netscape composer can do this: a recursive wget returns a 404 error, 
and the Composer isn't very helpful because the site does extensive sniffing 
and says it can't deal with JavaScript.
Setting network.http.version to "1.0" does not help either.
Don't know how to track this down.

Comment 10

[Andreas Franke (gone)]

Well, actually, the page loads successfully, if you are patient enough:

Document http://www.homestead.com/breakdancingheavan/bdh.html loaded
successfully
Document: Done (258.016 secs)

If I use our cache proxy, the second time I load the page it's even quite fast:

Document http://www.homestead.com/breakdancingheavan/bdh.html loaded
successfully
Document: Done (35.518 secs)

It still freezes for some long intervals while loading (20 secs up to 2
minutes), but finally it even handles stop requests if you are patient
enough. 
The page doesn't display as intended, but probably that's some other bug
(redirections, javascript,...). So I'd like to unconfirm this bug again,
but since that's not possible, I am only going to lower the severity back
to normal. Sorry for the confirmation. I won't touch this bug again...

Maybe the scheduling/event-handling people are interested in this bug
as a testcase.

Comment 11

[leger]

Adding crash keyword.

Comment 12

[Asa Dotzler [:asa]]

elig, can you help us out on this one.  I'm stumped.

Comment 13

[Loren Cannon]

request for resolved fixed status . . . has been working for some time. . .

Comment 14

[Eli Goldberg]

Hi, Asa ---

I don't know what to suggest; this works for me using the 4.26.00 Mozilla build 
on Mac OS & Win32. 

(e.g. http://www.homestead.com/breakdancingheavan/bdh.html displays within 5 
seconds.)

Comment 15

[Asa Dotzler [:asa]]

thanks elig, reporter says it's good now.  Marking WORKSFORME.

Comment 16

[Asa Dotzler [:asa]]

Verified with 050808 build under NT.