browser run: syntax-error classifier mislabels runtime JSON.parse failures

[ankitranjan7]

Summary

BROWSER_RUN_SYNTAX_ERROR is assigned by matching /syntaxerror/i against any error name or message. Runtime JSON.parse failures are SyntaxErrors, so a program with no syntax error at all is reported as having one.

Cause

src/browser/run/runner.ts, normalizeExecutionError:

if (/syntaxerror/i.test(`${errorKind}: ${message}`)) {
  return new BrowserRunError(
    'BROWSER_RUN_SYNTAX_ERROR',
    sanitize(message),
    'Fix the browser-run JavaScript syntax and retry.',
  );
}

This catches every SyntaxError reaching the host, whatever its origin. JSON.parse on malformed input is the common case; the message text (unexpected data at the end, invalid number literal) is indistinguishable from a QuickJS lexer message, so nothing downstream can separate the two.

Repro

This program is valid JavaScript and is reported as a syntax error:

webcmd --session <id> browser run --stdin --no-snapshot-diff <<'JS'
const pending = page.waitForResponse(r => r.url().includes('dummyjson.com/products/1'));
await page.locator('#in-stock').click();
const response = await pending;
const body = await response.json();
return { title: body.title, status: response.status() };
JS

✖  BROWSER_RUN_SYNTAX_ERROR: QuickJS promise rejected: unexpected data at the end
✖  Fix the browser-run JavaScript syntax and retry.

The actual failure is inside response.json() (see #354). The hint sends the reader to audit a program that is already correct.

Suggested fix

Classify by origin rather than by error name:

• a genuine compile failure is detectable at the point the program is compiled, and can be tagged there
• everything else reaching normalizeExecutionError is a runtime error, and a runtime SyntaxError should keep its own identity rather than being relabelled as a defect in the caller's program

At minimum the hint should not assert that the caller's syntax is wrong when the classifier cannot tell.