When long script processing occurs inside the document body instead of the head, the doc will never finish loading.

VERIFIED WORKSFORME

Status

()

Core
HTML: Parser
--
major
VERIFIED WORKSFORME
17 years ago
17 years ago

People

(Reporter: Greg Bell, Assigned: jst)

Tracking

({testcase})

Trunk
mozilla0.9.1
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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

17 years ago
Created attachment 23738 [details]
The testcase the reporter provided

Comment 2

17 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
(Reporter)

Comment 3

17 years ago
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

17 years ago
Confirmed
Platform: PC
OS: Windows 98
Mozilla Build: 2001020320
Marking NEW.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

17 years ago
This does not sound like a parser problem. Giving bug to Johnny for further 
analysis.
Assignee: harishd → jst

Comment 6

17 years ago
updated qa contact.
QA Contact: janc → bsharma

Comment 7

17 years ago
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.
Keywords: qawanted → nsbeta1

Updated

17 years ago
Blocks: 74451
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.1
(Assignee)

Comment 9

17 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
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 10

17 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.