code-server: [Bug]: Problem opening .ipynb files (Jupyter Notebook)

Is there an existing issue for this?

  • I have searched the existing issues

OS/Web Information

  • Web Browser: Microsoft Edge / Chrome / Firefox / Vivaldi / Safari
  • Local OS: Windows 10.0.19044.1826 / macOS Big Sur 11.6.8
  • Remote OS: Raspberry Pi OS Lite (64-bit) 2022-04-04 (Kernel: 5.15 | Debian: 11 ‘bullseye’)
  • Remote Architecture: arm64
  • code-server --version: 4.5.2

Steps to Reproduce

  1. open code-server
  2. try to open .ipynb file
  3. trying to create an .ipynb file

Expected

The file should open and be viewable

Actual

Code-server keeps trying to open the file, or creating the file, never finishes loading on screen.

Logs

No response

Screenshot/Video

image

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

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 1
  • Comments: 45 (16 by maintainers)

Most upvoted comments

Hi all, I was able to simulate almost all possible cases in an orderly manner, and I was unable to replicate the problem:

  • Web Browser: Firefox / Chrome / Chromium-based spinoffs
  • Remote OS: Raspberry Pi OS Lite / Ubuntu Server / Containers
  • Local OS: Windows 10 / Windows 11 / MacOs / iPadOs/ Ubuntu / Raspberry Pi Desktop / Android

It didn’t really work well in only two cases:

  • Firefox on Android 9 (sorry, I don’t have a newer version)
  • LXC Ubuntu Server container (I’m sure it’s a ProxMox problem)

I suspect that when I generated the report for this bug, I had left the bind-addr setting at 0.0.0.0:8080, I didn’t realize that port forwarding via SSH wasn’t working (I use tmux); or I don’t know if I made some other mistake.

I want to thank you all for the support, and if no one has any more comments, I will close this case.

Thank you very much,

code-server-jupyter-working

Hi all, I was doing some tests, running code-server on two virtual machines with Debian v11.4 (clean install) and Ubuntu Server 22.04.1 (clean install), connected from Vivaldi 5.4 2753.40 (clean install) and always without HTTPS.

I found something curious, the bug only occurs when bind-addr is 0.0.0.0.0:8080 (whether or not to use password),

When bind-addr is 127.0.0.1.1:8080 and I use port forwarding with ssh (whether I use password or not); everything works normally:

code-server-port-forwarding-ssh

Apparently I must have PIP installed on the virtual machines as well.

There is supposed to be a popup warning on startup when using insecure contexts saying that certain functionality will not work because the browser does not allow them but we should instead make that popup appear at the point of trying to perform an action so it is more obvious why a certain feature is not working. So instead we would make it show every time a web view fails to open, when paste fails, and other things that will fail due to insecure contexts. In the specific case of web views it might be best to show that message right in the web view instead of a popup.

Also we should change the error message in the console to specifically say whether an insecure context is the problem instead of just “can’t compute”.

Hi all, I was doing some tests, running code-server on two virtual machines with Debian v11.4 (clean install) and Ubuntu Server 22.04.1 (clean install), connected from Vivaldi 5.4 2753.40 (clean install) and always without HTTPS.

code-server is required to be served via HTTPS to run code using service workers: Using Service Workers - Web APIs | MDN

I found something curious, the bug only occurs when bind-addr is 0.0.0.0.0:8080 (whether or not to use password),

When bind-addr is 127.0.0.1.1:8080 and I use port forwarding with ssh (whether I use password or not); everything works normally:

localhost is considered a secure origin by browsers as well.
ℹ️ This seems to apply applies for 127.0.0.1, the IP of localhost, too*.

*Tested with docker run --rm -it -p 8888:8888 registry.gitlab.b-data.ch/jupyterlab/python/base, accessing the server on both 127.0.0.1 and localhost.

I was not able to reproduce with the codercom/code-server:4.6.0 Docker image through Firefox (version 91.11.0esr).

@wolframalpha “Can’t compute sha-256” happens when crypto.subtle is not available which probably means the browser does not support it. Could you post your browser and browser version? Thanks!

@c-dasq and @Emporea could you confirm whether you see similar errors in the browser console or the Log (Window) output? (Ideally post the full output.) Thank you! It would also be helpful to check the network tab in the browser dev tools to see if anything is failing to load or hanging (I also recommend checking the “disable cache” box in the network tab to make sure it is not a caching issue).

https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subtle

Thank you all very much, I am going to close this issue.

To install ipykernel you have to go to the path where Python is (or change the path), and that’s it:

/usr/bin/python3 -m ipykernel install

I installed ipykernel (using your terminal) and now everything works perfect 😃

emporea - funciona ok

Can you do a test and let me know, please?

And now its not working again. Without me changing anything but closing the files and opening it up again multiple times.

Edit: (1hour later) its working again. I don’t know why there is this inconsistency.

Right now its working with my deployment too. I am even more confused.

I can see wibdwbv.ipynb

@wolframalpha In your case: Another problem is, that you are not serving code-server via HTTPS. See #5475 (comment).

Oh yeah that makes sense, the browser crypto API is only available in secure contexts I believe.

From https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subtle:

Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

I could not reproduce this issue at https://demo.jupyter.b-data.ch (OS: Debian bullseye, Arch: amd64, code-server: v4.6.0); with none of my custom docker images.

I could not reproduce it running my custom docker images locally (OS: Debian bullseye, Arch: arm64, code-server: v4.6.0) either.

ℹ️ Extension versions: ms-toolsai.jupyter@2022.8.1002170547, ms-python.python@v2022.12.1.

  • Web Browser: Firefox 104.0 (64-bit)
  • Local OS: macOS 12.5.1 (Monterey)

Can you please complete the bug report template?