To fully fix for the Tabnine case we will need:

1. Implement asExternalUri.
2. Use the sub-domain proxy instead of path-based proxy when available. Tabnine will only work with sub-domains since their application does not use relative paths and it does not seem they are able to fix that or provide a workaround like allowing a base URL. Users will need to set up wildcard certificates and DNS (or at the very least one for the Tabnine port).
3. Allow external proxies (like Coder’s dev URLs) so it can be set up to work in environments that have their own sub-domain proxy setup and cannot delegate that role to code-server.

I’ve identified the Root Cause as well and have an idea for fixing this.

Root Cause

Based on my findings, the call stack looks like this:

1. extension calls asExternalUri using vscode.env.asExternalUri
2. that calls asExternalUri here
3. that calls $asExternalUri here
4. calls openerService.resolveExternalUri here

This last function – resolveExternalUri – tries to resolve this external uri using one the _resolvers (property on class). The problem is…there are no resolvers in the browser (at least in code-server, where i’m running with yarn watch).

“Okay…so shouldn’t it throw this error?”

You would think so but if you look at the link in 3 in my call stack list, you’ll notice the code isn’t wrapped in a try/catch block. Therefore, that error never bubbles up.

“is that a bug?”

I would say so but I might check with @code-asher. Raised upstream: https://github.com/microsoft/vscode/issues/162770

There may be more to this root cause since I’m not sure why there wouldn’t be a resolver for this external URI in the first place. I know it works in Codespaces but I can’t figure out how.

Solution

I’d like to discuss with @code-asher first but I did find this. When I add resolveExternalUri here called like so:

		resolveExternalUri: async (uri: URI) => {
			const v = await Promise.resolve(URI.parse("http://localhost:8080/proxy/8000"))
			return v
		},

then my extension uses it!

If this is the correct place to patch, then next steps would be to agree upon how external uris should be resolved. One approach could be to use code-server’s built-in proxy and do something like localhost:8000 -> <base-url>/proxy/8000.

Notes

I have started looking into this and will share my notes here and update this comment as I go.

CONCLUSION: I successfully reproduced the bug.

Investigation: does asExternalUri work for a basic callback URL? ✅

Here are the steps I’m following to check:

1. create a new extension: npx yo code
2. open code-server (4.7.0) locally (macOS + Brave) and open extension
3. use vscode.env.asExternalUri in extension (see code below)
4. run extension (F5) or click “Run extension” in Run and Debug window
5. run command and test

      const callableUri = await vscode.env.asExternalUri(
        vscode.Uri.parse(vscode.env.uriScheme + "://test")
      );

      vscode.window.showInformationMessage(
        `your url: ${callableUri.toString()}`
      );

Expected It shows callback URL in information notification and that URL is accessible in my browser.

Actual It shows callback URL in information notification and that URL is accessible in my browser.

Investigation: does asExternalUri work for a URL like localhost:8000? ❌

Similar steps as above but with this code:

      const callableUri = await vscode.env.asExternalUri(
        vscode.Uri.parse(`http://localhost:8000)
      );

      vscode.window.showInformationMessage(
        `your url: ${callableUri.toString()}`
      );

Expected

It behaves like Codespaces and transforms the URL to be behind the a proxy such as https://jsjoeio-coder-code-server-rpvvw55xp7f4x9-8000.githubpreview.dev/. More info needed here on how this should behave.

Actual

It does not transform URL and returns http://localhost:8000.

Chatting with their team about this. Stay tuned!

Awesome. Thank you!

Good news - PR is pretty much good to go. We should be able to wrap it up Monday assuming all goes well.

I chatted with @code-asher offline and we came up with a fix. I’m going to work on it today and hopefully push up a draft PR soon. Keep an eye out.

Thanks for letting us know @Sominemo! That’ll be helpful when we go to fix this. We may want to write our own extension that uses asExternalUri and add an e2e test to make sure it works (when we fix this).

Dart & Flutter extension for VS Code uses asExternalUri too, and its DevTools iframes don’t work without manual port forwarding, because it tries to connect to localhost. As far as I understand, it’s related to this issue.

The Tabnine team is still facing this so we need to dig into it.

Awesome, that sounds like a really good workaround.

I’m thinking we should leave the issue open until we fix asExternalUri since it would be ideal to have parity with local VS Code.