Support opening links in a new window from within webviews

[tomduncalf-figma]

Summary

In Figma for VS Code, we would like to support links which open new windows, either using <a target="_blank"> links or window.open in JS, from within an iframe in a webview (the extension opens a webview, which contains Figma in an iframe).

We believe this would be generally useful functionality for other extensions, e.g. an extension which loads documentation in an iframe may want to open new windows, without changing the source code of the documentation page.

Current behaviour

See video:

links.mov

Inside a webview

Clicking a <a target="_blank"> link in a top-level webview opens a new browser immediately.
Clicking a window.open link in a top-level webview gives an error Blocked opening '...' in a new window because the request was made in a sandboxed frame whose 'allow-popups' permission is not set.

Inside an iframe inside a webview (this is how the Figma for VS Code extension works)

Clicking a <a target="_blank"> link or a window.open link in a top-level webview gives an error Blocked opening '...' in a new window because the request was made in a sandboxed frame whose 'allow-popups' permission is not set.

Desired behaviour

Ideally clicking a link which tries to open in a new window would show the usual Do you want Code to open the external website? dialog box, and would open the link in a browser if the user presses Open.

Alternatively, VS Code could add allow-popups to the iframe, so that the links immediately open a new browser. However, it seems better to go via the usual confirmation dialog flow.

Workarounds

For links which we control, we can replace them with a postMessage call which then calls vscode.openExternal. However, for links embedded in third party Figma plugins, this would require the third parties to modify their code, which might mean substantial extra work or may be difficult for them to do (e.g. if the plugin is actually an iframe around their main web app, they may not wish to add Figma/VS Code specific code in there).

We have investigated replacing window.open with a new implementation which calls postMessage and/or adding a global document.body.addEventListener('click'... listener to intercept clicks on <a target="_blank"> links, but this doesn't feel great, and does not work if the plugin itself has its own iframe(s), as we cannot control these or inject code into it.

[gjsjohnmurray]

You may want to upvote #185204

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[FederAndInk]

It would be awesome to have an option to remove the target="_blank" so clicking on links just works

[DanTup]

I hit this with Flutter's DevTools too. The tools are embedded inside a webview and have links to documentation that should open in a new window (not inside the webview).

[vscodenpa]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[isidorn]

I just discussed this with @mjbvz and our main concerns are that this lets webview contents create native UI elements like alerts. Our recommendation is instead hook up the webview to trigger VS Code's UI instead
We have two main concerns about allowing system native UI to be triggered from webviews:

• Consistency. The native UI may look out of place and may not behave like other UI elements in VS Code
• Phishing. If a webview is compromised, it could show native looking UI that collects sensitive user info such as passwords. As users trust VS Code, they may be more likely to enter this information without thinking

Thus we have no plans to go forward with this feature right now.

I suggest to go with one of the workarounds you shared in the initial comment. The one where your plugin have to opt-into this by calling your api that does the vscode.openExternal sounds reasonable to me.

[DanTup]

Seems to be working for me today.. I still see an error in the console, but the page opens fine.

Nevermind, it works for us because we implemented a workaround by using postMessage that I forgot about 😄

[tomduncalf-figma]

@isidorn Thank you for the update and sorry for the late response, my GitHub notifications aren't working correctly.

I'm not sure if I fully understand the concerns – my proposed solution is to still show the Do you want Code to open the external website? prompt, and to open the link in a regular browser window, so this wouldn't appear any more native than links opened in a new window from VS Code using vscode.openExternal.

It would just mean that you could open a link in a new browser window using <a target="_blank"> or window.open, rather than having to modify existing sites to call vscode.openExternal.