Closed
Bug 112858
Opened 23 years ago
Closed 11 years ago
simple but lengthy Javascript document.write loop hangs the complete browser
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: martin.honnen, Unassigned)
References
Details
(4 keywords)
Attachments
(3 files)
If I load a page with
<html>
<head>
</head>
<body>
loop starts:
<br />
<script type="text/javascript">
for (var i = 0; i < 100000; i++)
document.write(i + ' Kibology <br \/>');
</script>
loop finished.
</body>
</html>
in Mozilla the complete browsers hangs, nothing is displayed in the window I
load the page in (not even the "loop starts"), and I cannot access the stop
button. Even other Mozilla windows get blanked when you try to switch to them. I
wait for several minutes with no progress, then try to close the window when XP
tells me the app is not responding and I can only terminate.
NN4 is also working hard on a loop like this but the toobar remains accessible,
you can press the stop button to stop page loading, and you can switch to other
windows which are correctly displayed, and after sometime NN4 finishes the loop
and the loading of the page properly.
I think Mozilla should be able to load the page without hanging.
Reporter | ||
Comment 1•23 years ago
|
||
![]() |
||
Comment 2•23 years ago
|
||
The usual single-thread and we-are-not-coming-back-to-the-event-loop problem...
Comment 3•23 years ago
|
||
Sure, at some point that would be nice, but given that this is an extreme edge
case I won't spend any time on this any time soon.
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → Future
Reporter | ||
Comment 4•23 years ago
|
||
I run the test case with Mozilla 0.9.6, results
Sat Dec 01 00:32:58 GMT+0100 2001
loop starts:
0 Kibology
1 Kibology
...
99999 Kibology
end of loop Sat Dec 01 01:09:29 GMT+0100 2001: 2190.312 seconds.
That is more than 30 minutes to run the code, and it that time no output
appears at all in the browser window, it still displays the previous page and
is unresponsive.
With NN4.78 I get
Sat Dec 01 01:29:41 GMT+0100 (Westeuropäische Normalzeit) 2001
loop starts:
0 Kibology
...
99999 Kibology
end of loop Sat Dec 01 01:30:26 GMT+0100 (Westeuropäische Normalzeit) 2001:
44.891 seconds.
With IE6:
Sat Dec 1 01:32:04 UTC+0100 2001
loop starts:
0 Kibology
...
99999 Kibology
end of loop Sat Dec 1 01:32:18 UTC+0100 2001: 14.125 seconds.
IE prompts the user twice in that time to confirm that he wants to continue to
run the script.
Both NN4 and IE6 actually output the static html and then the document written
lines, with the scrollbar growing, while Mozilla just hangs displaying the
hourglass cursor.
I admit 100000 document.writes is not the average web page but taking more than
30 minutes to process that and and before displaying anythting seems like a
problem to me.
Comment 5•23 years ago
|
||
Yes, I agree that this is a problem, but it's not one that will get any
attention anytime soon. We have more critical problems.
Reporter | ||
Comment 6•23 years ago
|
||
While I was at it I think testing the DOM level 1 methods vs document.write is
worth a try.
However Mozilla still takes minutes to run through that code
Sat Dec 01 16:20:35 GMT+0100 2001
Sat Dec 01 16:47:06 GMT+0100 2001: 1591.141 seconds.
IE6 for comparison
Sat Dec 1 16:47:47 UTC+0100 2001
Sat Dec 1 16:48:15 UTC+0100 2001: 28.093 seconds.
![]() |
||
Comment 8•22 years ago
|
||
The hang is the same as described in bug 23187 and company.
Depends on: 145425
Updated•22 years ago
|
Comment 10•21 years ago
|
||
This bug manifests itself in the practical realm:
http://pedagonet.com/browse.php?subjects_id=1
At the end of the page, document.write starts choking and the output is brutally
aborted.
The above page works in IE and Safari.
PS: May 26th, 2004 - 103 entries in the DB, page may change with time.
Comment 11•19 years ago
|
||
*** Bug 330893 has been marked as a duplicate of this bug. ***
Comment 12•18 years ago
|
||
Bug 146373 has profiles; it seems js_GetProperty is the bottleneck. Sounds like bug 76139 – Over 900 successive lookups for the _same_ (frame, property).
If there's JavaScript involved, using the var keyword limits scope chain traversal. Python's tip of limiting dots by using temp vars might also be appropriate.
Comment 13•18 years ago
|
||
http://www.devwebpro.com/devwebpro-39-20030514OptimizingJavaScriptforExecutionSpeed.html has more good generic tips.
Comment 14•18 years ago
|
||
(In reply to comment #12)
> Bug 146373 has profiles; it seems js_GetProperty is the bottleneck. Sounds like
> bug 76139 – Over 900 successive lookups for the _same_ (frame, property).
>
> If there's JavaScript involved, using the var keyword limits scope chain
> traversal. Python's tip of limiting dots by using temp vars might also be
> appropriate.
Bug 76139 is not about JS property lookups.
Need fresh profile results, the ones in bug 146373 are quite old.
/be
Updated•15 years ago
|
Assignee: general → nobody
QA Contact: amar → general
![]() |
||
Comment 16•11 years ago
|
||
None of the testcases made Firefox hang.
Firefox took 0.4s on both timed tests (same speed as Chrome 31 and faster than IE 11).
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•