Webviews blank in second IDE window - possibly service worker issues

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I maintain a VS Code extension with several webviews (sidebar views + editor panel). In Cursor, opening a second window while the first is still open (and webviews are open in that first window) often leaves webviews blank for a long time (2-5 minuites) before rendering suddenly starts working.

The same extension works normally in VS Code and Antigravity and has no issues rendering in multiple instances at once.

The rendering is not per-window instance, but per webview/panel. So if i have two instances i can open panel A in one, and panel B in another. But opening the same panel in different window struggles to render and stays fully blank.

Closing the first (working) window instantly renders all the blank webviews in window 2.

Some additional notes and logs:

In webview DevTools → Network: index.html loads immediately; fake.html is delayed until the stall clears, then everything renders. I.e. when closing the other window.

Debugging have lead me to console.log output like:

Found unexpected service worker controller. Found: …/service-worker.js?…&id=<uuid-A>…
Expected: …/service-worker.js?…&id=<uuid-B>…
Waiting for controllerchange.

This log is not appearing in neither VSCode or Antigravity.

A theory is screenshotted and attached, but i am not knowlegable enough to debug further/solve it.

Finally i want to add that this extension is quite extencive and uses React and communication with localhost apis etc. I have tried to slim it down to try to resolve, but it did not work. However creating a fully fresh extension with just simple HTML content did solve the issue i think. So some sort of resource exhaustion in the service workers/webview renderers could be likely i guess.

Steps to Reproduce

I understand that it might not be the best to link to an extension, but reproducing using this works:

Use the Mangabey.distinct-sh and follow:

Steps to reproduce:

  1. Window 1: open extension webviews (for example Schema Explorer panel).
  2. Open a second Cursor window while window 1 stays open.
  3. Webviews in window 2 stay blank.
  4. Close window 1 and see the rendering in window 2 suddenly appear.

Expected Behavior

Webviews render within a few seconds (as in VS Code / Antigravity) in each IDE instance.

Screenshots / Screen Recordings

All DISTINCT webviews from your install share one Chromium origin.png
All DISTINCT webviews from your install share one Chromium origin.png823×349 47.5 KB

Operating System

MacOS

Version Information

Version: 3.7.36
VS Code Extension API: 1.105.1
Commit: 776d1f9d76df50a4e0aeca61819a88e7c1b861e0
Date: 2026-06-13T00:31:56.287Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Here is a screenrecording of the issues. As you se, releaseing the views in the leading window makes them render in the other.

6

Hey, thanks for the report. We don’t often get such a detailed write-up with logs, a repro extension, and a video. I saw the screenshot about the shared Chromium origin and the controller handshake, plus the recording where the panels in the second window render right after the first window closes.

Your theory looks solid. The same panel in two windows may resolve to the same vscode-webview:// origin and the same service worker scope. That could explain the Waiting for controllerchange that hangs while the first window’s clients are still alive. The fact that this doesn’t happen in VS Code and Antigravity is also an important signal. I’ll take this to investigate and try to reproduce it with distinct-sh.

One thing that would help narrow it down: what Electron and Chromium versions are in the VS Code and Antigravity builds where this doesn’t reproduce? You can find it in Help > About or the equivalent. That’ll help confirm whether this is just a Chromium base version difference.

I can’t share an ETA yet, but I’ll post an update in the thread as soon as I have one.

7

Thanks for the swift reply!

Yeah, i have spent quite some hours (and tokens hehe) trying to understaand this but don’t get it and the logs are so limited here…

I tested with these versions:

VSCODE:

Version: 1.124.2 (Universal)
Commit: 6928394f91b684055b873eecb8bc281365131f1c
Date: 2026-06-12T00:12:36Z
Electron: 42.2.0
ElectronBuildId: 14159160
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Darwin arm64 25.6.0

Antigravity:

Antigravity IDE Version: 2.0.4
VSCode OSS Version: 1.107.0
Commit: def9583aef9852ff94cb0dea16ede9bb6b095b30
Date: 2026-06-02T00:22:56.234Z
Electron: 39.2.3
Chromium: 142.0.7444.175
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin arm64 25.6.0
Language Server CL: 924974766

8

Thanks for the version dump, that actually helps narrow things down a lot.

Interesting detail: both Cursor and Antigravity are currently on Chromium 142 (142.0.7444.x), but the bug doesn’t reproduce in Antigravity, and only VS Code moved to Chromium 148. That pretty strongly rules out my original idea of a Chromium version difference. If it was only that, Antigravity on 142 would also fail. So the delta is more likely in the VS Code base version (Antigravity is on VSCode OSS 1.107.0, we’re roughly on 1.105.x) or in something Cursor-specific around the webview or service worker.

I’m going to keep digging and I’ll try to reproduce using distinct-sh with your steps. I can’t give an ETA yet, but I’ll post an update here as soon as I have one. Thanks for writing everything up so clearly, the repro extension and the video really speed this up.

9

Quite sure that this issue is somwhat related to/in the same realm as the current topic:

The webviews in my extension are quite big in terms of size and rendering etc. React app with alot of contexts, webview messages etc. Possibly performance is somehow what makes this really slow. As mentioned before the views do appear, but that is after something like 2-5 min. Maybe that is some timeout or something.

However i do not see any performance issues in VSCode or Antigravity as mentioned above.

Might be useful, idk.

10

Hey, thanks for adding the context. I’d keep these two things separate for now.

The thread about the 1-second delay (154788) is about an upstream delay when loading the webview, which was fixed in the base VS Code around 1.102. You’re already on 1.105, so you should have that specific fix.

What you’re seeing looks like a different issue: a blank screen for 2 to 5 minutes specifically when the same panel is open in two windows, plus instant render when you close the first window, and Waiting for controllerchange in the logs. That sounds more like service worker controller contention, not the webview size itself. A heavy React app can make it worse, but the trigger here is having the same panel in two windows, not size by itself. Otherwise it would be slow even in a single window.

I’ll keep digging and try to reproduce it on distinct-sh using your steps.