Can't reproduce this issue in the markdown preview with current VS Code insiders on MacOS 10.15.2

What MacOS version?

I'm also on 10.15.2. Oddly enough, I just attempted to reproduce it again with markdown preview and it's working as expected.

Ok, closing as not-reproducible

It's still an issue for the codestream extension though

How can I easily test that?

Just install the extension and the webview should open immediately once installed. If it doesn't, use the CodeStream: Sign in command in the palette. Then reload the window

I don't see the web view getting restored at all (no errors or anything). Does it have a serializer?

Sorry, we just only re-display the webview if you're already logged in. We don't use a serializer.

I've made a video reproducing it. It starts with the webview displayed correctly, I open up the dev tools and inspect the uri for the js we load, then reload the window. On reload, the webview panel is displayed again but left blank and in the webview dev tools, you'll see the error. The requested uri is still correct though. Then I'll close the corrupted webview and re-open it, and it works correctly again.

I've now also seen this but only when the dev tools were open (on the main VS Code window)

I'm seeing this happen pretty often as well. Let me know if there's any info I can get for you

@mjbvz - Has this been attached to a future milestone yet? We're trying to find workarounds on our end but right now this is having a huge impact on our customers' experience.

No but since you can reproduce this reliably, it would be good if you could try investigating what's going wrong:

• Place where we create webview elements:

  vscode/src/vs/workbench/contrib/webview/electron-browser/webviewElement.ts

  Line 212 in 4270786

  export class ElectronWebviewBasedWebview extends BaseWebview<WebviewTag> implements Webview, WebviewFindDelegate {

• Place where we register the protocol:

  vscode/src/vs/workbench/contrib/webview/electron-browser/webviewProtocols.ts

  Line 10 in 4270786

  export function registerFileProtocol(

It should wait until the protocol is registered before sending over the html but something is failing (possibly on the electron side)

@mjbvz At the point where registerFileProtocol() is called there is no await or callback. The code directly resolves the ready promise:

registerFileProtocol(contents, WebviewResourceScheme, fileService, getExtensionLocation(), getLocalResourceRoots);
this._resolve();

The registerFileProtocol calls in electron should now be synchronous, see #92138

@mjbvz while registerFileProtocol is synchronous, what about the function it calls registerBufferProtocol? it has an async callback with what appears to be some kind of success check. Would this._resolve() need to be called inside registerBufferProtocol's callback? pseudo code below:

registerFileProtocol(contents, WebviewResourceScheme, fileService, getExtensionLocation(), getLocalResourceRoots, () => this._resolve());

export function registerFileProtocol(
	contents: electron.WebContents,
	protocol: string,
	fileService: IFileService,
	extensionLocation: URI | undefined,
	getRoots: () => ReadonlyArray<URI>,
        onRegistered: () => void // new arg
) {
	contents.session.protocol.registerBufferProtocol(protocol, async (request, callback: any) => {
		try {
			const result = await loadLocalResource(URI.parse(request.url), fileService, extensionLocation, getRoots);
			if (result.type === WebviewResourceResponse.Type.Success) {
                                 // new code
                                if (typeof(onRegistered) === 'Function') {
                                     onRegistered();
                                 }
				return callback({
					data: Buffer.from(result.data.buffer),
					mimeType: result.mimeType
				});
			}

This one should also be async now, see https://www.electronjs.org/docs/api/breaking-changes-ns#planned-breaking-api-changes

The other callback ( async (request, callback: any)) is the handler for requests themselves once they come in

This is one of the changes mentioned in that doc:

The registered or intercepted protocol does not have effect on current page until navigation happens.

Just a hunch: Could it be that navigation is sometimes being triggered before the registration is started? (I couldn't find the relevant code)

We also get this issue with my Dashboard extension, which uses a webview for a custom UI. Reopening the webview solves the problem.

Kruemelkatze/vscode-dashboard#35.

I just noticed the same issue while updating two of my extensions. I'm with VS Code 1.45 Stable and VS Code 1.46 Insiders, on MacOS. Loading on Windows, worked perfectly.

The failed resources are a css and a png file I use. Another remote png loads fine.

But, it only happens when the WebView is loaded at extension's activation, with in my case is defined as activationEvents: *. If I close the WebView and call it again, it works.

It's a bit weird, because I have the same WebView on other extensions and it is working fine. I thought it could be something related to recent updates I made on this Webview, but if I install older versions of the same extension (using the VS Code Extension feature), it also fails.

Just noticed I didn't embrace https://code.visualstudio.com/updates/v1_39#_warning-if-webviews-dont-use-webviewaswebviewuri-for-local-resources yet. I'm still loading local resources using { scheme: "vscode-resource" }. Could it be connected somehow?

I'll try to update, and post here if something new appear.

Unfortunately, didn't work 😞 .

At first it appeared ok, but after a few retries, the issue reappeared. It's instable, at least.

Just out of curiosity, using scheme: "vscode-resource" gives me this:

<img src="vscode-resource:/thePath/vscode-readme.png">

Using asWebviewUri has a slight different syntax:

<img src="vscode-resource://file///thePath/vscode-readme.png">

I hope the above PR should solve this, and be released as an patch to 1.45.

Thank you

@mjbvz does it have to be new vscode-webview-resource protocol?

Even if that pull request fixes things, it would still require all extension authors to update their extensions for the broken vscode-resource loading on reload.

@RandomFractals Yes. Extensions that use asWebviewUri will just automatically start using the new protocol. The PR also tries to rewrite any hardcoded vscode-resource uris (which have been deprecated for a while since they also don't work on web)

Had to revert this fix due to #98768

Will revisit for June

@mjbvz If you need to test with extensions for testing/reproduction, you can use mine. Just create a simple .py file :

print("ok")

and press Ctrl+Alt+B. It should open a web view ( which is a React App ), and the react script sometimes fails to load with Failed to load resource: net::ERR_UNKNOWN_URL_SCHEME error.

I have not seen this in the last few weeks working on webview debugging or reproduce it as I used to be able to, thus marking verified.