Investigating the root cause again,

Postman extension renders the response via monaco editor which actually uses web workers for the different resource editor, in this case it was the html.editor
Issue was happening at

vscode/src/vs/workbench/contrib/webview/browser/pre/service-worker.js

Line 235 in 9f4e94e

const client = await sw.clients.get(event.clientId);

the call couldn't find any client for the worker script
The worker resources where coming from a client whose id that was different from the frame's client id, which led me to this issue https://issues.chromium.org/issues/40525015
Before PlzdedicatedWorker, the fetch context inside workers was reusing the context of its associated frame which gets created in ServiceWorkerNetworkProviderForFrame and obtained via RenderFrameImpl::CreateWorkerFetchContext
After PlzdedicatedWorker which will begin script loading from the browser process, a separate client is created for the worker and the fetch context for the worker is associated with this client via RenderFrameImpl::CreateWorkerFetchContextForPlzDedicatedWorker

Try the demo page https://worker-client-id-demo.glitch.me/ to validate the above

#244144 attempts to adjust our service worker logic by passing the webviewId on the service worker registration url so that we can communicate with the outer iframe for the resource load, I only scoped the changes when the client is for dedicated worker or shared worker to keep the impact minimal.

Re-enable plzdedicatedworker feature #244143

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions