Using iframe based webviews on desktop

[mjbvz]

Today VS Code implements the webview api on desktops using electron's <webview> tag. We've run into some unexpected behavior with webviews and would prefer to move to a more standard web based approach, such as using iframes

For web, we already implement webviews using normal iframes. You can also enable experimental iframe based webviews in desktop VS Code by setting "webview.experimental.useIframes": true ("webview.experimental.useExternalEndpoint": true in older VS Code versions)

Known blockers:

• We probably want to use an electron custom-protocol to host the webview content itself. However we cannot register a service worker inside pages served up using a custom protocol: Cannot use service worker in html document served from custom protocol: The document is in an invalid state. electron/electron#20248

• Find does not work for for iframe based webviews. There is no clear way to implement the find functionality for webviews without taking a dependency on a third party html search library

[mjbvz]

Also potentially addresses:

• Try better webview focus tracking solution in Electron 6+ #65413
• macOS: some commands no longer work inside iframe inside webview #65452
• Webview does not dispose properly #50556
• input cannot focus when switching webview #84216

[sguillia]

Hi

I am an extension author

This issue totally prevents some of my users to open the webview contributed by my extension.
The panel opens, but the content is not loaded.

ERR No application in the Launch Services database matches the input criteria log.ts:197

Adding this line to the settings fixes the problem:

"webview.experimental.useExternalEndpoint": true

• VSCode Version: 1.44
• OS Version: macOS 10.14.6

Do you recommend me to make my extension spontaneously write useExternalEndpoint to the user settings?

My extension requires internet anyway so this seems a reasonable workaround.

I can try to detect when the problem occurs, by setting up a watchdog in the extension, and making the webview content call postMessage on first load.

[mjbvz]

@sguillia No. Your extension should never direct users to enable this setting. It is intentionally not documented and marked as experimental because it is not production ready and it is not particularly stable

[mjbvz]

@deepak1556 Just pushed an update to my branch the enables offline iframe based webviews (without requiring service workers): https://github.com/mjbvz/vscode/tree/iframe-webviews

The bulk of the change is in mjbvz@9091ad7

While can't switch to iframe based webviews yet, this iteration I think we should try the following:

• Enable the new vscode-webview-resource scheme our existing webviews. This would let us move away from using a vscode-resource protocol handler for each individual webview.

• Update asWebviewUri to return vscode-webview-resource uris.

• Add some code that tries to rewrite vscode-resource: uris to vscode-webview-resource uris (this is very similar to the code we already have for web that rewrites vscode-resource uris).

[bpasero]

@mjbvz does that solution preserve todays isolation from webview to webview? I thought in order to achieve that, each webview would need its own origin?

And a second question: what is the purpose of vscode-resource scheme. Is it only used for content inside webview that wants to access files?

[deepak1556]

does that solution preserve todays isolation from webview to webview? I thought in order to achieve that, each webview would need its own origin?

Yup we are preserving that, the idea for desktop is quite similar to web but instead of subdomains we generate new uuids for each webview that will act as the origin and we map that to the webview id. For ex:

vscode-webview is registered as standard scheme, it will respect URI of the format scheme://origin/path. When something like vscode-webview://uuid1/test.html and vscode-webview://uuid2/test.html are loaded in two different webview, chromium will treat these as separate origins because of uuid1 , uuid2 and provide them with their own process.

On the main process side, we pretty much just have to handle the path to load resource from based on the uuid -> webview id mapping

protocol.registerBufferProtocol('vscode-webview', (request, cb) => {
   const url = new URL(request.url)
   switch (url.host) {

    } 
})

[bpasero]

Ah ok, I was not aware that having the UUID as part of the URL is sufficient, that is great 👍

[mjbvz]

#100991 enables offline iframe based webviews on desktop. Still blocked on moving off of webviews until search is supported: #96307