1328578 - Visit a page with a certain javascript code freezes browser and creates a huge amount of data on the users computer

Status: RESOLVED DUPLICATE of bug 1306334

(Firefox :: File Handling, defect)

Description

[moro]

Attachment: HTML file with the javascript code that causes the issue

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94

Steps to reproduce:

1. Visit a page with the certain javascript code.
2. Boom!

	I have uploaded a proof of concept that exposes the problem on the following URL :
	( CAUTION : click at your own risk ) http://moro.neocities.org/test-poc.html

	I'm also attaching a HTML file with the 'malicius' code (test-poc.html)



Actual results:

1. Browser freezes and start downloading files.
2. Browser becomes totally unresponsive and the only option left is to kill the firefox process
3. Now, hundreds of files are found on the /Downloads folder

Operating system : OS X 10.11.2
User Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0

The problem also exists on Firefox for Linux (Ubuntu) and Firefox for Android. I didn't test it on other environments.



Expected results:

Stop execution of the script.

For example, other browsers behave different to handle this error:
 - Chrome 55 downloads the first file, then stops executing the script and asks user if wants to download multiple files.
 - Opera 42 executes the script a limited number of times (~40) until it throws a 'Maximum call stack size exceeded' message.

Comment 1

[:Gijs (he/him)]

I would be a bit surprised if this isn't on file already in one form or another. But either way, we're aware of this issue. Paolo, what's the current progress and/or are we planning to address this other than through the download revamp stuff?

Comment 2

[:Paolo Amadini]

You can open up this bug and duplicate it to bug 1306334. It's a well-known issue.

As far as I know, we discussed which approach to use, but no work on the issue is currently planned. It can definitely be addressed independently from the rest of the download experience redesign.

Comment 3

[:Gijs (he/him)]

(In reply to :Paolo Amadini from comment #2)
> You can open up this bug and duplicate it to bug 1306334. It's a well-known
> issue.
> 
> As far as I know, we discussed which approach to use, but no work on the
> issue is currently planned. It can definitely be addressed independently
> from the rest of the download experience redesign.

I'll dupe this, but is it expected that on a clean profile we'll save these files without prompting? (Though tbh, the modal prompt spam is not a much better alternative...)
I wonder if it's worth keeping that hidden... the result of running the testcase on a fast internet connection and fast machine is pretty dire.