Process explorer: update name for service worker process

[deepak1556]

Steps to Reproduce:

1. Open any webview, ex: open an extension page
2. Open process explorer
3. There will now be a window process with no associated title, it can be mistaken for workbench

Inspecting the window via remote debugging, the following are the location information

"vscode-webview://extensioneditor/service-worker.js?id=bd03d4e0-fea8-4a03-8b…de-resource.vscode-webview.net&parentOrigin=vscode-file%3A%2F%2Fvscode-app"

Service workers are also spawned as renderer processes so it would be good to differentiate them in the explorer.

[bpasero]

Yes, 💯 . I was wrongly assuming we had leaking windows when running integration tests because I saw many many windows appearing that were actually webviews.

[Tyriar]

@deepak1556 @bpasero is there anything in the command line that I can use to determine it's a service worker in a way that won't break later?

service worker:

"/Users/daimms/dev/Microsoft/vscode/.build/electron/Code - OSS.app/Contents/Frameworks/Code - OSS Helper (Renderer).app/Contents/MacOS/Code - OSS Helper (Renderer) --type=renderer --disable-color-correct-rendering --field-trial-handle=1718379636,4839957752083809804,9678658336852867050,131072 --disable-features=CookiesWithoutSameSiteMustBeSecure,SameSiteByDefaultCookies,SpareRendererForSitePerProcess,WindowCaptureMacV2 --lang=en-GB --standard-schemes=vscode-webview,vscode-file --secure-schemes=vscode-webview,vscode-file --bypasscsp-schemes --cors-schemes=vscode-webview,vscode-file --fetch-schemes=vscode-webview,vscode-file --service-worker-schemes=vscode-webview --streaming-schemes --app-path=/Users/daimms/dev/Microsoft/vscode --enable-sandbox --num-raster-threads=4 --enable-zero-copy --enable-gpu-memory-buffer-compositor-resources --enable-main-frame-before-activation --renderer-client-id=10 --no-v8-untrusted-code-mitigations --shared-files --vscode-window-config=vscode:7c3d8904-b26f-4e78-b3e6-ad1a70789c7a --seatbelt-client=100"

real window:

"/Users/daimms/dev/Microsoft/vscode/.build/electron/Code - OSS.app/Contents/Frameworks/Code - OSS Helper (Renderer).app/Contents/MacOS/Code - OSS Helper (Renderer) --type=renderer --disable-color-correct-rendering --field-trial-handle=1718379636,4839957752083809804,9678658336852867050,131072 --disable-features=CookiesWithoutSameSiteMustBeSecure,SameSiteByDefaultCookies,SpareRendererForSitePerProcess,WindowCaptureMacV2 --lang=en-GB --standard-schemes=vscode-webview,vscode-file --secure-schemes=vscode-webview,vscode-file --bypasscsp-schemes --cors-schemes=vscode-webview,vscode-file --fetch-schemes=vscode-webview,vscode-file --service-worker-schemes=vscode-webview --streaming-schemes --app-path=/Users/daimms/dev/Microsoft/vscode --no-sandbox --no-zygote --num-raster-threads=4 --enable-zero-copy --enable-gpu-memory-buffer-compositor-resources --enable-main-frame-before-activation --renderer-client-id=5 --no-v8-untrusted-code-mitigations --shared-files --vscode-window-config=vscode:7c3d8904-b26f-4e78-b3e6-ad1a70789c7a"

[bpasero]

Yeah this is really not easy to get right at the moment. It seems to me that a iframe (we no longer use webview) inherits the properties of the window it is in besides explicitly enabling sandbox.

For the shared process I use a hack to tell shared process from normal window apart:

vscode/src/vs/platform/sharedProcess/electron-main/sharedProcess.ts

Line 231 in 98b67fa

disableBlinkFeatures: 'Auxclick' // do NOT change, allows us to identify this window as shared-process in the process explorer

@deepak1556 is there any way to impact the options that are used for these processes so that we can maybe do something similar?

To clarify, we only really have the entire command line in hand when trying to figure out what the process is:

vscode/src/vs/base/node/ps.ts

Line 49 in 494cbbd

function findName(cmd: string): string {

[deepak1556]

Let me check on what parent process command lines are inherited by the out of process worker processes and see if we can control them.

For the shared process or workbench window, I would recommend to add custom command line arg that vscode can control to help distinguish via for ex:

webPreference: {
  additionalArguments: ['--shared-process']
}

[bpasero]

Yeah I can adopt that for the shared process. I just checked and when I pass additionalArguments to the workbench window, the same argument is received by the out of process worker.

[Tyriar]

I don't think I can action this yet since window kind doesn't exist on the service worker processes? lmk

[bpasero]

From my testing everything I put on the workbench window is inherited to the out of process iframe (that is what we are talking about here right?). I think we need some kind of hook to set command line arguments on those to tell them apart.

PS: the only difference is the sandbox enablement, but as we figured out is not a good hint when the workbench window is sandboxed.

[Tyriar]

If there's a way to map the PID to a friendly title on another proc that would work as well, that's how the window names come into the proc explorer:

vscode/src/vs/code/electron-sandbox/processExplorer/processExplorerMain.ts

Lines 243 to 247 in 145e380

	// Map window process pids to titles, annotate process names with this when rendering to distinguish between them
	ipcRenderer.on('vscode:windowsInfoResponse', (event: unknown, windows: any[]) => {
	this.mapPidToWindowTitle = new Map<number, string>();
	windows.forEach(window => this.mapPidToWindowTitle.set(window.pid, window.title));
	});

Alternatively, I could just show any window without a title returned above as "service-worker", but that feels like it will probably fall apart in the future.

[deepak1556]

This requires some plumbing work in the runtime, currently chromium doesn't differentiate the shared worker or service worker which are launched similar to other renderer process via command line arguments, there is lot of internal tracking involved which is what the Task Manager in chrome relies to identify and map these process PID to the correct type.

I will try to add a simple command line arguments to these worker renderers that would let us differentiate them in our process explorer, --renderer-type=service-worker, --renderer-type=shared-worker.