User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36

Steps to reproduce:

Tested under Ubuntu 18.04 with Firefox 84.0.1.

1. Go to https://reaperbugs.pwnsdx.com/
2. Click Reap Firefox
3. Click Ok
4. The browser freezes
5. The laptop freezes
6. The laptop reboots

Actual results:

This is an old bug for "Firefox 62.0.2 and earlier.". It seems it tries to download a lot of files (that's what chrome said when trying to load the page). The Firefox then freezes, followed by the OS, to end by a reboot.

I am running a Dell XPS 15 7590 under Linux Ubuntu 18.04.

Expected results:

Firefox tells me the website tries to download a lot of files and prevents it.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Reproduced on the latest versions of Firefox Nightly 86.0a1 (2021-01-08), beta 85.0b6 and release 84.0.2 using the steps provided and with the same results.
This could not be reproduced on Chrome as it simply shuts briefly down and opens a new tab instantly without freezing the computer or browser.

Updating flags and setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

I'm not sure where to put the bug but it's not Widget/Gtk as it surely affects other platforms too. Looks like infinite JS loop or so.

I'm not sure if this even is a bug, but it definitely is not "(Catastrophic) Blocks development/testing, may impact more than 25% of users, causes data loss, likely dot release driver, and no workaround available".

Sounds like the site intentionally crashes the browser by running it out of memory, and Linux handles that badly.

Based on the description, it sounds like this is a Downloads API bug, so moving it there…

This is to do with blob broadcasting and navigation via link clicks (source: https://gist.github.com/pwnsdx/d20a99c0500d6f05993ef730bef26746 ). A similar-ish thing was brought up in bug 1647019 but that was resolved because it used different techniques for the navigation that were blocked for other reasons, so the exploit no longer worked. It's a bit interesting because the comments on the gist suggest that this uses "history back and forward" calls, but those aren't in the gist - it just clicks links a lot of times. Paul, was this supposed to be stopped by the rate limiting introduced in 1314912?

I'm also wondering if we should set some kind of limit on the number of blob URIs a single site should be allowed to create, or something...

There is also bug 1463527 about download spam protection in general.

Potentially a dupe of Bug 1438214 which should've been fixed via Bug 1472158?
Bug 1314912 only rate limits direct calls to the history / location APIs, so it wouldn't apply here.

(In reply to Paul Zühlcke [:pbz] from comment #7)

Potentially a dupe of Bug 1438214 which should've been fixed via Bug 1472158?
Bug 1314912 only rate limits direct calls to the history / location APIs, so it wouldn't apply here.

The DoS scenario is slightly different here from bug 1438214: While over there they created endlessly new Blobs, here we just iterate downloading the very same blob instance, it seems. Any thoughts, :smaug?

This smells mostly a dup of bug 1463527.