Webview Inset API not showing HTML

[lollobaldo]

Issue Type: Bug, can reproduce with a minimal repo on Linux and Windows.

The Webview Inset API from #85682 and #66418 does not appear to work. Here is how to reproduce:

• Create Inset with the API vscode.window.createWebviewTextEditorInset()
• Add the html with inset.webview.html = ...
• The Webview appears, but the HTML is never displayed (see black space between line 9-10)

I know it's a proposed API, so I'm running on insiders, with enableProposedApi: true. It shows the space correctly, so I don't think it's a problem on my end.
Here is the snippet I used, as well as a reproduction repository:

export function activate(context: vscode.ExtensionContext) {
  context.subscriptions.push(
    vscode.commands.registerCommand('myExtension.sayHello', async () => {
      if (!vscode.window.activeTextEditor) {
        return;
      }
      const editor = vscode.window.activeTextEditor;

      const line = editor.selection.active.line;
      const inset = vscode.window.createWebviewTextEditorInset(editor, line - 1, 10);
      inset.onDidDispose(() => {
        console.log('WEBVIEW disposed...:(');
      });
      inset.webview.html = getWebviewContent(); // Some HTML with a remote image in it
    })
  );
}

Repro: https://github.com/lollobaldo/vscode-trial

• Launch extension being developed
• Run command Inset:: Demo session: inset appears, but html is not displayed

VS Code version: Code - Insiders 1.62.0-insider (ff1e16e, 2021-10-29T07:49:33.336Z)
OS version: Linux x64 5.4.0-80-generic
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (4 x 3310)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on rasterization: disabled_software skia_renderer: enabled_on video_decode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	3, 3, 2
Memory (System)	15.06GB (0.32GB free)
Process Argv	--crash-reporter-id 5882958b-19fb-4a08-a677-622c6303708c
Screen Reader	no
VM	0%
DESKTOP_SESSION	dice
XDG_CURRENT_DESKTOP	MATE
XDG_SESSION_DESKTOP	dice
XDG_SESSION_TYPE	x11

Extensions (3)

Extension	Author (truncated)	Version
vscode-eslint	dba	2.2.2
haskell	has	1.7.1
language-haskell	jus	3.4.0

A/B Experiments

vsliv695:30137379
vsins829:30139715
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythontb:30258533
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805cf:30301675
pythonvspyt200:30323110
vsccppwt:30382699
bridge0708:30335490
bridge0723:30353136
pythonrunftest32:30365365
pythonf5test824:30361779
javagetstartedc:30350118
pythonvspyt187:30365360
vsaa593:30376534
vsc1dst:30396469
vscexrecpromptt3:30397560

[lollobaldo]

Seems to have broken with the August release 1.60.0

[Disco1267]

I can confirm the issue, in 1.62.2, Ubuntu 20.4.
The effects are:
Mark-Down Preview doesn't work
Extension: ms-mssql.mssql Query results don't show-up.
and I guess it affects a lot more.

And an error pop-up appears on the lower-left of the window, telling:

Error loading webview: Error: Could not register service workers: InvalidStateError: Failed to register a ServiceWorker: The document is in an invalid state..

[q-wertz]

Also the Latex pdf view in a VSCode tab is broken

[lollobaldo]

@jrieken happy to help if you have any idea where I should start looking

[jrieken]

I have pushed a code change that should restore insets. It's a fun issue, the API integration creates web views and uses simple number (as String) their identifiers. Those identifier are later used as iframe source (via webviewContentEndpoint), see here. It must be that the browser normalizes these urls from vscode-webview://1/index.html?foo to vscode-webview://0.0.0.1/index.html?foo so that later we fail to associated the webview correctly again (here I believe)

@mjbvz I believe we are good now but I am leaving it up to you to do some special id validation or improved parsing

[mjbvz]

Thanks @jrieken

Closing this as it sounds like the original issue has been fixed