feat: UtilityProcess API

[deepak1556]

Description of Change

Electron applications which run complex Node.js services outside the main process and have necessity to communicate with the renderer process, did it in either of the two ways,

(i) Fork a child process from the renderer via child_process.fork and establish a direct communication channel via Node.js sockets.
(ii) Fork a child process from the main via child_process.fork and establish a direct communication channel via Node.js sockets.

If the renderer is sandboxed, then (i) is not possible and with (ii) a direct socket connection cannot be established with the renderer instead messages have to be routed via the main process. In #22404 we tackled the use case of an application using a renderer process in the background to perform cpu intensive work or isolate crash prone components and allowing the capability to communicate with a sandboxed renderer using MessageChannel.

This PR is inspired by that change and introduces a new module UtilityProcess in the main process that allows creating light weight chromium child process with only Node.js integration while also allowing to communicate with a sandboxed renderer using MessageChannel. The API was designed based on Node.js child_process.fork to allow for easier transition with one primary difference being that the entry point modulePath must be from within the packaged application to allow only for trusted scripts to be loaded unlike the Node.js version which can load from arbitrary location.

Additionally the module upholds the contract that main process is the only trusted process in the application by not allowing to establish communication channels with any renderer in the application by default. Instead the main process is responsible for creating the desired communication channel and sharing the endpoints to the respective child processes.

Example Usage:

main.js

const w = new BrowserWindow({
        webPreferences: {
          sandbox: true,
          preload: path.join(fixturesPath, 'preload.js')
        }
});

// Create Message port pair for Renderer <-> Utility Process.
const { port1: rendererPort, port2: utilityPort } = new MessageChannelMain();
// Send rendererPort to the sandboxed render process
w.webContents.postMessage('port', null, [rendererPort]);
// Create utility process
const child = utilityProcess.fork(path.join('path-in-application-package', 'worker.js'));
// Send utilityPort to the utility process
child.on('spawn', () => {
  child.postMessage('', [utilityPort]);
});
// Utility process can also send messages to the main process via process.parentPort
// We can listen to them via
child.on('message', (data) => {
  console.log(`MESSAGE FROM CHILD: ${data}`);
});
// Child process emits exit event on termination
child.on('exit', (code) => {
  console.log(`CHILD EXITED WITH CODE: ${code}`);
});

preload.js

const { ipcRenderer } = require('electron');

ipcRenderer.on('port', (e) => {
  e.ports[0].postMessage({ data: [...] });
  e.ports[0].on('message', ({data}) => {
     // ... do something with data from the worker process ...
  });
});

worker.js

let rendererConnection = null
process.parentPort.on('message', async (e) => {
  rendererConnection = e.ports[0];
  beginWork(e.data);
});

function beginWork(toProcess) {
  // After work
  rendererConnection.postMessage({ result });
}

Future Work:

• Allow sandboxing the utility process, it is possible to specify the type of sandbox for the utility process when launching it content::UtilityProcessHost::SetSandboxType but it is currently restricted to set of predeclared options. I need to explore how much an embedder can extend the chromium sandbox without any serious patches and think about what level of control we can give to users. An usage example for this would be like, utility process that only performs file I/O can declare a sandbox that disallows network and child_process creating syscalls. Given the complexity of this feature, I don't plan to tackle it in this PR.

• Would an options to create utility process with just v8 be of any interest ? (i-e) no Node.js integration, no blink integration just vanilla v8

• Expose Deno integration with utility process ???

Release Notes

Notes: Added new UtilityProcess API to launch chromium child process with node integration

[nornagon]

🤔 It could be interesting to allow users to sandbox their utility processes to various degrees!

[deepak1556]

Agreed, I was also hoping to expose this but current content API is not flexible and extracts the value from mojom parameter. If we can add a small patch then we can make the sandbox property configurable https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/service_process_host.h;l=141-158.

Also need to think about which ones are supported via this API from the list https://source.chromium.org/chromium/chromium/src/+/main:sandbox/policy/mojom/sandbox.mojom, we would also need to document what syscalls are allowed/disallowed, paths accessible for each of the type to make this API understandable.

[nornagon]

I wonder if we could provide full control over the sandbox? Maybe not that useful... but interesting! e.g. allow the app to specify individual paths/libraries/syscalls etc to allow.

[nornagon]

@deepak1556 it would be great to get an expanded explainer for this! Adding wip to drop from the API review queue pending that :)

[deepak1556]

Sorry I was planning to update before requesting review, will address it today.

@nornagon updated the explainer section, PTAL. Thanks!

[samuelmaddock]

API LGTM

[nornagon]

Also, I don't want to miss @erickzhao's comment that we should add more documentation for this in our guides about process types.

[deepak1556]

Thank you for taking the time to do a thorough review of this change!

I don't want to miss @erickzhao's comment that we should add more documentation for this in our guides about process types.

Yup definitely, I will address it before merging the PR.

[deepak1556]

Have created #36074 as follow-up for the docs change. Allows for easier reivew, I will merge this PR today once build is green.

[deepak1556]

Failing test is unrelated and is also flaky on main branch, merging.

[release-clerk]

Release Notes Persisted

Added new UtilityProcess API to launch chromium child process with node integration

[trop]

I was unable to backport this PR to "21-x-y" cleanly;
you will need to perform this backport manually.

[trop]

I have automatically backported this PR to "22-x-y", please check out #36089