WebViews that use iframes frequently fail to load in v1.140

Since updating to v1.140, the Dart extension's sidebar webviews are failing to load almost every time, instead just rendering a grey block:

There are a few warnings in the console, but nothing that seems fatal. There is a pane-body element in the DOM where I presume the frame should be:

I tested loading this 10 times in portable versions of both 1.139.1 and 1.140.0 and the results were:

1.139.1: 10/10 loaded correctly
1.140.0: 2/10 loaded correctly, 8/10 showed the grey box

I added some logging in the code that creates the iframe inside our webview and sets its src, and I can see that this code is still running, despite the iframe not being visible in the DOM:

I'm not sure how to debug any further. From the extensions perspective, everything looks the same, including the fact that the scripts we injected into the webview are running and setting the src of an iframe inside.

I've been testing activity bar views today on 1.141.0-insider and haven't noticed any issue, so this might have been already fixed (intentionally or not).

There have been a lot of memory leak-related fixes as far as I can see, and it might have happened one of them messed up webviews. In the past a memory leak fix broke editor actions for example.

Unfortunately not, still seeing it:

Version: 1.141.0-insider (user setup)
Commit: ec2e580674cdb512aa9b2a9596ab35d8a9590f1e
Date: 2026-10-01T04:00:54Z
Electron: 43.7.3
ElectronBuildId: 15386805
Chromium: 150.0.7871.250
Node.js: 24.21.0
V8: 15.0.245.31-electron.0
@github/copilot: 1.0.90
@github/copilot-sdk: 1.0.16
OS: Windows_NT x64 10.0.26200

I have the same problem here! 😠

What happens if you move the section to a different sidebar? E.g., from left to right by dragging it? The provider should be called again.

I already did it and not works. =(
Property Editor also breaks.

I wonder if this might be similar/related to #125993 (or the same, but the error just presents itself differently now). Like that issue, I've noticed that when this is broken, it's broken until I restart VS Code. When it works first time, it ends to continue to work for that VS Code session.

Edit: Interestingly, if I delay setting the src of our embedded iframe for 5s, then the webview is black for 5s, then turns grey. So it appears to be something in the loading of the embedded page that is causing it, not just the webview itself. The page we're loading (Flutter DevTools) uses WASM and I think cross-origin isolation - I wonder if either of these could be the trigger. It's odd that I can't find the iframe at all in the dev tools though.

Edit: Although I can't find it in the DOM or select it with the picker, the iframe is visible in the drop-down in the console, and I can find the element there, and it does seem to have a sensible width/height too.

Guys for now I downgrade to VsCode to 1.139.1 version.
It works untill this issue can be solved in next updates.
https://code.visualstudio.com/updates/v1_139

close VsCode
download VsCode 1.139.1 and install
run debug to test

x64 - https://update.code.visualstudio.com/1.139.1/win32-x64-user/stable
Arm64 - https://update.code.visualstudio.com/1.139.1/win32-arm64-user/stable

Interestingly, I've found that if I target the webview frame in the console and then run:

document.getElementById('devToolsFrame').srcdoc = 'Test';
document.getElementById('devToolsFrame').removeAttribute('srcdoc');

Then everything loads correctly. I don't understand why it fails the first time (even after a 5s delay, so it's clearly not a race with the webview becoming visible).

Robo (@deepak1556)

Robo (@deepak1556) I think this is due to the Electron update in #336697. The same DevTools iframe loads on Electron 43.6.0 but crashes on 43.7.3 when using WASM.

Robo (@deepak1556)

Robo (@deepak1556) unfortunately neither of those made any difference (assuming I'm testing them right... oddly, launching Code with the exe in this way kept the process running after I closed the VS Code window and I had to press Ctrl+C.. not sure if that's expected).

Testing with VS Code 1.40 portable:

.\Code.exe 'D:\Dev\Test Projects\flutter_counter_basic\'

Fails: 5
Successes: 0

.\Code.exe --js-flags="--no-wasm-tier-up" 'D:\Dev\Test Projects\flutter_counter_basic\'

Fails: 5
Successes: 0

.\Code.exe --no-cached-data 'D:\Dev\Test Projects\flutter_counter_basic\'

Fails: 5
Successes: 0

btw, I don't know if it's consistent, but having the developer tools open seems to either stop the issue, or at least reduce the chance of it happening (this was also noted by another user at Dart-Code/Dart-Code#6209 (comment)).

Having the same issue. I can confirm that having the developer tools open before the webview renders will make them render properly. As soon as I close the developer tools, the next update on the webview causes it to go blank gray again.

Another data point, possibly the same regression, this time with a webview panel in the editor area (not the sidebar): a web extension (only a browser entry, so on desktop it runs in the local web worker extension host) with a scripted webview (enableScripts, module script via asWebviewUri, blob: workers, WebAssembly GC). Same extension build, same Electron/Chromium 150:

VS Code desktop 1.139.1: works (Windows, Linux).
VS Code desktop 1.140.0: on Windows the panel stays gray (local window and Remote-SSH); reproducible headless on Linux with @vscode/test-electron + xvfb-run + --extensionDevelopmentKind=web (the webview's self test never completes).
VS Code for the Web 1.140 (vscode.dev, @vscode/test-web with Chromium and Firefox): works.

What we checked on 1.140.0 desktop: webview resources load (200), the service worker registers, scripts run and postMessage reaches the extension when the extension runs in the Node host; a stable viewType does not help; asset bytes are identical; JS recursion depth is the same as on 1.139.1. The first failure we can see headless is inside a long-running WebAssembly computation in a blob: worker started from the webview (it throws, and restarting the worker then hangs). Happy to share a minimal repro if useful.

Sorry for the delay, this should now be fixed with #339634 in our latest insiders. The issue was indeed related to the wasm exception due to tier up compilation, the grey panel was from crash iframe process (confirmed with minidump). --no-wasm-tier-up disabled eager tier up but there was another path to tier up dynamically based on budget hence it didn't help, running with --js-flags="--liftoff-only" should have confirmed it instead.

Robo (@deepak1556)

In a quick test in Insiders, this does indeed appear fixed. Thanks Robo (@deepak1556)!

25. In a quick test in Insiders, this does indeed appear fixed. Thanks Robo (@deepak1556)!

I still have this bug, i needed to downgrade my vscode version from 1.141.1 to 1.139.1 because claude and codex cli weren't working in side bar

Webview renderer did not become ready ... renderer_ready_timeout (30000ms).

Diony Rinker (@yDiony)

Diony Rinker (@yDiony) I have commented on your issue, its from a different root cause.

Navigation Menu

Repository navigation

WebViews that use iframes frequently fail to load in v1.140 #339079

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

WebViews that use iframes frequently fail to load in v1.140 #339079

Description

Activity

lppedd commented on Oct 1, 2026

DanTup commented on Oct 1, 2026

digitalprobr commented on Oct 1, 2026

lppedd commented on Oct 1, 2026

digitalprobr commented on Oct 1, 2026

DanTup commented on Oct 1, 2026

digitalprobr commented on Oct 1, 2026

DanTup commented on Oct 1, 2026

benibenj commented on Oct 2, 2026

4 remaining items

DanTup commented on Oct 2, 2026

DanTup commented on Oct 2, 2026

kdaker commented on Oct 3, 2026

elkasab99 commented on Oct 3, 2026

deepak1556 commented on Oct 5, 2026

DanTup commented on Oct 5, 2026

yDiony commented on Oct 14, 2026

yDiony commented on Oct 14, 2026

deepak1556 commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions