Closed
Bug 66952
Opened 24 years ago
Closed 23 years ago
When long script processing occurs inside the document body instead of the head, the doc will never finish loading.
Categories
(Core :: DOM: HTML Parser, defect)
Core
DOM: HTML Parser
Tracking
()
VERIFIED
WORKSFORME
mozilla0.9.1
People
(Reporter: gb, Assigned: jst)
References
()
Details
(Keywords: testcase)
Attachments
(1 file)
|
199 bytes,
text/html
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010129
BuildID: 2001012904
This bug sounds ridiculous, but bear with me, I think it's a real problem.
An identical javascript will work fine in the head, but cause the browser to go
into an infinite 'loading' state if done in the body.
Document and script content length also seems to have a bearing on this in our
real system, possibly due to a race condition.
Reproducible: Always
Steps to Reproduce:
Create an html page with the following markup and script (modified as specified
below) and point Mozilla to it.
<html>
<head>
</head>
<body class='defaultbody' onload="alert('onload fired')">
<p>body content</p>
<script language="Javascript">for(ii = 1; ii < 1000000; ii++){}</script>
</body>
</html>
In the preceding example, the for loop causes the script to "think" for a while.
One million counts may be too little on fast machines. If you get the
"expected results" the first time, then do some other slow processing to bog the
script down (like nested loops, etc..).
Actual Results: When the bug manifests, the page will never complete loading
(mozilla icon moves, onload never fires).
Expected Results: Move your script up into the <head> area and it will work as
expected (page completes loading, onload event fires).
The expected results are that the page eventually loads correctly no matter
where the <script> block resides.
I am not providing a test URL because the nature of the bug requires some
tinkering with the script code. I can get this 100% of the time on a pentium
NT4 PC and on an iMac running OS9.
I have also confirmed the same behavior in the Netscape 6 release.
NOTE: Placing document.write(" ")' after the long script operation seems to
synchronize everything and "solve" the problem in this simple case. In our
production system, this "fix" does not work. I only mention it in order to help
you debug.
|
||
Comment 1•24 years ago
|
||
|
|
||
Comment 2•24 years ago
|
||
This WORKSFORME, but I am leaving it open to see if anyone else can reproduce it. Adding testcase keyword. Platform: PC OS: Windows 98 Mozilla Build: 2001012904
Keywords: testcase
I made a foolproof point-and-click example, available at http://buzz.geneer.com/mozilla in the files 66952_good.asp and 66952_bad.asp New information: It seems that to trigger the bad behavior, the document must be loaded over http. A document loaded from the filesystem or cache will always produce the Expected Results. I used .asp file extensions because the server and client seem to agree not to cache those by default. (So the bug is reproducible without manually dumping the mem and file caches.) Errant behavior is now confirmed and 100% reproducible on: Windows NT4 (pentium class) Windows 98 (pentium II class) Windows 2000 (pentium III class) Mac OS9 (blueberry iMac with a stupid mouse) If you are still unable to find the bug, or if any of the examples don't make sense, please let me know. We are very anxious to resolve this issue, as it is preventing our web application from functioning in mozilla (and netscape 6) Thank you, -Greg
|
|
||
Comment 4•24 years ago
|
||
Confirmed Platform: PC OS: Windows 98 Mozilla Build: 2001020320 Marking NEW.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
This does not sound like a parser problem. Giving bug to Johnny for further analysis.
Assignee: harishd → jst
Let's retest once http is hosted on the new cache. Perhaps the stars will align and this will vanish. Bindu, marking qawanted, but not until the cache lands (roughly March 21 or 22).
Keywords: qawanted
I am seeing this on yesterdays Linux build. I think this is important, nominating for nsbeta1. This is one more of the cases where we "never finish" loading a page, which breaks all kinds of tests we do based on document load. It can also break some real functionality, as the tetscases demonstrate. Fixing this bug might also fix other page load problems. We have excellent test cases in this bug so I believe this bug offers the best changes to find out what is going on and fixing it.
|
||
Updated•23 years ago
|
|
Assignee | |
Comment 9•23 years ago
|
||
I just tested this again and I don't see this problem any more, marking WORKSFORME, please reopen if this is still happenin'.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
|
||
Comment 10•23 years ago
|
||
Verified on: build: 2001-04-16-06-Mtrunk platform: WinNT Both the .asp files are checked and works fine.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•