是的，100%。我错误地假设在运行集成测试时我们有泄漏的Windows，因为我看到许多许多Windows出现，实际上是webviews。

@deepak1556@bpasero 是否有命令行中的任何内容可以让我以某种方式确定它是一个服务工作者，而不会破坏以后的兼容性？
服务工作者：

"/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"

实际窗口：

"/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"

是的，目前这确实不容易做到。在我看来，一个 iframe (我们不再使用 webview )继承了 window 的属性，除了显式启用沙箱之外。
对于共享进程，我使用了一个技巧来区分共享进程和普通窗口：
vscode/src/vs/platform/sharedProcess/electron-main/sharedProcess.ts
第 231 行的 98b67fa
| | disableBlinkFeatures: 'Auxclick'// 不要更改，这允许我们在进程资源管理器中将此窗口识别为共享进程 |
@deepak1556 是否有办法影响这些进程使用的选项，以便我们可能做类似的事情？
澄清一下，当我们试图弄清楚进程是什么时，我们手中只有整个命令行：
vscode/src/vs/base/node/ps.ts
第 49 行的 494cbbd
| | functionfindName(cmd: string): string{ |

让我检查一下父进程的命令行参数是否被子进程继承，看看我们是否可以控制它们。对于共享进程或工作台窗口，我建议添加一个自定义命令行参数，以便VS Code可以通过它来区分，例如：

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

是的，我可以将该方法应用于共享进程。我刚刚检查了一下，当我将 additionalArguments 传递给工作台窗口时，相同的参数也会被进程外的工作器接收到。

你好，我理解你的问题。这句话的意思是“我认为我不能立即采取行动，因为窗口类型在服务工作进程中不存在”。这句话可能是在使用Windows操作系统时遇到的错误消息。如果你能提供更多上下文或信息，我可以更好地帮助你解决这个问题。

从我的测试来看，我放在工作台窗口上的所有内容都会继承到外部进程的iframe(这就是我们在这里讨论的内容，对吧？)。我认为我们需要某种钩子来设置命令行参数，以便将它们区分开。
附注：唯一的区别是沙箱启用状态，但正如我们所发现的，当工作台窗口被沙箱化时，这不是一个好的提示。

如果有一种方法可以将PIDMap到另一个进程上的友好标题，那也是可行的。这就是窗口名称如何在proc explorer中显示的方式：
vscode/src/vs/code/electron-sandbox/processExplorer/processExplorerMain.ts
第243行到第247行
| | // 将窗口进程pidMap到标题，在渲染时使用此注解来区分它们 |
| | ipcRenderer.on('vscode:windowsInfoResponse',(event: unknown,windows: any[])=>{ |
| | this.mapPidToWindowTitle=newMap<number,string>(); |
| | windows.forEach(window=>this.mapPidToWindowTitle.set(window.pid,window.title)); |
| | }); |
或者，我可以直接显示上面没有标题的任何窗口为“service-worker”，但这感觉将来可能会出问题。

这需要在运行时进行一些管道工作，目前Chromium无法区分共享工作者或服务工作者，它们通过命令行参数启动，类似于其他渲染进程。有很多内部跟踪involved,这就是Chrome中的Task Manager用来识别和Map这些进程PID到正确类型的方法。
我将尝试为这些worker渲染器添加一个简单的命令行参数，这样我们就可以在我们的进程资源管理器--renderer-type=service-worker、--renderer-type=shared-worker中区分它们。