One unresponsive JS thread freezes the whole browser

[Agent Orange]

When running any page which has a piece of poorly written JavaScript on it, the entire browser locks up: all tabs across all windows; every aspect of the browser and UI becomes unresponsive, taking tens of seconds to process a single click. Other tabs can neither be opened nor viewed, the offending tab cannot be closed, and even the "stop script" dialog, when it appears, is not readily usable. The CPU usage is only 1 thread @100%, not even enough to kick on the fans.
(Facebook triggers this bug semi-regularly.)

It is unacceptable that a single malfunctioning webpage should be able to wreck the browser so heavily. Chrome does not do this; and even Firefox (50.0.2), while a rogue JS thread does choke its renderer, it does not lock up the core browser and UI; consequently, its "Stop Script" dialog works quickly and as intended.

• CPU: i7-920
• Pale Moon 27.0.2 (x64)
• OS: Mint 18 XFCE

(Will provide any further configuration details requested.)

This code snippet can reproduce the bug reliably: https://studio.code.org/c/301123500/

[Tomaso]

Tested and confirmed.

[Moonchild]

When running any page which has a piece of poorly written JavaScript on it, the entire browser locks up: all tabs across all windows; every aspect of the browser and UI becomes unresponsive, taking tens of seconds to process a single click. Other tabs can neither be opened nor viewed, the offending tab cannot be closed, and even the "stop script" dialog, when it appears, is not readily usable. The CPU usage is only 1 thread @100%, not even enough to kick on the fans.

The "stop script" dialog should suspend the offending script, unless you're looking at poorly written JS that causes issues due to recursive calls (e.g. a timeout calling itself). There's no easy or reliable way to safeguard against this kind of thing, since it will flood the main thread (which is by its very nature a 1-core deal; the controller thread can't be multithreaded).

That being said, I can see if I can make the "stop script" function a bit more aggressive in what all it stops.

EDIT: it seems reasonable to me to just stop all scripts in a tab if you hit the unresponsive script dialog. That will be a simple, effective fix.

[Moonchild]

https://github.com/MoonchildProductions ... 4ebaa09780 takes care of this -- do note that really bad recursive scripting will continue to hang the browser, but at least "stop script" gives a better way out in this case.
Added a pref dom.global_stop_unresponsive_script (boolean) to control this behavior in case you want the old way, although I can't off-hand think of a situation where you'd just want to stop one script -- you're likely going to have a (very) broken situation anyway

[Agent Orange]

[…]There's no easy or reliable way to safeguard against this kind of thing, since it will flood the main thread (which is by its very nature a 1-core deal; the controller thread can't be multithreaded).

Why is this? Is it truly necessary for an out-of-control script to lock up the browser's user interface? Why do Firefox and Chrome not have this behavior? Are there any "pages available to be stolen from their book", so to speak?

That being said, I can see if I can make the "stop script" function a bit more aggressive in what all it stops.

EDIT: it seems reasonable to me to just stop all scripts in a tab if you hit the unresponsive script dialog. That will be a simple, effective fix.

That like a workaround to an issue separate from the one that this thread is about.

The stop script dialog DOES work; it just takes an eternity for the browser to get around acknowledging that the button was pressed…

[Agent Orange]

[…]That like a workaround to[…]

Argh, what a horrible typo! And I can't edit it!!