ipywidgets not working after changing kernel

[sdissegna-maystreet]

Environment data

• VS Code version: 1.61.2
• Jupyter Extension version (available under the Extensions sidebar): main branch
• Python Extension version (available under the Extensions sidebar): v2021.10.1365161279
• OS (Windows | Mac | Linux distro) and version: macOS 10.15.7
• Python and/or Anaconda version: 3.9
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
• Jupyter server running: Local

Expected behaviour

After changing kernel, cells with ipywidgets can be re-run to show the widgets.

Actual behaviour

After changing the kernel, ipywidgets stops working.

Steps to reproduce:

Given a notebook containing a single cell with this code:

import ipywidgets as w
w.IntSlider()

If you run it, it will show a widget. If you now change kernel, then change back to the original kernel, and then run it again it will no longer show a widget. If you close the notebook and re-open it, it will work.

[IanMatthewHuff]

@sdissegna-maystreet Thanks for the repro on this. I repro the same thing on current bits. When I change the kernel th first time that I change the kernel the cell with the widget can run, but no widget appears. If I try to run the cell a second time the cell runs forever without finishing:

[zpincus]

This is also even more of an issue when using a remote jupyter server: I haven't been able to figure out how to get ipywidgets working ever again in a notebook, while that notebook is associated with a particular kernel running on the remote jupyter server. That is, once you choose a specific running kernel from the kernel chooser, closing and reopening the notebook file, or reloading the UI or closing and reopening the workspace, or even quitting and restarting vscode will not restore ipywidgets.

The only way to get the widgets to work again for that notebook file is to choose the entry in the kernel picker that creates a new kernel (rather than reconnecting to an existing kernel), then close and reopen the file (or reload the UI), then re-attempt.

I presume/hope #8096 will also fix this case too, but it would certainly be good to check.

[zpincus]

Unfortunately, even with the new changes in Jupyter extension version 2021.10.100, this bug in fact does still affect reconnecting to existing sessions on a remote server.

That is, connecting to a new kernel (and creating a session on the remote server) now no longer breaks ipywidgets, but when re-connecting to an existing session, widgets are still broken.

The easiest steps to reproduce this are:

1. Switch to remote jupyter.
2. Make two cells like so:

import ipywidgets

ipywidgets.IntSlider()

3. Run all cells; note that the slider appears.
4. Close notebook and reopen, or just reload the UI via the "reload" command.
5. Due to Opening a notebook on remote, closing it, and reopening it does not reuse the same kernel #7610 you are actually now in a new session (you can verify by trying to run cell 2 and getting an NameError).
6. Click on the "select kernel" button in the vscode UI, and select the existing session (which is the one created in step 3).
7. Run just the second cell again. No NameError, but no slider either.

If you then go to the kernel picker and create a kernel session, you can run both cells and the slider reappears. But again connecting back to the existing session, the slider will not appear and ipywidgets remains broken.

@IanMatthewHuff would you prefer I create a new issue for this part of the bug, or just keep it all in this issue?

[DonJayamanne]

@zpincus I've created an issue here #8179
Please could you confirm this works for local kernels, that way we can close this issue and track the work for remote kernels on #8179 and we'll try to get that fixed in a recovery build.

[zpincus]

Sorry for not noting this above, but I can confirm that on v2021.10.1001414422 of the Jupyter extension, not only does ipywidgets work when changing kernels on the local server (which starts a new kernel every time), but it also works on remote servers when starting up new kernels. It's only broken when connecting to an existing kernel on remote servers, so this is definitely progress :)

[DonJayamanne]

Thanks for your feedback.
I'm currently looking into the issue related to the remote kernels. We'll try to get that into a recovery release for next week.