feature request: API to set URL of WebView

[mrmeku]

Currently the webview API does not allow setting a URL to load content. Thus, if you want to load content from a remote/local server you need to set the webview's html to include an iframe.

Inserting an iframe inside of a webview breaks all keyboard shortcuts inside the webivew (so no copy / paste) and also outside of the webview (so you cannot open the command palatte)

The bugs described above do not occur when an iframe is not inserted within a webview. If we could set the webview's url we would not need an iframe. Thus the feature request is an extension of the webview api to set a url to load content.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Cannot copy and paste from/to a webview's iframe (#68799)
• WebView optionally add "allow-modals" to iframe sandbox options (#67109)
• Cannot Capture File->Save menu option when using a webview (#60801)

[mrmeku]

Might be a duplicate of #65452
But I've added some extra details to this feature request so I'll leave it to the maintainers to decide if this should be closed and marked as duplicate

[mjbvz]

If we were to support this, would you expect:

• VS Code api to be enabled?
• Navigation to work?

[mrmeku]

We would expect an api to set the url and that navigation would work after the fact.

[mjbvz]

As an example: if you load a url like localhost:3000 in the webview, would you expect:

• That content served on localhost:3000 could use the vscode apis that webview content has access to today (using postMessage for example)
• That you could click on a link on the page and it would navigate to that page within the webview element? Navigation is blocked inside of webviews today

The two are are harder to support together for security reasons. We don't want to let webviews navigate to arbitrary pages and that content on that page could then use the vscode apis.

---

Edit Just noticed you edited the comment so you can ignore these questions

[mrmeku]

Yes, we would want to unblock navigation as part of this API request. *thanks for asking!

[hediet]

In my scenario, webworkers of monaco don't seem to work in vscodes webviews.
I can't really debug it since the dev tools window opens way too late, but I think it is because only http(s?)-served websites can spawn web workers.
IFrames are very slow and I have tons of focus problems with them in Vs Code so I would like to avoid them.

I would be fine with blocking navigation but persisting the URL query parameters which are then allowed to be updated from within the webview.
My extension would start a webserver to host the content.

[zhanba]

@mjbvz support navigation is important for SPA, any plan to support this?

[ghost]

I have managed to get a solution, available here, but it can't load js/css at this moment.

[mjbvz]

Closing as this is not something we can provide a good story for

Webviews take raw html in part because this lets us modify the html content before it is rendered, such as injecting the webview API. This is generally not possible for content loaded from a url (unless you have a proxy, but that's not business VS Code wants to get into). As a result, none of the VS Code variables or scripts would be available inside of a url based webview, which makes it about the same just rendering a full width+height iframe for the url inside your webview.

Instead, if you need to display content from a specific url, use an iframe. You webview code can also post messages to this iframe to communicate with it

[memeplex]

I would like to revisit this issue. I'm having a bad time trying to implement a previewer for revealjs that doesn't lose its position each time it gets refreshed. In order to support this, revealjs updates its url to include the current slide number. @mjbvz you suggested to use an iframe in 2021, but that's not possible anymore since a couple of years at least (I tried and the iframe is always empty, my code is quite similar to #123766). The only way around this I see is some kind of convoluted message passing informing slide changes.