2059668 - Add sandbox option to evaluate_script

Status: RESOLVED FIXED

(Developer Infrastructure :: Firefox MCP, enhancement)

Description

[Ruhollah Majdoddin]

evaluate_script always evaluates in the page's own realm: script.ts sends
target: { context } and never the optional "sandbox" field that WebDriver
BiDi's script.callFunction target already accepts.

That has two costs for an agent debugging a page:

1. Inspection can be defeated by the page. If the page has overwritten
   querySelector, a getter, or Array.prototype methods - deliberately or as
   part of the bug under investigation - every evaluate_script result is
   filtered through the tampered code. Verified on Firefox 153: against a
   page that replaces document.querySelector, evaluate_script returns the
   replacement's answers.

2. Evaluation is invasive. Anything the function leaves on the global leaks
   into the page and can perturb the behavior being debugged.

Firefox already implements the remedy: target: { context, sandbox: "name" }
makes the Remote Agent evaluate in a sandbox realm
(remote/shared/Realm.sys.mjs - Cu.Sandbox over the window with
wantXrays: true). Same principal as the page, so no privilege change - but
Xray wrappers show the native view of the DOM, and writes stay invisible to
the page. The same name reuses the realm across calls, so state persists;
different names are mutually isolated. This is the engine's equivalent of
the "isolated world" other DevTools stacks expose.

Proposal: an optional "sandbox" string parameter on evaluate_script, passed
through to the BiDi target. Omitted, behavior is unchanged.

Related: bug 2057981 (raw BiDi command escape hatch) would also reach
sandbox realms, but a first-class parameter keeps the common case - reading
a page without trusting or disturbing it - one tool call with no protocol
knowledge required.

Comment 1

[BMO Github Automation]

Attachment: [mozilla/firefox-devtools-mcp] Bug 2059668 - Add sandbox option to evaluate_script (#144)