Stop a deeply recursive script from taking down the process

[lahma]

Fixes #75.

The problem

EngineInstance built the Jint engine without any execution constraints, so Options.Constraints.MaxExecutionStackCount stayed at Jint's default of -1 — the stack guard off. Jint spends the native stack on JavaScript frames, and the 1 MB a thread gets by default holds roughly a thousand of them (Jint's own EngineLimitTests measures ~990 in Release). A browser offers around eleven thousand, so a script written for one could exhaust the stack here.

That is what makes the reported symptom so blunt: a StackOverflowException cannot be caught, so the try/catch AngleSharp already has around EvaluateScriptAsync in ScriptRequestProcessor never runs and the whole process dies.

The fix

Enable the stack guard. Such a script now reports the usual RangeError: Maximum call stack size exceeded, which is an ordinary JavaScriptException and gets tracked like any other script error via IBrowsingContext.TrackError.

How deep a script may go before that happens is what the new JsScriptingOptions carries, defaulting to 10000 — roughly what browsers allow, so this is not a compatibility cut:

var config = Configuration.Default
    .WithJs(new JsScriptingOptions
    {
        MaxCallStackDepth = 5000,
    });

WithJs() and new JsScriptingService() keep working unchanged, on the default options. This also makes the claim the README and docs/general/01-Basics.md have carried all along — that options can be passed to WithJs — true.

The guard only fires once the native stack is nearly out; below the configured depth Jint continues the call on a fresh stack. JsEventLoop's thread therefore gets a stack to match, so the depth is reached on the thread itself rather than by borrowing thread-pool ones. A 32 bit process keeps the default, having little address space to spare once a few loops exist.

Tests

StackGuardTests — runaway recursion in page script does not escape OpenAsync; a small MaxCallStackDepth produces the expected JavaScriptException; and 1500-deep recursion still returns the right value, so the default is not a regression for scripts that legitimately recurse past one thread's stack.

The first two are worth a note: a StackOverflowException cannot be caught, so there is nothing weaker to assert than "we got here at all". I checked they are not vacuous by disabling the guard and re-running — the test host dies with Test Run Aborted instead of failing.

Not addressed

• The follow-up comment on StackOverflow exception when trying to open link #75 (ReferenceError: Image is not defined on google.com) is stale: Image arrived in e8de221, and script errors already do not escape OpenAsync.
• An infinite loop (while (true) {}) still hangs OpenAsync forever. JsScriptingOptions is the natural home for a TimeoutInterval / MaxStatements knob if that is ever wanted.

🤖 Generated with Claude Code

[FlorianRappl]

Fantastic!