VS Code loading twice at workspace startup

[l0rd]

Describe the bug

When starting a che-code based workspace the IDE gets loaded a first time and shows an error message (Error loading webview) and after a few seconds gets reloaded:

vs-code-loading-twice.mov

Che version

next (development version)

Steps to reproduce

Click here (access to Che dogfooding instance is required).

Expected behavior

VS Code is loaded once.

Runtime

OpenShift

Screenshots

No response

Installation method

OperatorHub

Release Notes Text

An extension was used to open the project folder at VS Code startup. The result was VS Code beeing loaded twice in the user browser. This is not necessary anymore as we use the VS Code startup parameter --default-folder that has been (re-)introduced recently.

[azatsarynnyy]

The work on this issue has been postponed. At least, until we fix #21537

[l0rd]

We should try replacing ?tkn=eclipse-che with ?folder=${PROJECT_SOURCE}.

[azatsarynnyy]

We should try replacing ?tkn=eclipse-che with ?folder=${PROJECT_SOURCE}.

@l0rd it's a good idea. But it works OOTB for ?folder=/projects only. As VS Code doesn't resolve the environment variables passed through the URL query parameters.

Hardcoding ?folder=/projects looks like the following, in Project Explorer:

That's why we have che-on-start extension that detects the right path VS Code should navigate to, depending on a few conditions.

As I see it, one of the options for fixing that problem would be to move that logic from the extension to the entry point script. In that case we could provide the correct path to the server side instead of redirecting the client.

[l0rd]

${PROJECT_SOURCE} should be resolved by the DevWorkspace operator

[l0rd]

So the proposal is to resolve ${PROJECT_SOURCE} when setting a DevWorkspace status.mainUrl.

For example, an endpoint with a path that references $PROJECT_SOURCE and with the attribute type: main:

        endpoints:
          - name: che-code
            attributes:
              type: main
              cookiesAuthEnabled: true
              discoverable: false
              urlRewriteSupported: true
            targetPort: 3100
            exposure: public
            path: '?folder=${PROJECT_SOURCE}'
            secure: false
            protocol: https

should result in a DevWorkspace status where the $PROJECT_SOURCE has been resolved:

"status": {
    (...)
    "mainUrl": "https://workspace1bc9e32c0fcd4aed.apps.mloriedo-devworkspaces.devcluster.openshift.com/che-code/?folder=/projects/my-project",
    "message": "https://workspace1bc9e32c0fcd4aed.apps.mloriedo-devworkspaces.devcluster.openshift.com/che-code/?folder=/projects/my-project",
    "phase": "Running"
  }

I am adding the label area/devworkspace-operator.

[azatsarynnyy]

That sounds great! As most of the workspaces are single-root projects, it should fix the problem for the vast majority of cases.

[azatsarynnyy]

I've found out how we can do the same in VS Code entrypoint.
We can pass ${PROJECT_SOURCE} when we start VS Code Server
https://github.com/che-incubator/che-code/blob/3072353809a0e30369eb7bddd566a35fdb3c94bd/code/src/vs/server/node/serverEnvironmentService.ts#L46

[l0rd]

I've found out how we can do the same in VS Code entrypoint.

We can pass ${PROJECT_SOURCE} when we start VS Code Server

https://github.com/che-incubator/che-code/blob/3072353809a0e30369eb7bddd566a35fdb3c94bd/code/src/vs/server/node/serverEnvironmentService.ts#L46

👍great! Let's do that then

[azatsarynnyy]

Fixed by che-incubator/che-code#131.
VS Code is loaded x2 faster now.

[max-cx]

This issue was not manually cloned into Jira for release notes because VS Code was a Technology Preview feature up until Che 7.56 / DS 3.4, and we don't document known issues or bug fixes for Technology Preview features in DS release notes.

[devstudio-release]

sync'd to Red Hat JIRA https://issues.redhat.com/browse/CRW-3852