Restating:

• Bug 1734320 in https://phabricator.services.mozilla.com/D127641 introduced SandboxStructuredClone and making it accessible via wantGlobalProperties including factoring out nsContentUtils::StructuredClone from nsGlobalWindowInner::StructuredClone and mozilla::dom::WorkerGlobalScope::StructuredClone. An additional usage in mozilla::dom::PerformanceMark::Constructor in https://phabricator.services.mozilla.com/D142625 as part of https://bugzilla.mozilla.org/show_bug.cgi?id=1724645.
  • The motivation was for devtools to be able to use it for https://bugzilla.mozilla.org/show_bug.cgi?id=1734166 but the performance hit decided for it not to be used, so the only use was in the xpcshell test_structuredClone.js introduced with the functionality.
• This patch leverages that existing-but-unused implementation by making the webextension content script sandbox always "wantGlobalProperties" that "structuredClone" implementation while also introducing a pref extensions.webextensions.legacyStructuredCloneBehavior which enables the old behavior as perceived by web extensions which is conditioned on:
  • being a webext content script sandbox (as reported by xpc::IsWebExtensionContentScriptSandbox) AND
  • if the thing being cloned is an object (per JS::Value::isObject which does not have the typeof(null)=='object' weirdness) and if the object-to-be-cloned is one of the types that would previously have been serialized into the window global, we change the target global to be the window global (as compared to the window and worker cases where we use the window/worker global, which previously for content scripts was the window global because of the prototype chain)
• A critical call to mozilla::dom::MaybeWrapValue was added to sandboxStructuredClone; the xpcshell test only ever ran the test in a sandbox global and did not interact with multiple globals. The generated WebIDL bindings (non-permalink linux64 WindowBinding.cpp inherently have that, but the sandbox dynamic definition stuff is not that and does not have any extra WebIDL binding goop.
• The test infra seems to most closely match test_ext_contentscript_context_isolation.js in terms of the ExtensionContent.getContextByExtensionId and seems reasonable to me but I am not an expert at that infra and I'm assuming @robwu will validate this is a reasonable approach for scaffolding. But the actual checks look good to me; we have the major checks on a JS object versus a Blob, where Blob is one of the set of legacy supported objects. Because the legacy object checks are done in C++ we don't have to worry about exhaustively testing all of the types because it's not like JS where we could be doing a check against something that ends up being undefined, etc.

Extension test lgtm (with the linting error fixed).

Thanks! Could you also uplift the change to 149 beta so that the regression does not reach release?