[Bug]: terminal not working when your web base_path is not /

[acmol]

Is there an existing issue for this?

• I have searched the existing issues

OS/Web Information

• Web Browser: Chrome
• Local OS: Windows, Ubuntu
• Remote OS: Ubuntu
• Remote Architecture: x86
• code-server --version: 4.5.0 02b9d7e with Code 1.68.1

Steps to Reproduce

1. use k8s ingress, set code server base path to /ide/
2. open ${your-code-server-host}/ide/
3. ctrl + J open terminal

Expected

show terminal

Actual

No terminal created.

open chrome dev Terminal, you will see some errors like this:

    
    Failed to load resource: the server responded with a status of 503 (Service Unavailable)
    /stable-30d9c6cd9483b2cc586687151bcbcd635f373630/static/out/vs/workbench/services/keybinding/browser/keyboardLayouts/layout.contribution.win.js:1

but the root path of ide is /ide/ , not /

Logs

No response

Screenshot/Video

No response

Does this issue happen in VS Code or GitHub Codespaces?

• I cannot reproduce this in VS Code.
• I cannot reproduce this in GitHub Codespaces.

Are you accessing code-server over HTTPS?

• I am using HTTPS.

Notes

If your root path is /, terminal will open correctly.

[benz0li]

I am experiencing the same issue. Julia/Python REPL and R terminal are also not working. Furthermore, the Jupyter extension fails to activate.

[benz0li]

@jsjoeio The changes regarding baseUrl when comparing /opt/code-server/lib/vscode/out/vs/code/browser/workbench/workbench.html from code-server v4.4.0 to v4.5.0:

diff --git a/opt/code-server-4.4.0/lib/vscode/out/vs/code/browser/workbench/workbench.html b/opt/code-server-4.5.0/lib/vscode/out/vs/code/browser/workbench/workbench.html
index 2adf1b0..3ceda51 100644
--- a/opt/code-server-4.4.0/lib/vscode/out/vs/code/browser/workbench/workbench.html
+++ b/opt/code-server-4.5.0/lib/vscode/out/vs/code/browser/workbench/workbench.html
@@ -28,9 +28,9 @@
 
                 <!-- Workbench Icon/Manifest/CSS -->
                 <link rel="icon" href="{{BASE}}/_static/src/browser/media/favicon-dark-support.svg" />
-                <link rel="alternate icon" href="{{BASE}}/_static/src/browser/media/favicon.ico" type="image/x-icon" />
+                <link rel="alternate icon" href="{{BASE}}/_static/src/browser/media/favicon.ico" />
                 <link rel="manifest" href="{{VS_BASE}}/manifest.json" crossorigin="use-credentials" />
-                <link data-name="vs/workbench/workbench.web.main" rel="stylesheet" href="{{WORKBENCH_WEB_BASE_URL}}/out/vs/workbench/workbench.web.main.css">
+                <link data-name="vs/workbench/workbench.web.main" rel="stylesheet" href="{{VS_BASE}}/static/out/vs/workbench/workbench.web.main.css">
 
         </head>
 
@@ -38,26 +38,21 @@
         </body>
 
         <!-- Startup (do not modify order of script tags!) -->
-        <script src="{{WORKBENCH_WEB_BASE_URL}}/out/vs/loader.js"></script>
-        <script src="{{WORKBENCH_WEB_BASE_URL}}/out/vs/webPackagePaths.js"></script>
+        <script src="{{VS_BASE}}/static/out/vs/loader.js"></script>
+        <script src="{{VS_BASE}}/static/out/vs/webPackagePaths.js"></script>
         <script>
