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)

defect
Not set
normal

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.
The usual single-thread and we-are-not-coming-back-to-the-event-loop problem...
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
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.
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.
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.
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
The hang is the same as described in bug 23187 and company.
Depends on: 145425
Depends on: 174359
Keywords: hang, perf
Keywords: testcase
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.
*** Bug 330893 has been marked as a duplicate of this bug. ***
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.
(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
Assignee: general → nobody
QA Contact: amar → general
Keywords: csec-dos
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.

Attachment

General

Creator:
Created:
Updated:
Size: