我试图通过发送来拦截 WebWorker 请求Fetch.enable在工作目标会话中，但得到了"'Fetch.enable' wasn't found"来自 Chromium 的错误。这是否意味着 Chromium 不支持 WebWorker 请求拦截？我的铬版本是97.0.4691.0 (Developer Build).
合理的答案将不胜感激。
- 更新 -
我想我已经以木偶师的方式工作了。请查看我的修复kitt1987/木偶师 https://github.com/kitt1987/puppeteer/commit/dddff4aed4f2241832e620b1cd6811da7394dfca。只是一个快速修复，没有精心设计。
TL;NR
实际上，我使用 puppeteer 拦截了一个网站的请求。然后我发现这个网站请求了WebWorker中的一些文件，但是如果启用拦截，puppeteer就会出现bug。看傀儡师/傀儡师#4208 https://github.com/puppeteer/puppeteer/issues/4208 and 傀儡师/傀儡师#2781 https://github.com/puppeteer/puppeteer/issues/2781.
在深入挖掘 puppeteer 源代码并跟踪原始协议消息后，似乎调用page.setRequestInterception(true)也拦截WebWorker请求，但是这些请求从不发出任何Network.requestWillBeSent events，这被称为page.requestpuppeteer 中的事件，然后 WebWorker 请求挂起以等待request.continue()这通常被称为page.request事件处理程序。
然后我试图找出原因Network.requestWillBeSent事件丢失了。 Chrome DevTools 能够跟踪其网络面板中的所有请求，然后我分析了其 CDP 流量协议监视器 https://developer.chrome.com/blog/new-in-devtools-92/#protocol-monitor并发现一个新的WebWorker启动了一个新的会话，它需要发送Network.enable再次在新会话中启用网络跟踪。但是，在我发送之后Fetch.enable在新会话中启用拦截时，出现了错误。
puppeteer:protocol:SEND ► {"sessionId":"3DE89BAC041203C90EF1B3D2CC348EAA","method":"Fetch.enable","params":{"handleAuthRequests":true,"patterns":[{"urlPattern":"*"}]},"id":245} +0ms
puppeteer:protocol:RECV ◀ {"id":245,"error":{"code":-32601,"message":"'Fetch.enable' wasn't found"},"sessionId":"3DE89BAC041203C90EF1B3D2CC348EAA"} +0ms
你可以找到我的修复kitt1987/木偶师 https://github.com/kitt1987/puppeteer/commit/b40729d53984b920a951975c145f38a3a9b8bd13.
