Skip to content

[Bug]: Workspace URI parsing and construction should use server OS's path separator, not browser host OS's #6141

Closed as not planned
@pigpag

Description

@pigpag

Is there an existing issue for this?

  • I have searched the existing issues

OS/Web Information

  • Web Browser: Chrome 110
  • Local OS: Windows 10
  • Remote OS: CentOS 7.9
  • Remote Architecture: amd64
  • code-server --version: 4.11.0 with Code 1.76.1

Steps to Reproduce

  1. Create a workspace with the following content in the .code-workspace file:
{
    "folders": [
        {
            "name": "workspace",
            "uri": "file:///home/some/path/to/folder"
        }
    ]
}

Note that I use uri instead of path so I can provide a URI. In my real use case, I have a virtual workspace with a custom URI scheme so I cannot use path.

  1. Start the browser in Windows and connect/log in to server.
  2. Not that folder won't open, with error "\home\some\path\to\folder - Unable to resolve path" (note the backslash). For custom virtual workspace, files may be able to open, but the editor tab title will contain the full path with the wrong path separator.

Expected

  1. For file:// scheme, folders should be able to open.
  2. For custom URI scheme, file paths should use server's path separator, and editors' titles should consist of only the basenames of the files (e.g. "file.js", not "\home\some\path\to\folder\file.js")

Actual

  1. file:// scheme URI has "Unable to resolve" error
  2. Editor titles contain full path with the incorrect path separators even if custom URI schemes can be opened.

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

  1. This issue is gone if I hack the browser's User-Agent string to pretend to be from Linux.
  2. This issue seems related to Accessing from windows is broken #1659

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingos-windowsWindows relatedtriageThis issue needs to be triaged by a maintainer

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions