Webview Doesn't exist in Electron Instance

[lucas-phillips]

Description

I'm getting a 404 error when opening a webview vscode extension in an Electron instance of Theia. This only happens in the Electron instance. When I open the webview in the browser, everything works just fine.

Reproduction Steps

I downloaded the latest version of Theia. I then cloned this repo into the plugins folder: https://github.com/leocll/vscode-extension-webview-template (If I loaded with a VSIX, a webview panel wouldn't even open, the extension just did nothing, but I believe it may be an issue with the VSIX he uploaded to the marketplace.) After cloning the repo and running Theia, I ran the command "Example: Webview", which resulted in this:

(Text says: "Not Found. HTTP Error 404. The requested resource is not found" for those that don't like reading black on dark gray text :D)

Thanks for any help you can provide!

[vince-fugnitto]

I tried using the vscode-extension-samples webview-sample and it also did not work correctly in Electron. When testing it on the browser it worked correctly.

[marcdumais-work]

@akosyakov Any insights about this issue? Did you have the chance to investigate when you self-assigned? I see absolutely no errors anywhere, just a black view, as per the screenshot above.

[akosyakov]

@marcdumais-work Unfortunately not, we don't have capacity at TypeFox for it. I think someone who build Electron products should step up here. Important thing that we should not rely on Electron tech.

[vince-fugnitto]

I did some quick tests to try and identify the issue and I noticed one anomaly when in electron.
I verified the behavior of the cat-coding webview sample in both the browser and electron and noticed that the method loadResource is called on the browser but never electron:

theia/packages/plugin-ext/src/main/browser/webview/webview.ts

Line 421 in 09d90c4

protected async loadResource(requestPath: string): Promise<void> {

The result is that I see a blank webview on electron.

I wonder if the WebviewChannels are not properly communicating, I don't understand the webview code completely at the moment but I will keep investigating in the hopes of getting it to work. I've also noticed that vscode uses webviews and not iframes to render webviews in electron, but even when I modified vscode sources to use iframes the webviews were still properly rendered.

If others have some ideas please don't hesitate to reach out.

[akosyakov]

There is a service worker that intercept requests from webview iframe and dispatch to the main window. Could you check that such service worker is running? If not why, if so then you can debug while it does not dispatch.

[vince-fugnitto]

There is a service worker that intercept requests from webview iframe and dispatch to the main window. Could you check that such service worker is running? If not why, if so then you can debug while it does not dispatch.

Thank you for the pointers @akosyakov, through logging I actually do not see the service-worker running on electron, but it is on the browser. I'll try to investigate further why this is the case.

[vince-fugnitto]

I found the following electron limitation regarding service-workers and a corresponding vscode issue:

• Cannot use service worker in html document served from custom protocol: The document is in an invalid state. electron/electron#20248 (comment)
• Using iframe based webviews on desktop microsoft/vscode#83188 (comment)

It looks like electron does not support service workers created with a custom protocol.

[akosyakov]

I don’t think it applies to us, we don’t use any electron apis or custom protocols, only standard web apis and iframes. That’s what vs code want to have eventually.

[akosyakov]

Did you manage to debug it and see what is the root cause?

[vince-fugnitto]

Did you manage to debug it and see what is the root cause?

@akosyakov no I wasn't able to successfully debug it and determine the root cause yet.

[akosyakov]

There are 2 issues:

• webview hostname placeholder is resolved without port in Electron
• our security token is not applied to subdomains of localhost

[akosyakov]

@svenefftinge @marcdumais-work @marechal-p I wonder how we should go about security token for iframes? Webview URL is dynamically generated to deploy it on own origin and isolate from the main window context, so it does not have access to cookies and so on.

[paul-marechal]

@akosyakov write the security cookie in a way that it would be shared across subdomains?

[akosyakov]

Webviews are 3rd party remote content. I don’t think we want to let them to access this token. I was wondering about consequences of removing check for them.

[paul-marechal]

WebViews are contributed by extensions, the same extensions that can access the full nodejs APIs. The token prevents parties that are not part of Theia from accessing the service (via DNS rebinding attacks or other means). But how is VS Code doing? Do they have such mechanism?

[akosyakov]

WebViews are contributed by extensions, the same extensions that can access the full nodejs APIs.

That's true. Could you try to configure a cookie that it works for localhost and its subdomains?

But how is VS Code doing? Do they have such mechanism?

I don't know. Don't think that they have such mechanism. They use electrion APIs and custom protocols, i.e. they don't run web server in Electron. We don't want to go this way because of single sourcing.

[marcdumais-work]

I believe this issue is fixed by a combination of the following merged PRs:

• [electron] fix resolution of hostname placeholder #7823
• plugin-ext: attach security cookie to webviews #7847