WebView port mapping not working under Remote SSH #102449
Comments
|
Any updates on this? It looks like extensions that rely on WebView port mapping are completely broken. |
mjbvz
added
bug
|
@mjbvz I'm testing with the latest insider on both macOS and Ubuntu which seems to include your commit to fix this issue (?). But the port mapping still does not work. Am I missing something? The WebView still does not work
while the
|
|
Hm, just tested this with a simple extension and R specifically and it seems to be working for me:
What is your server version? This can be found by running Also can you try putting together a minimal example that shows it not working? |
|
I'm currently working on Ubuntu via Remote-SSH and the latest insider does not work. Following is The minimal example is just like what you tried: ?getand the WebView is blank. If this works then everything should work normally. Maybe the fix somehow works for dev container but not for SSH? |
|
I also tried with a dev container and it does not work either. |
|
A minimal example is:
|
|
In both Remote-SSH and Remote-Container environments, I found that the first time I tried The following are more examples to test with:
apt install -y libcurl4-openssl-dev libxml2-dev libssl-dev libssh2-1-dev libsasl2-dev libcsv-dev libfontconfig1-dev libcairo2-dev
Rscript -e "install.packages(c('devtools', 'shiny'))"
shiny::runExample("01_hello")
devtools::install_github("nx10/httpgd@boost-beast")
httpgd::httpgd()
plot(rnorm(100))
httpgd::httpgdBrowse()
.vsc.browser(httpgd::httpgdURL(), viewer = FALSE) |
|
@deepak1556 The problem is the mapping from the request to the webview. In
Subsequent requests do not:
I will see if I can put together a small electron reproduction. However instead of using the web contents id at all, it would be nice if we could instead use the requesting origin: |
|
Filed electron/electron#24820 to track the electron issue upstream @deepak1556 Instead of fixing my new issue, I think we should prioritize either:
|
mjbvz
added
electron
|
I'm wondering if there's anything that could be done on our side to walk-around this at the moment? It looks like this cannot be fixed in a short term due to upstream issue. Is it possible that we take advantage of the mechanism behind |
|
Yes you should be able to workaround the issue by calling openExternal yourself. Not great but I think it should work @deepak1556 Let me know if I can help you look into the electron issues/feature requests |
|
Is it possible to use the port mapping enabled by openExternal or by some other port mapping API (I haven't seen any?) but not literally open an external web browser page? |
|
@mjbvz sorry was looped into other work, I will have a fix for the mentioned electron issues tomorrow or day after. |
|
In the recent release, the auto port forwarding start to delay significantly so that the WebView is kept blank. |
|
I switched to |
This comment has been minimized.
This comment has been minimized.
|
We also have switched to |
|
I have tried to add a different workaround since it looks like electron/electron#27078 is not being back ported to electron 11. Please test out the next VS Code insiders build and let me know if this still isn't working |
mjbvz
added
the
author-verification-requested
|
It does not work with LaTeX Workshop 8.15.0. No output in the console of Webview Dev Tools. You can try the extension with PDF files without TeX distributions.
Version: 1.54.0-insider |
|
Please test this again in the latest insiders build. We now use service workers instead of electron to load webview resources, which I'm hoping addresses this |
|
I tested with the latest insider build and webview port-mapping, but it still does not work. |
|
I just looked more closely at the original issue and see that the original example uses an iframe, which explains why you don't see this working Previously port forwarding on desktop used electron protocols to intercept and rewrite requests. We originally broke all port mapping when we moved the request intercepting to the main thread instead of being window specific. Now however we use service workers to load resources inside of webviews, which is how the web version of VS Code has always worked. This fixes port mapping for me, with the exception that service workers currently cannot intercept requests for/from iframes. @renkun-ken We can't workaround this issue in any reasonable way, so using I'm going to close this issue since as far as I know port mappings now works, except for known limitation related to iframes. To verify:
diff --git a/webview-sample/src/extension.ts b/webview-sample/src/extension.ts
index 6349900..5e81aea 100644
--- a/webview-sample/src/extension.ts
+++ b/webview-sample/src/extension.ts
@@ -40,7 +40,10 @@ function getWebviewOptions(extensionUri: vscode.Uri): vscode.WebviewOptions {
enableScripts: true,
// And restrict the webview to only loading content from our extension's `media` directory.
- localResourceRoots: [vscode.Uri.joinPath(extensionUri, 'media')]
+ localResourceRoots: [vscode.Uri.joinPath(extensionUri, 'media')],
+ portMapping: [
+ { webviewPort: 8888, extensionHostPort: 9999 }
+ ]
};
}
@@ -189,24 +192,9 @@ class CatCodingPanel {
<head>
<meta charset="UTF-8">
- <!--
- Use a content security policy to only allow loading images from https or from our extension directory,
- and only allow scripts that have a specific nonce.
- -->
- <meta http-equiv="Content-Security-Policy" content="default-src 'none'; style-src ${webview.cspSource}; img-src ${webview.cspSource} https:; script-src 'nonce-${nonce}';">
-
- <meta name="viewport" content="width=device-width, initial-scale=1.0">
-
- <link href="${stylesResetUri}" rel="stylesheet">
- <link href="${stylesMainUri}" rel="stylesheet">
-
- <title>Cat Coding</title>
</head>
<body>
- <img src="${catGifPath}" width="300" />
- <h1 id="lines-of-code-counter">0</h1>
-
- <script nonce="${nonce}" src="${scriptUri}"></script>
+ <img src="http://localhost:8888/image.png" />
</body>
</html>`;
}
|
|
@mjbvz Thanks for your detailed explanation. Thanks again for keep tracking on this. Maybe it is worth mention in the documentation of WebView about the limitation of port mapping inside iframes. |
and others
Steps to Reproduce:
r.sessionWatchertotrue, and reload vscode.Create R terminaland an R session is started?getIt starts an http server that provides the R documentation, and a VSCode
WebView should show up by the following extension code.
When
viewer="Active", the WebView cannot be shown properly with the latest release and insider of VSCode. Theiframecontent is empty.However, if I run the following in R
which basically calls
showBrowserwithviewer=false, then a local web browser is open byenv.openExternal(Uri.parse(url));the web page is properly shown. Only after this, I call?get, or equivalentlyThe WebView could be properly shown.
I guess the port mapping of WebView via Remote SSH somehow is not working and it works with the port mapping enabled by
env.openExternal(Uri.parse(url)). Everything works well if the same is done locally.Related: REditorSupport/vscode-R#380.
Does this issue occur when all extensions are disabled?: Yes
The text was updated successfully, but these errors were encountered: