For automation and devtools, we sometimes want to execute script directly as if it was run by the user in the context of the page. Currently this is quite hard to do, so we often end up running those scripts in a sandbox, but with XRays waived. This is OK, but it's observably different from running in the content itself, and so can cause some interop issues for automation scripts.

To solve this it would be good to have a simple way to eval scripts as if they were running directly in content (but without the scripts being blocked by CSP or similar) e.g. Cu.evalInContent by analogy to Cu.evalInSandbox.

I think you can mostly get this by calling .eval() over Xrays, but I'm not sure whether the CSP check uses the subject principal or the principal of the global. If it's the former this will Just Work, but I suspect it's probably the latter. If somebody could dig up where the CSP check is for eval that'd be helpful.

(In reply to Bobby Holley (:bholley) from comment #1)

I think you can mostly get this by calling .eval() over Xrays, but I'm not sure whether the CSP check uses the subject principal or the principal of the global. If it's the former this will Just Work, but I suspect it's probably the latter. If somebody could dig up where the CSP check is for eval that'd be helpful.

I imagine for many of these use-cases we wouldn't want to use .eval() over xrays as that could lose filename and line number information, so it may be worthwhile to expose another mechanism even if eval works.

In terms of where the check is performed, the xray wrapper resolves the eval property with the original realm eval (https://searchfox.org/mozilla-central/rev/6a7c3a1eda4ebb8f9c13779dbbf5eff15bacf8ed/js/xpconnect/wrappers/XrayWrapper.cpp#1614), which is defined to js::IndirectEval here: https://searchfox.org/mozilla-central/rev/6a7c3a1eda4ebb8f9c13779dbbf5eff15bacf8ed/js/src/builtin/Eval.cpp#364. This performs the call through the JS security callbacks table, which should (IIRC) end up here for main-thread contexts: https://searchfox.org/mozilla-central/rev/6a7c3a1eda4ebb8f9c13779dbbf5eff15bacf8ed/caps/nsScriptSecurityManager.cpp#450

(In reply to Nika Layzell [:nika] (ni? for response) from comment #2)

This performs the call through the JS security callbacks table, which should (IIRC) end up here for main-thread contexts: https://searchfox.org/mozilla-central/rev/6a7c3a1eda4ebb8f9c13779dbbf5eff15bacf8ed/caps/nsScriptSecurityManager.cpp#450

Looks like that pulls the CSP off the window, so we'll need a separate API here anyway.