-                const baseUrl = new URL('{{WORKBENCH_WEB_BASE_URL}}', window.location.origin).toString();
-                Object.keys(self.webPackagePaths).map(function (key, index) {
-                        self.webPackagePaths[key] = `${baseUrl}/node_modules/${key}/${self.webPackagePaths[key]}`;
-                });
-
-                const nlsConfig = {};
+                let nlsConfig
                 try {
-                        nlsConfig['vs/nls'] = JSON.parse(document.getElementById("vscode-remote-nls-configuration").getAttribute("data-settings"))
-                        if (nlsConfig['vs/nls']._resolvedLanguagePackCoreLocation) {
+                        nlsConfig = JSON.parse(document.getElementById("vscode-remote-nls-configuration").getAttribute("data-settings"))
+                        if (nlsConfig._resolvedLanguagePackCoreLocation) {
                                 const bundles = Object.create(null)
-                                nlsConfig['vs/nls'].loadBundle = (bundle, _language, cb) => {
+                                nlsConfig.loadBundle = (bundle, _language, cb) => {
                                         const result = bundles[bundle]
                                         if (result) {
                                                 return cb(undefined, result)
                                         }
-                                        const path = nlsConfig['vs/nls']._resolvedLanguagePackCoreLocation + "/" + bundle.replace(/\//g, "!") + ".nls.json"
-                                        fetch(`{{WORKBENCH_WEB_BASE_URL}}/vscode-remote-resource?path=${encodeURIComponent(path)}`)
+                                        const path = nlsConfig._resolvedLanguagePackCoreLocation + "/" + bundle.replace(/\//g, "!") + ".nls.json"
+                                        fetch(`{{VS_BASE}}/vscode-remote-resource?path=${encodeURIComponent(path)}`)
                                                 .then((response) => response.json())
                                                 .then((json) => {
                                                         bundles[bundle] = json
@@ -67,9 +62,14 @@
                                 }
                         }
                 } catch (error) { /* Probably fine. */ }
-
+                Object.keys(self.webPackagePaths).map(function (key, index) {
+                        self.webPackagePaths[key] = new URL(
+                                `{{VS_BASE}}/static/node_modules/${key}/${self.webPackagePaths[key]}`,
+                                window.location,
+                        ).toString();
+                });
                 require.config({
-                        baseUrl: `${baseUrl}/out`,
+                        baseUrl: new URL(`{{VS_BASE}}/static/out`, window.location).toString(),
                         recordStats: true,
                         trustedTypesPolicy: window.trustedTypes?.createPolicy('amdLoader', {
                                 createScriptURL(value) {
@@ -77,13 +77,13 @@
                                 }
                         }),
                         paths: self.webPackagePaths,
-                        ...nlsConfig
+                        'vs/nls': nlsConfig,
                 });
         </script>
         <script>
                 performance.mark('code/willLoadWorkbenchMain');
         </script>
-        <script src="{{WORKBENCH_WEB_BASE_URL}}/out/vs/workbench/workbench.web.main.nls.js"></script>
-        <script src="{{WORKBENCH_WEB_BASE_URL}}/out/vs/workbench/workbench.web.main.js"></script>
-        <script src="{{WORKBENCH_WEB_BASE_URL}}/out/vs/code/browser/workbench/workbench.js"></script>
+        <script src="{{VS_BASE}}/static/out/vs/workbench/workbench.web.main.nls.js"></script>
+        <script src="{{VS_BASE}}/static/out/vs/workbench/workbench.web.main.js"></script>
+        <script src="{{VS_BASE}}/static/out/vs/code/browser/workbench/workbench.js"></script>
 </html>

[CodingJinxx]

Having the same issue, staying on 4.40v for the time being

[aghontpi]

➕ same issue

• Web Browser: Safari, Frefox, Chrome
• Local OS: macOS 11.x
• Remote OS:

NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"

• Remote Architecture: x86_64
• code-server --version: 4.5.0 02b9d7e with Code 1.68.1

network request path is wrong

some of the files load with correct path, (in the img, it should be "https://{hostname}/code/{other stuff}"

but some load with incorrect path

[23fo]

same issue，and python extension fails to activate.

[benz0li]

Cross reference: #5326

[jsjoeio]

Hi all - thank you for the reports and the details! We had all last week off for the holidays so I'm just now seeing this. @code-asher is out until Thursday. I'm going to start investigating this today.

Hoping I should be able to easily reproduce with Caddy

[jsjoeio]

Investigation Notes

I'll update this comment with my findings as I investigate this issue.

The Issue

Folks are having issues using the Integrated Terminal when they run code-server no on the root path i.e. /ide. This is very common.

Steps to reproduce

1. brew upgrade code-server - upgrade to latest release (v4.5.0)
2. code-server - run code-server
3. caddy run - run Caddy and serve code-server on sub-path

# Caddyfile
http://localhost:8082/ide/* {
  uri strip_prefix /ide
  reverse_proxy 127.0.0.1:8080
}

4. http://localhost:8082/ide/ - open code-server in browser (don't forget trailing slash)
5. open Integrated Terminal
6. see error - terminal doesn't load

Screenshot

What could have caused this?

Whenever issues like this happen, it's usually related to a VS Code upgrade which is the most brittle part of the codebase.

@benz0li left a helpful diff here to show any changes related to baseUrl.

I'm going to look at the commits for the 1.68 upgrade to see what we documented about the change.

Nothing stands out in particular there. It seems like the baseUrl is wrong for anything in /static/node_modules/ looking at @aghontpi. I see those upstream here:

https://github.com/microsoft/vscode/blob/30d9c6cd9483b2cc586687151bcbcd635f373630/src/bootstrap-window.js#L136

I don't see any recent changes so i'm hesitant to believe the change is there.

Based on the diff provided earlier, I think this could be related:

-		const baseUrl = new URL('{{WORKBENCH_WEB_BASE_URL}}', window.location.origin).toString();
+		const baseUrl = new URL('{{WORKBENCH_WEB_BASE_URL}}', window.location).toString();
 		Object.keys(self.webPackagePaths).map(function (key, index) {
 			self.webPackagePaths[key] = `${baseUrl}/remote/web/node_modules/${key}/${self.webPackagePaths[key]}`;
 		});

The only difference is using window.location in the call to new URL instead of window.location.origin.

Strangely, the MDN docs say the second argument to new URL should be base: string here.

This is in an HTML file inside a <script /> tag so I am guessing that's why we don't have any TypeScript errors. I'm going to try making that change and run code-server locally with yarn watch to see if that solves it.

Actually...that may not be accurate.

In particular, you can use an existing URL object for either argument, and it will stringify to the object's href property.

So this means it went from using the origin (string we passed) to using the href which means it's a different value:

• origin: "http://localhost:8082"
• href: "http://localhost:8082/ide/?folder=/Users/jp/dev/oss/tabnine-vscode"

which seems the right call 🤔 https://jsfiddle.net/5ca3um8x/5/

meaning I don't know if that's the issue here.

digging around i found window.require.getConfig() which returns an object and we see baseUrl is not relative to root.

baseUrl: "http://localhost:8082/stable-30d9c6cd9483b2cc586687151bcbcd635f373630/static/out/"

thinking out loud...feels like we have logic in place to make sure WORKBENCH_WEB_BASE_URL supports a relative root and then this line "reverts" that back to assuming code-server is at the root:

const baseUrl = new URL('{{WORKBENCH_WEB_BASE_URL}}', window.location.origin).toString();

oddly enough, workbench.html and workbench-dev.html do not create baseUrl the same.

Well, when I change workbench-dev.html to mimic our change in workbench.html, the terminal (and code-server) fail to load:

this means using window.location.origin results in the Terminal working.

And if you look upstream, they both use that as well:

• https://github.com/microsoft/vscode/blob/main/src/vs/code/browser/workbench/workbench-dev.html#L40
• https://github.com/microsoft/vscode/blob/main/src/vs/code/browser/workbench/workbench.html#L39

I think this is enough evidence to open a PR so that CI builds and we can test a full build via npm.

Wait actually...now I'm not sure 🤔 That change to window.location from window.location.origin only happened on our side inside workbench-dev.html which I believe is only used in Development (at least it shouldn't be used in prod unless I'm missing something) so now I'm not sure about this fix I proposed.

But it also makes me question why we'd make that change in workbench-dev and not workbench 🤔

I'll open a PR and test a build anyway.

Unsurprisingly, that did not work.

I'm starting back on this again.

Next, I'm looking at all changed files between 4.4.0 and 4.5.0.

We did change the order of the patches to make it easier apply the display patch. See here. I wonder if that could have caused this.

I may try applying all the patches but the display language and see if that work.

No luck there.

So this 983269f works locally when you run code-server in development mode aka yarn watch with Caddy.

@oxy and I paired on this. We paired on this. We made the correct change in workbench-dev.html but not workbench.html. My PR has been updated and now we need to check once again after CI finishes.