Adopt utility process for shared process and file watchers

[bpasero]

This is a follow up from #92164 and covers remaining work to eventually enable sandboxed renderers fully in Electron via app.enableSandbox().

This means that our shared process has to move away from a node.js enabled browser window to the new utility process.

Breaking down the usages today:

• extension management
• settings sync
• profiles
• terminals
• file watcher

Some initial thoughts:

• the shared process should probably just change to be a utility process as a first step
  • however, any code that relies on the browser window network stack instead has to leverage Electrons net APIs from the electron-main process to not loose proxy support
  • this can probably be done by implementing some kind of IRequestService that is backed by a main process service implementation
• any child process has to decide whether it wants to lift up to a utility process off the main process or remain inside the shared process

//cc @alexdima

[sandy081]

settings sync is safe to be removed as it does not use any non sandbox stuff like node apis.

[bpasero]

To clarify: we can still have a shared process in the end, I do not have strong feelings, but it would be node.js only and not electron browser enabled. I think the benefit of having another process offload work from the main process is still valid.

[sandy081]

One concern I have with shared process not having electron browser enabled is the network proxy and If we can enable request service to redirect to main as you mentioned, this shall be fine. But I am wondering how much load we gonna put on main and if that impacts perf.

[bpasero]

As far as I know, network load is handled from another utility process, so I think that should be fine, right @deepak1556 ?

[deepak1556]

Yes that is correct, the main process is only responsible for initiating the request from the JS thread, the actual work is done by the network utility process.

[Tyriar]

For the terminal part in shared proc, it just passes manages the pty host process and passing requests to/from it, so good there.

#153182 seems like a blocker to enabling utility processes though.

[bpasero]

@Tyriar does #133895 still apply?

[Tyriar]

@bpasero I think so, but #153182 was happening with a single window

[bpasero]

Sorry for the confusion, I was not suggesting the issues are related, rather was wondering if moving to utility process would help for #133895

[Tyriar]

Oh, I haven't looked at any of the utility process stuff yet, so not sure what the difference between a regular node (pty host now) and utility processes are. If the pty host was a utility process off the main process would I be able to setup direct comm channels between the renderer and the pty host?

[bpasero]

@Tyriar yes that is the idea, in short:

• a utility process is a new electron main process API similar to cp.fork (created by Deepak)
• you get a full node.js environment within the utility process and can even further fork child processes
• you can send a message port into the utility process and have the other end connected to a renderer
• you can then transfer data exclusively between utility process and renderer

(the extension host has adopted and is validating this approach in insiders)

[bpasero]

I think you can even keep having a PTY host (as a utility process) and then child processes for each terminal, but I would then do 1 message port per window to offload communication.

@deepak1556 just wondering: can I send a message port further down to child processes to even offload work from the utility process or is the message port limited to operating only from the utility process?

[Tyriar]

Sounds great! 🙂

[deepak1556]

Message port is limited to operating only from the utility process. I would prefer to keep it this way since otherwise we could have untrusted child processes talking directly to the renderer and serves as a way to break out of the renderer sandbox.

[sandy081]

Reverted request service in shared process to use browser XHR because of the bug #155204

[bpasero]

Since the request service issue has been addressed, I am starting to work on this for January. I already figured out that the file watcher has to move out of the shared process into its own utility process. @Tyriar I will let you know how that work progresses because I feel once I made the move, PTY host should also move out and by then I am hopefully having a set of utilities in place to make the adoption easier. I am building on top of the code from AlexD used for the extension host.

[bpasero]

Some initial work landed on main and setting window.experimental.sharedProcessUseUtilityProcess to true will have the shared process run from a utility process, same as the file watcher.

There are some issues with integrated terminal that I cannot reproduce running out of sources but appear in the built version. But I was able to browse and install an extension.

[bpasero]

Terminal works as well now! It was just an issue where we passed an unsupported execArgv to node.js via fork but took me days to actually find 🚀

#174852

[bpasero]

I will close this one out for Feb since the significant portion of the work has already happened. Will create a new issue for moving terminals out, but for now they coexist as before.