Related
-
Please fix the bug that causes a 1-second delay when loading the webviews
-
Sample extension to test with: Open VSX Registry
Debugging convo with Codex:
VS Code/Cursor registers an internal webview service worker using a URL like service-worker.js?..&id=.
The browser exposes the active controller as a fully resolved absolute URL, so it shows up as vscode-webview…/service-worker.js?..
The check is currentController.scriptURL.endsWith(swPath), so vscode-webview… vs service-worker.js is not the mismatch.
The mismatch is the querystring id: the page for webview 9b01… is still being controlled by the worker for webview 8379…
The key detail is that service worker control is based on scope, and the default scope comes from the script’s directory, not its querystring. MDN: the default scope is the directory where the service worker script is located. MDN register(). So two URLs like:
…/service-worker.js?..&id=A
…/service-worker.js?..&id=B
can still be in the same effective scope, while differing only by query params used as version/instance identity.
So what could be different in Cursor?
Most likely, one of these:
Cursor is keeping the previous webview controller alive longer than VS Code, so the new page starts under the old controller and waits for controllerchange.
Cursor has a webview/session/storage partition difference that delays service worker activation or takeover.
Cursor has a patch in its webview host/preload path that changes webview lifecycle timing enough to expose this race.