Closed Bug 336602 Opened 18 years ago Closed 18 years ago

Uploading file triggers "unresponsive script" message when there's no script

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: timwi, Unassigned)

References

Details

(Whiteboard: addon: SessionSave ) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

Since Firefox upgraded itself to 1.5.0.3, uploading a file to a PHP-powered website often triggers the "unresponsive script" message box, even when there's absolutely no JavaScript on the page that appears.

The file is uploaded correctly. The animated rotating icon in the tab works normally up to the point where the file has completed uploading. It then freezes for a few seconds. Then the error message appears.

Clicking "Stop script" makes the response page appear normally. Clicking "continue" only leads to the same message box another few seconds later.

Reproducible: Always

Actual Results:  
"Unresponsive script" message box appears inappropriate. There is no script on the page.

Expected Results:  
Response page should appear as usual.
Thanks, but no. That forum post assumes that the message is triggered because the upload takes too long, or because the site is too slow. Neither is the case. I get the error happening even if I upload a 10-KB file to localhost. The upload finishes, then it blocks for n seconds (where n is the dom.max_script_run_time setting, default 5) and then the message pops up. In cases where the upload *is* large and the site *is* slow, it takes its while to upload the file, but the upload is performed correctly and flawlessly. Only when the upload finishes, but before the results page is displayed, the blockage begins.
Additional testing information.

OS: Windows XP SP2
CPU: AMD
MEMORY: 1024 MB
HDD: 74 GB

Firefox Versions: 1.5+ (includes newest)

NOTE: This does NOT occur in 1.0.7.

This also occurs on my machine. I have tested a simple HTML form that takes a file upload and that is all. No PHP, no javascript, nothing. Just plain HTML. 

During this upload Firefox consumes ~100% of the CPU and hangs (see http://www.within-reason.com/bugzilla/taskmanager.gif). Eventually you get the "unresponsive script" error (see http://www.within-reason.com/bugzilla/unresponsive_script.gif). If you select "continue" Firefox hangs again using ~100% CPU and the messages appears. This goes on for almost ever. If you hit stop script the next page (which is just a simple HTML printout saying "Hello!") loads.

Beyond that, even though you can tweak the config setting, you should not have to. A normal user will not know what to do and if they are using a site or open source web app you have developed, they will only become frustrated. This is a major bug in Firefox. Serious flaw.

When testing the same site in Internet Explorer, it works fine without error. If you add in some PHP to copy the file and do some processing, IE still works without problem. Firefox still fails. The file is uploaded correctly though.

TO REPRODUCE:

Reproducable: Always

Test site: http://www.within-reason.com/bugzilla/

Go and upload a file using Firefox 1.5 or greater. Then try with Firefox 1.0.7 or lower.

There are two HTML pages: index.html and process.html

Code for index.html:
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>
<html>
	<head>
		<title>Bug 336602 - Test Site</title>
		<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	</head>

	<body>
		<h1>Bug 336602 - Test Site</h1>
	    <form action="process.html" method="post" enctype="multipart/form-data" name="uploadPDF" id="uploadPDF">
			<input type="file" name="pdf" id="pdf" /><br/>
			<input type="submit" name="Submit" value="Submit">
		</form>
	</body>
</html>

Code for process.html:
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>
<html>
	<head>
		<title>Bug 336602 - Test Site</title>
	</head>
	<body>
		HELLO!
	</body>
</html>

Thanks.
Mike
(In reply to comment #3)
> During this upload Firefox consumes ~100% of the CPU and hangs (see
> http://www.within-reason.com/bugzilla/taskmanager.gif). Eventually you get the
> "unresponsive script" error (see
> http://www.within-reason.com/bugzilla/unresponsive_script.gif). If you select
> "continue" Firefox hangs again using ~100% CPU and the messages appears. This
> goes on for almost ever. If you hit stop script the next page (which is just a
> simple HTML printout saying "Hello!") loads.

I tried uploading a 10 KB file and a 10 MB file using both Firefox 1.5.0.3 and the SeaMonkey 1.0.2 candidate on Windows XP SP 2. I never saw excessive CPU usage, a hang, or the "unresponsive script" dialog. After the file uploaded, I got the "Hello!" page.

Can you try creating a new profile and see if that fixes the problem?
I have not yet tried creating a new profile (I'm at work, I'll have to do it later).

But...

I have tested a number of file sizes. Here are my results.

(Note: each time the file gets bigger, Firefox uses more CPU, around 500K it starts using ~100% and "hangs" during the upload process. Not sure if this is normal.)

(Note: all of S*these were tested on the local LAN and using 1.5.0.3.)

With dom.max_scrip_run_time = 30
4 KB    --> WORKS
36 KB   --> WORKS
52 KB   --> WORKS
104 KB  --> WORKS
150 KB  --> WORKS
390 KB  --> WORKS
850 KB  --> WORKS
1005 KB --> WORKS
1532 KB --> WORKS
3140 KB --> FAILS*

With dom.max_script_run_time = 5
4 KB    --> WORKS
36 KB   --> WORKS
52 KB   --> WORKS
104 KB  --> WORKS
150 KB  --> WORKS
390 KB  --> FAILS*
850 KB  --> FAILS*
1005 KB --> FAILS*
1532 KB --> FAILS*
3140 KB --> FAILS*

What this leads me to believe is that Firefox thinks a script is running because it using a vast amount CPU and actually doing something for longer than Mozilla feels is safe.

When in reality it is only uploading a file. Beyond that, there are cases where a script, such as PHP, make take some time to load and run. If this is the case, users should not be receiving this error and should not have to change config settings. After all, EVERYTHING works fine in 1.0.7. It seems 1.5+ introduced the issue.

Another reason why I believe this is a bug is because in 1.0.7, the dom.max_script_run_time is set to 5 and uploads work fine. In addition, in 1.0.7 when you upload a file (say the largest I tested), not only does it work, but Firefox does not use anymore than 20% CPU and does not hang. The file upload is instant as it should be on a local LAN.

Something was introduce in 1.5+.
Ok, after doing some more testing and checking out a few different computers. I have determined that the culpret of this issue is an extension. SessionSave .2,  the version that is on Mozilla's extension site. 

There is a new version in the forums. You can find it by using the link at the bottom of the Mozilla extension page to the extension’s homepage. This new version, .2d, fixes the problem.
It looks like the problem was a bad extension.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
(In reply to comment #7)
> It looks like the problem was a bad extension.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

I get that "unresponsive script" message, too. Even with no page loaded (fresh tarted Firefox with about:blank as home page). Due to that behaviour I suspect a bad extension, too, but due to the stunning precise message I'm unable to nail that down - at least I'm way too lazy to uninstall/reinstall each and every of my numerous installed add-on's.

I would suggest to extend that message with a hint to where to search - in the message itself or in any kind of subsequent window.
bring revisionist for small set of "unresponsive script" bugs.
sorry for bugspam.
Status: RESOLVED → VERIFIED
Whiteboard: addon: SessionSave
You need to log in before you can comment on or make changes to this bug.