72107 - above URL does not load (loads in Netscape/2 4.61)

Status: RESOLVED DUPLICATE of bug 29805

(Core :: DOM: Navigation, defect)

Description

[a0075487]

Version that does not work: Mozilla/5.0 (OS/2; U; Warp 4; en-US; 0.8)
Gecko/20010217 for Xfree86/2 !
The Gimp users manual does not load, neither form the url above nor downloaded
to harddisk on my computer. javascript enabled, indexing function of the manual
switched off

Comment 1

[Phil Schwartau]

[e-mail]: What happens when you try to load the document? 
Does the browser "hang"? What is the CPU and memory usage when this happens? 
If the browser does not hang, do you see any errors in the JavaScript Console?

(Tasks-->Tools-->JavaScript Console)

Be sure to open the console and clear out any errors from past sites
before you try to load the GIMP documment; then see if you find any errors - 



What happens if indexing function of the manual is switched on? 

Comment 2

[Phil Schwartau]

Compare bug 31784

Comment 3

[Mike Kaply [:mkaply]]

I recreated this on the latest Windows build.

The page just simply never completes loading. Ever. On 4.x it loads fine.

There are no errors in the console.

The mozilla is animating, and the browser is still responsive. It's just 
spinning.

Not sure where this belongs...

Comment 4

[Phil Schwartau]

Using debug Mozilla builds 2001-03-25. on WinNT, Linux. 

The site loaded very slowly, whereas NN4.7 loaded it in around 10 seconds. 
With Mozilla, the CPU remained pegged at 100% for a minute or two. I saw 
these assertions in the debug console: 


###!!! ASSERTION: The DocLoader is still busy...There is a bug in 
End Document notifications: '0',
file  d:\mozilla\xpfe\browser\src\nsBrowserInstance.cpp, line 998

###!!! Break: at file nsBrowserInstance.cpp, line 998
/manual/GUM/wwhblnk.htm

Comment 5

[Phil Schwartau]

Attachment: Linux stack trace obtained via interrupting page load

Comment 6

[Phil Schwartau]

Not sure of which code is holding up the page load, but I can't see 
JS Engine issues in the assertions or the stack trace. Reassigning to 
Embedding:Docshell for further triage -

Comment 7

[Phil Schwartau]

NOTE: I have a Mozilla binary from 2001-02-01 that loads the site 
as fast as NN4.7. The next WinNT binary I have, from 2001-03-03, 
seems to hang. So perhaps a regression occurred between those two dates...

Comment 8

[Phil Schwartau]

Really reassigning - 

Comment 9

[Adam Lock]

Revisting old bugs...

This page works more or less but very, very slowly.

Some reasons it is slow:

1. Lots of Javascript. This page pulls in approximately 170k of external JS plus
plenty more inlined.
2. Lots of memory allocations. For example GimpmanualIX.js & GimpmanualTOC.js
perform at least 1600 memory allocations to build up a table of contents tree
and index.
3. Lots of loops and document.write'ing. The tree for the table of contents is 
walked to generate the TOC panel.
4. Broken sniffer code - only expects IE or Nav version 4.

I can't isolate any obvious bustage. Phil do you want to take this back to JS
ownership and mark it as a page with performance problems? Otherwise I would be
inclined to mark it WONTFIX

Comment 10

[Adam Lock]

Attachment: HTML and JS for the site, zipped up

Comment 11

[Adam Lock]

One other point. There is plenty of calls to document.write in this JS, but it
doesn't appear to be enclosed by document.open/close operations. I thought this
was a requirement if you wanted to write to a document?

Comment 12

[Phil Schwartau]

Oops - looks like this is a dupe of bug 29805. Sorry, I should have
spotted that before. Note these bugs filed against gimp.org:

bug 29805 ASSI       Loading page is *really* slow (due to bad document.write())
bug 37500 VERI DUPL  NonStop downloading 
bug 90882 RESO DUPL  Mozilla responds very slowly with the above page or hangs 
bug 74519 NEW  [Evangelism] JavaScript tree doesn't work correctly


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