firefox hangs when this page is loaded (as does netscape 8 beta)

RESOLVED EXPIRED

Status

()

Firefox
General
--
critical
RESOLVED EXPIRED
13 years ago
12 years ago

People

(Reporter: neil craig, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

this section of code hangs firefox:

for(i=0; i<document.all.length; i++)
{
		document.write(document.all[i]+"<br/>");
}

i can see why as document.all may contain a fair amount of data however other
browsers e.g. opera8 and sadly IE6 cope with it.

netscape 8 beta also hangs, suggesting the issue has existed for some time.

Reproducible: Always

Steps to Reproduce:
1. load http://www.thedotproduct.co.uk/firefox/index.htm or any other page
containing:

for(i=0; i<document.all.length; i++)
{
		document.write(document.all[i]+"<br/>");
}
Actual Results:  
firefox hangs and does not seem to recover.

Expected Results:  
rendered the page or warned that the script was using too many resources.

i have several extensions installed however i do not believe these have any
effect since the issue is exactly the same in netscape 8 beta which is based on
firefox 0.9.6 and has no extensions or themes installed as i use it only for
testing.

my build config is:

about:buildconfig

Build platform
target
i686-pc-cygwin

Build tools
Compiler 	Version 	Compiler flags
$(CYGWIN_WRAPPER) cl 	12.00.8804 	-TC -nologo -W3 -nologo -Gy -Fd$(PDBFILE)
$(CYGWIN_WRAPPER) cl 	12.00.8804 	-TP -nologo -W3 -nologo -Gy -Fd$(PDBFILE)

Configure arguments
--disable-ldap --disable-mailnews
--enable-extensions=cookie,xml-rpc,xmlextras,pref,transformiix,universalchardet,webservices,inspector,gnomevfs,negotiateauth
--enable-crypto --disable-composer --enable-single-profile
--disable-profilesharing --enable-optimize --disable-debug --disable-tests
--enable-static --disable-shared --enable-official-branding

and my machine is a dual athlon, 2GB ram which at the moment is running on
win2000 sp4.
I'm not seeing the problem. You've coded an infinite loop as far as we see it
(using document.all.length as the loop bound, but you're elements to the page in
each loop).  I do eventually get the "unresponsive script" prompt and can cancel
the script.

I see exactly the same thing in IE6 on WinXP SP2. They bring up the unresponsive
script dialog a little quicker, but seem to take longer to actually kill it.

Opera doesn't go into a loop. Would be interesting to experiment and see if the
document.write() isn't changing the DOM of the page, or if perhaps they're
looping over a cached copy of the unaltered original document or something. I
don't think that's the correct behavior though.

I don't see the security issue here. I'm not seeing exactly what you initially
described, but even if I did we don't normally treat browser DOS bugs as
confidential.
Group: security

Comment 2

13 years ago
I modified the testcase in comment 0 to output document.all.length. Firefox, IE
and Opera both update the length as more elements are written to the page.
Firefox and IE do the slow script warning while Opera pegs one of my cpus but
still remains responsive. Looks like the UI is on its own thread and has
priority over the script. Pressing ESC cancels the script in Opera.
(Reporter)

Comment 3

13 years ago
yeah, i see what you're saying about the infinite loop and i understand that.
the issue i have is that despite leaving the script running for over 6 minutes
(and firefox eating 100MB+ of ram plus one of my CPUs), i got no warning or
error messages. firefox also becomes completely unresponsive. i tried opening a
new window (usually i use tabs) and running the page in the new window with the
result that both windows froze.

i also get no output whatsoever from firefox to the document. ie and opera both
show some kind of output, opera not nearly so much as ie and opera (8) simply
issues a short form of document.all:

[object HTMLHtmlElement]
[object HTMLHeadElement]
[object HTMLTitleElement]
[object HTMLMetaElement]
[object HTMLScriptElement]
[object HTMLBodyElement]

whereas ie outputs multiple:

[object]

whilst issuing a slow script warning after around 5 seconds.

it seems on my system at least, that firefox is not handling the loop as
gracefully as it might. can i provide any more information/data dumps which
would help? unfortunately i'm still running windows 2k through necessity at the
moment...so this might not be as easy as it could be.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.