Bugzilla

(In reply to Neil Fraser from comment #0)
> A while(1){} statement within JavaScript in a SVG causes a dialog box to
> appear
> asking if you want to terminate the script.  This is good.  What's bad is
> that
> if the infinite loop contains calls to "document.createElementNS" and
> "appendChild", then the infinite loop goes unchecked.  There's no way to
> terminate the script without terminating the browser.

Two updates from testing in 2022-era Firefox:
 - We do now show a "This page is slowing down Firefox" notification (if you try to interact with the page, at least)
 - ...though if I click "Stop", the content process remains pegged at 100% CPU with memory-usage ticking ever-upwards.
- ...however, it looks like we **did really stop the script**. Memory usage and CPU is just pegged because we're now left with an absurdly giant DOM which we attempt to render.
- And then the content process ultimately crashes with an out-of-memory exception, on my machine at least (which turns just that one tab into an error page, in our modern e10s-enabled world, essentially; and the rest of the browser is fine).

This produces a crash report like bp-f16f5f95-ee35-4c33-9e14-ce8b50220818  (from me just now).

So I think this is essentially WORKSFORME at this point; the hang is still there but it's not as problematic given that we do show the "Stop" button, and we do kill the content process if it's sufficiently misbehaving (without taking down the rest of the browser).

(In reply to Neil Fraser from comment #0)
> A while(1){} statement within JavaScript in a SVG causes a dialog box to
> appear
> asking if you want to terminate the script.  This is good.  What's bad is
> that
> if the infinite loop contains calls to "document.createElementNS" and
> "appendChild", then the infinite loop goes unchecked.  There's no way to
> terminate the script without terminating the browser.

Two updates from testing in 2022-era Firefox:
 - We do now show a "This page is slowing down Firefox" notification (if you try to interact with the page, at least)
 - ...though interestingly: if I click that notification's "Stop" button, the content process remains pegged at 100% CPU with memory-usage still ticking ever-upwards.
- ...however, it looks like we **did really stop the script**. Memory usage and CPU is just thrashing because we're now left with an absurdly giant DOM which we attempt to render.
- And then the content process ultimately crashes with an out-of-memory exception, on my machine at least (which turns just that one tab into an error page, in our modern e10s-enabled world, essentially; and the rest of the browser is fine).  This is to-be-expected for a page of the size that we're left with at the point where I was able to interrupt the script, I think.

This produces a crash report like bp-f16f5f95-ee35-4c33-9e14-ce8b50220818  (from me just now).

So I think this is essentially WORKSFORME at this point; the hang is still there but it's not as problematic given that we do show the "Stop" button, and we do kill the content process if it's sufficiently misbehaving (without taking down the rest of the browser).