The browser.tabs.remote.autostart pref can be set to false to disable e10s.
While it defaults to false, it is true in practice:

• In Firefox
• In GeckoView (bug 1650118)
• And even in Thunderbird (bug 1671301)

The only active user of this pref are some xpcshell tests. The pref is always set too late, so this doesn't ever work actually: When BrowserTabsRemoteAutostart() is called, the pref is read once and the result is cached. In xpcshell tests, prefs are set at runtime, either in head.js (that reads from user.js) or in the extension tests' head.js. But xpcshell tests already initialize BrowserTabsRemoteAutostart() before the prefs are read. Currently the following callers are triggered before the prefs are read:

• Added in bug 1582512 (2019): XPCJSRuntime::Initialize calls XRE_IsE10sParentProcess() which in turn calls BrowserTabsRemoteAutostart()
• Added in bug 1178274 (2015): XRE_XPCShellMain calls BrowserTabsRemoteAutostart() directly.

I also checked the effectiveness of the pref in non-xpcshell tests, by initializing a directory with a user.js containing user_pref("browser.tabs.remote.autostart", false); and running Firefox with it (from Treeherder, because the pref is disabled in official Firefox builds), but according to about:support e10s is not disabled. I also tried a local build with the same effect: ./mach run --temp-profile --setpref=browser.tabs.remote.autostart=false (I didn't check, but I guess that prefs might be read after JS initialization?)

Since the pref cannot be disabled via xpcshell tests, I suggest to remove it altogether. It would still be possible to disable e10s, via MOZ_FORCE_DISABLE_E10S.

Setting browser.tabs.remote.autostart to false and then loading https://lab.allotropia.de/wasm crashes the browser instantly (m-c of 14 Oct 2022, on Linux). This is disconcerting to say the least and I spent a couple of hours chasing it, thinking it was a SM/wasm bug. So +1 for removing it entirely.

https://hg.mozilla.org/mozilla-central/rev/ddc3d1e9268d