Bugzilla

The testcase is almost identical with bug 1872960 except for the missing `self.navigator.storage.getDirectory()` (thus no involvement of file system / quota manager) which confirms the suspect that if quota manager would not have hanged on that bug we'd hang later on worker shutdown, anyways.

To recap shortly what happens (but I'll ask for a pernosco session to confirm 100%):

- The blob definition `a = new Blob([a, a, a, "�", a, ...], {})` adds a level of recursion to the generated blob on each onMessage, copying the blob from the previous call 6 times as piece into the new multipart blob.
- As a result, on each post message the newly generated blob contains 6 times the previous one, growing thus exponentially.
- This results in [very long running runnables](https://searchfox.org/mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0/dom/file/MultipartBlobImpl.cpp#79,94) on the worker thread that block the worker's shutdown.

This seems to be mostly a DoS scenario that shows that badly written JS can hang us before it causes an OOM (which would be the ultimate reaction, I think). Unless this is a fuzz blocker I am not sure if we should spend too much time resolving this.

FWIW, it seems the fuzzer found a way for workers to do accidentally what bug 1844129 wants to do purposefully.

The testcase is almost identical with bug 1872960 except for the missing `self.navigator.storage.getDirectory()` (thus no involvement of file system / quota manager) which confirms the suspect that if quota manager would not have hanged on that bug we'd hang later on worker shutdown, anyways.

To recap shortly what happens (but I'll ask for a pernosco session to confirm 100%):

- The blob definition `a = new Blob([a, a, a, "�", a, ...], {})` adds a level of recursion to the generated blob on each `onMessage`, copying the blob from the previous call 6 times as piece into the new multipart blob.
- As a result, on each post message the newly generated blob contains 6 times the previous one, growing thus exponentially.
- This results in [very long running runnables](https://searchfox.org/mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0/dom/file/MultipartBlobImpl.cpp#79,94) on the worker thread that block the worker's shutdown.

This seems to be mostly a DoS scenario that shows that badly written JS can hang us before it causes an OOM (which would be the ultimate reaction, I think). Unless this is a fuzz blocker I am not sure if we should spend too much time resolving this.

FWIW, it seems the fuzzer found a way for workers to do accidentally what bug 1844129 wants to do purposefully.

The testcase is almost identical with bug 1872960 except for the missing `self.navigator.storage.getDirectory()` (thus no involvement of file system / quota manager) which confirms the suspect that if quota manager would not have hanged on that bug we'd hang later on worker shutdown, anyways.

To recap shortly what happens (but I'll ask for a pernosco session to confirm 100%):

- The blob definition `a = new Blob([a, a, a, "�", a, ...], {})` adds a level of recursion to the generated blob on each `onmessage`, copying the blob from the previous call 6 times as piece into the new multipart blob.
- As a result, on each post message the newly generated blob contains 6 times the previous one, growing thus exponentially.
- This results in [very long running runnables](https://searchfox.org/mozilla-central/rev/bc6a50e6f08db0bb371ef7197c472555499e82c0/dom/file/MultipartBlobImpl.cpp#79,94) on the worker thread that block the worker's shutdown.

This seems to be mostly a DoS scenario that shows that badly written JS can hang us before it causes an OOM (which would be the ultimate reaction, I think). Unless this is a fuzz blocker I am not sure if we should spend too much time resolving this.

FWIW, it seems the fuzzer found a way for workers to do accidentally what bug 1844129 wants to do purposefully.