Uploaded image for project: 'Red Hat OpenShift Dev Spaces (formerly CodeReady Workspaces) '
  1. Red Hat OpenShift Dev Spaces (formerly CodeReady Workspaces)
  2. CRW-3885

VS Code's webview functionality should work when the browser is behind the proxy

XMLWordPrintable

    • False
    • None
    • False
    • Release Notes
    • Hide
      = Fixed webviews in Microsoft Visual Studio Code - Open Source for restricted environments

      Before this update, link:https://code.visualstudio.com/api/ux-guidelines/webviews[webviews] in Microsoft Visual Studio Code - Open Source did not render correctly in restricted environments. This issue occurred because the browser could not download static resources from the public Internet behind a proxy. With this update, the {prod-short} build of Microsoft Visual Studio Code - Open Source serves those resources directly from its server, which is usually accessible through proxies.
      Show
      = Fixed webviews in Microsoft Visual Studio Code - Open Source for restricted environments Before this update, link: https://code.visualstudio.com/api/ux-guidelines/webviews [webviews] in Microsoft Visual Studio Code - Open Source did not render correctly in restricted environments. This issue occurred because the browser could not download static resources from the public Internet behind a proxy. With this update, the {prod-short} build of Microsoft Visual Studio Code - Open Source serves those resources directly from its server, which is usually accessible through proxies.
    • Bug Fix
    • Done

      VS Code client (on the browser side) tries to fetch the common static resources for the WebView from the "https://uuid.vscode-cdn.net/insider/ef65ac1ba57f57f2a3961bfe94aa20481caca4c6/out/vs/workbench/contrib/webview/browser/pre/".

      As the resources can't be downloaded, any WebView functionality does not work. E.g.: markdown preview, the extension details page, etc.

      We can solve that problem by reworking the functionality on our (Che-Code) side to fetch the WebView-related static resources from the DevSpaces backend.
      As the same resources should be available on VS Code backend running in the cluster.

       

        1. Preview.png
          Preview.png
          30 kB
        2. Screenshot_2023-01-03_at_15.42.37.png
          Screenshot_2023-01-03_at_15.42.37.png
          102 kB
        3. Selection_001.png
          Selection_001.png
          49 kB
        4. Selection_002.png
          Selection_002.png
          58 kB

            [CRW-3885] VS Code's webview functionality should work when the browser is behind the proxy

            Maksym Musienko added a comment -

            I checked it under proxy with none self-sign SSL certificate (RHPDS). All worked as expected

            Maksym Musienko added a comment - I checked it under proxy with none self-sign SSL certificate (RHPDS). All worked as expected

            Vitaliy Gulyy added a comment - - edited

            There is a pull request to the upstream that fixes a bug when building the base URI for webview static resources.
            The fix was successfully tested on several clusters with DS 3.6.0.RCs.

            But there is one restriction, that does not allow the webviews to be working properly if static resources were taken from local host (the host from where che-code was loaded).
            If the server does not have a valid SSL certificate, the webview will not work. It's because webview uses service worker, for which having the HTTPS with valid certificate is mandatory.

            Having that on some our test clusters webviews do not work comment-22196626.
            Again, it does not work when webview resources switched to be loaded from the same host as che-code and the cluster does not have a valid SSL certificate.

            Vitaliy Gulyy added a comment - - edited There is a pull request to the upstream that fixes a bug when building the base URI for webview static resources. The fix was successfully tested on several clusters with DS 3.6.0.RCs. But there is one restriction, that does not allow the webviews to be working properly if static resources were taken from local host (the host from where che-code was loaded). If the server does not have a valid SSL certificate, the webview will not work. It's because webview uses service worker, for which having the HTTPS with valid certificate is mandatory. Having that on some our test clusters webviews do not work comment-22196626 . Again, it does not work when webview resources switched to be loaded from the same host as che-code and the cluster does not have a valid SSL certificate.

            Maksym Musienko added a comment - - edited

            I checked this functionality in the following way:
            Setup proxy locally on Fedora:


            And reproduce the problem with Preview on the Readme.md file. Use Java Lomboc project for this. After this, I add envs., variable to the tool container 
            env:

            • name: WEBVIEW_LOCAL_RESOURCES
              value: 'true'
              And the problem with unavailable content disappeared. But the preview widget was empty. After further investigation, I found the next errors in js. the console of Chrome browser about self-sign TLS certificate:

               - But the strange thing that with the open public certificate the problem is still actual

             

            Maksym Musienko added a comment - - edited I checked this functionality in the following way: Setup proxy locally on Fedora: And reproduce the problem with Preview on the Readme.md file. Use Java Lomboc project for this. After this, I add envs., variable to the tool container  env: name: WEBVIEW_LOCAL_RESOURCES value: 'true' And the problem with unavailable content disappeared. But the preview widget was empty. After further investigation, I found the next errors in js. the console of Chrome browser about self-sign TLS certificate:  - But the strange thing that with the open public certificate the problem is still actual  

            Nick Boldt added a comment -

            Previous code builds were impacted by CRW-4328, but that should be fixed now.

            • quay.io/devspaces/code-rhel8:3.6-56 (coming later today)
            • quay.io/devspaces/code-rhel8:3.7-52 (33 mins ago)

            Nick Boldt added a comment - Previous code builds were impacted by CRW-4328, but that should be fixed now. quay.io/devspaces/code-rhel8:3.6-56 (coming later today ) quay.io/devspaces/code-rhel8:3.7-52 (33 mins ago)

            Dmytro Nochevnov added a comment -

            Reopening issue, because there is outdated tarball in code-rhel8:3.6-55 image https://issues.redhat.com/browse/CRW-4328

            Dmytro Nochevnov added a comment - Reopening issue, because there is outdated tarball in code-rhel8:3.6-55 image https://issues.redhat.com/browse/CRW-4328

            Dmytro Nochevnov added a comment - - edited

            There is successful build https://main-jenkins-csb-crwqe.apps.ocp-c1.prod.psi.redhat.com/job/DS_CI/job/code_3.6/9/

            Latest https://quay.io/repository/devspaces/code-rhel8:3.6-55 is included into DS 3.6.0.RC-20-04 (devspaces-operator-bundle-container-3.6-172).

            Dmytro Nochevnov added a comment - - edited There is successful build https://main-jenkins-csb-crwqe.apps.ocp-c1.prod.psi.redhat.com/job/DS_CI/job/code_3.6/9/ Latest https://quay.io/repository/devspaces/code-rhel8:3.6-55 is included into DS 3.6.0.RC-20-04 (devspaces-operator-bundle-container-3.6-172).

            Nick Boldt added a comment -

            Building in https://main-jenkins-csb-crwqe.apps.ocp-c1.prod.psi.redhat.com/job/DS_CI/job/code_3.6/7/console

            Nick Boldt added a comment - Building in https://main-jenkins-csb-crwqe.apps.ocp-c1.prod.psi.redhat.com/job/DS_CI/job/code_3.6/7/console

            Artem Zatsarynnyi added a comment -

            The upstream PR has been backported to 7.64.x

            Artem Zatsarynnyi added a comment - The upstream PR has been backported to 7.64.x

            Nick Boldt added a comment -

            Configuration option to be added (could impact performance if pulling assets from local cluster vs. from CDN). Blocker for 3.6.

            Nick Boldt added a comment - Configuration option to be added (could impact performance if pulling assets from local cluster vs. from CDN). Blocker for 3.6.

            Mirko Boettcher added a comment -

            Not sure, if the following is helpful for solving the issue. But I just came across this and wanted to share it. Code-Server has in its Repo quite a few patches for webview and serviceworkers. Maybe one of them helps?

            https://github.com/coder/code-server/blob/main/patches/service-worker.diff 

            https://github.com/coder/code-server/blob/main/patches/webview.diff 

            Mirko Boettcher added a comment - Not sure, if the following is helpful for solving the issue. But I just came across this and wanted to share it. Code-Server has in its Repo quite a few patches for webview and serviceworkers. Maybe one of them helps? https://github.com/coder/code-server/blob/main/patches/service-worker.diff   https://github.com/coder/code-server/blob/main/patches/webview.diff  

              vgulyy Vitaliy Gulyy
              azatsary Artem Zatsarynnyi
              Maksym Musienko Maksym Musienko
              Max Leonov Max Leonov
              Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated:
                Resolved: