1644767 - DoS using shared workers and on-connect firefox

Status: NEW

(Core :: DOM: Workers, defect, P3)

Description

[u635660]

Attachment: WebSocket_browser_crash_repro.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36

Steps to reproduce:

steps to reproduce
open WebSocket_browser_crash_repro.html in firefox

Firefox starts hanging and becoming unusable

Actual results:

firefox started becoming unstable

Expected results:

it should not start hanging and becoming unstable

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

:jstutte could you review the priority/severity for this bug?

Comment 2

[Jens Stutte [:jstutte]]

Hi Eden, I assume it is less scary than P1 suggests here?

Comment 3

[Alin Ilea, Desktop QA]

Hi,
I am able to reproduce the issue in latest Nightly 87.0a1 (2021-02-08), Beta 86.0b7 and Release 85.0.1 using Windows 10. Changing the flags and the status accordingly.
Thanks.

Comment 4

[Jens Stutte [:jstutte]]

So on my machine this causes the CPU to spin 100% and memory of Firefox slowly increasing, but while this happens the rest of Firefox remains quite responsive in the sense that I can close the affected tab without problems and after a while things turn normal. Given that there are many ways to OOM and waste CPU cycles via Javascript, I think we can lower the severity here, too. However, it seems there is no doorhanger for the user that informs about a blocking script in this case.