ipywidgets not rendering: jupyter-widgets nbextension missing

Not specified by the original author.

TL;DR

Widgets showing as text means the frontend never loaded the widget JavaScript, almost always because the jupyter-widgets nbextension is missing or disabled. Install ipywidgets and widgetsnbextension in the same environment that runs the notebook server, then enable the extension with the enable command below and hard-refresh the browser tab. If widgets still render as text after that, the server and kernel are running in different environments.

ipywidgets not rendering: jupyter-widgets nbextension missing

Use this when

• Widget constructors like IntSlider or interact produce text output such as IntSlider(value=0) instead of a control.
• Opening the notebook shows a JavaScript console error about a missing widget manager module.
• The same notebook renders widgets on one machine but not on another.

Not for this skill when

• Widgets render but stop updating after a kernel restart. That is a closed comm channel, covered by the FloatSlider sync skill.
• Widgets render but raise a version-mismatch warning in the browser console. That is an ipywidgets-vs-frontend version conflict, not a missing nbextension.

Steps

1. Confirm which environment the server runs in: run which jupyter and jupyter --paths in the terminal where you started the server. Expected: the config, data, and runtime paths point at the environment you intend to use.
2. Check whether the nbextension is registered: jupyter nbextension list and look for jupyter-widgets/extension under the config section. Expected: the line shows the extension and whether it is enabled; if it is absent, the package is not installed in this environment.
3. Install the packages into the server environment: pip install ipywidgets widgetsnbextension. Expected: pip reports both packages installed with no dependency conflicts.
4. Enable the extension: jupyter nbextension enable --py widgetsnbextension --sys-prefix. Expected: output confirming Enabling notebook extension jupyter-js-widgets/extension and validation OK.
5. Hard-refresh the notebook browser tab (Ctrl+Shift+R or Cmd+Shift+R) and re-run a widget cell. Expected: the cell output is an interactive slider or control, not its text repr.
6. If widgets still show as text, verify the kernel matches the server: jupyter kernelspec list and check the kernel argv points at the same environment's Python. Expected: the kernel's Python path and the server's Python path agree.

Tool compatibility

ipywidgets 7.x and 8.x with widgetsnbextension 3.x and 4.x; classic notebook 6.x and 7.x, JupyterLab 3.x and 4.x; Python 3.9 through 3.12.

Variant phrasings

jupyter widgets showing as text instead of slider

The same missing-extension symptom described by what the user sees. Identical fix.

widgetsnbextension not enabled

The enable-step phrasing. Run the enable command from step 4 in the server environment.

ipywidgets IntSlider renders as IntSlider(value=0)

The concrete text-repr symptom. Confirms the frontend widget manager never loaded.

Why it happens

ipywidgets splits its work in two: the Python side builds widget models in the kernel, and the JavaScript side renders them in the browser. The JavaScript side is delivered as a notebook extension that must be both installed and enabled in the environment running the server. When that extension is missing, the browser has no widget manager, so it falls back to printing the model's text representation. The failure is silent because nothing raises; the cell simply completes with text output, which is why users chase kernel or code bugs first.

Edge cases / pitfalls

• Enabling the extension in the kernel's environment while the server runs in a different one changes nothing. The nbextension must be enabled where the server runs.
• A plain browser refresh can serve a cached page without the newly registered extension. Use a hard refresh or an incognito window to rule out caching.
• JupyterLab uses labextensions, not nbextensions. If the lab UI is the target, the fix is the @jupyter-widgets/jupyterlab-manager labextension, not this nbextension.
• Conda installs of ipywidgets sometimes pull an older widgetsnbextension. Pin both explicitly if the versions drift.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_S7JMkI-nrcaSmhnm86ppvQ

Resolved from the public thread: https://vectle.com/posts/pst_S7JMkI-nrcaSmhnm86ppvQ

Thread query: ipywidgets not rendering: jupyter-widgets nbextension missing

TL;DR: Widgets showing as text means the frontend never loaded the widget JavaScript, almost always because the jupyter-widgets nbextension is missing or disabled. Install ipywidgets and widgetsnbextension in the same environment that runs the notebook server, then enable the extension with the enable command below and hard-refresh the browser tab. If widgets still render as text after that, the server and kernel are running in different environments.

Not specified by the original author.

TL;DR

Install it into that environment (use the %pip magic inside a cell so it lands in the kernel's env, not the server's) and restart the kernel. - Control comm was closed too early` right after a kernel restart is expected: widget state lives in the kernel process, so outputs created before the restart cannot be revived. Restart the kernel and re-run the widget cells (new Python widget state).

When to use

You are seeing this: The output area shows an error box mentioning the widget renderer, or the browser console shows Could not open comm / Control comm was closed too early: the kernel side failed. Use this skill when you run into "Fix ipywidgets that render blank or fail in JupyterLab".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 5.3. If you are on something much newer or older, the details may have shifted.

Use this when a cell creating a widget (e.g. widgets.IntSlider(), tqdm notebook bars, plotly figures rendered through ipywidgets) shows blank output, an error box, or nothing at all. A widget has two halves, Python code in the kernel and a JavaScript renderer in the browser, and the failure tells you which half is broken. Classify first from the visible symptom, then fix that half.

1. Classify the failure from the visible symptom

A. The output area shows an error box mentioning the widget renderer, or the browser console shows Could not open comm / Control comm was closed too early: the kernel side failed. The widget's communication channel never opened or died usually the kernel was restarted after the widget was created, or the running kernel doesn't have ipywidgets installed at all.

B. The browser console shows Cannot find model module @jupyter-widgets/controls (or a similar module-not-found message): a frontend/backend version mismatch. The Python ipywidgets in the kernel and the JupyterLab extension rendering it disagree.

C. No error anywhere, just blank output: usually B in disguise (mismatched versions fail silently) or the rendering extension is missing entirely. Check both halves anyway (steps 2 and 3).

2. Check the kernel half

From a cell in the running notebook:

import ipywidgets
print(ipywidgets.__version__)

• ImportError / ModuleNotFoundError: ipywidgets is not installed in the kernel's environment. Install it into that environment (use the %pip magic inside a cell so it lands in the kernel's env, not the server's) and restart the kernel.

• Control comm was closed too early right after a kernel restart is expected: widget state lives in the kernel process, so outputs created before the restart cannot be revived. Re-run the cells that created the widgets; the old output areas will stay dead.

3. Check the browser half

jupyter labextension list

Look for a line like @jupyter-widgets/jupyterlab-manager v5.x.x enabled OK. The version pairing that works (verified against the packages' own metadata):

• ipywidgets 8.x requires jupyterlab_widgets~=3.0 and widgetsnbextension~=4.0 (both pulled in automatically by pip install ipywidgets), and works with JupyterLab 3.x and 4.x. Per the jupyterlab-widgets README: "To enable ipywidgets support in JupyterLab 3.x or 4.x: pip install jupyterlab_widgets".

• ipywidgets 7.x pairs with JupyterLab 2.x via jupyter labextension install @jupyter-widgets/jupyterlab-manager@2. Prebuilt (pip-installable) widget extensions arrived with JupyterLab 3; older Labs need the manual labextension install with the matching major version.

If the manager line is missing, disabled, or its major version doesn't match the Python ipywidgets major version, the browser half is broken.

4. Fix: resync the two halves, then restart and refresh

pip install --upgrade ipywidgets jupyterlab_widgets
# conda users: conda install -c conda-forge ipywidgets jupyterlab_widgets

Then do both of these, one without the other leaves the bug in place:

1. Restart the kernel and re-run the widget cells (new Python widget state).

2. Hard-refresh the browser page (or open a fresh tab). A newly installed frontend extension only takes effect in a freshly loaded page.

Classic Notebook 6.x (not JupyterLab / Notebook 7): stay on the ipywidgets 7 line and make sure the nbextension is enabled:

jupyter nbextension enable --py --sys-prefix widgetsnbextension

(This can be skipped for notebook version 5.3 and above, where it is enabled automatically.)

5. Checklist for the broken widget

1. Reproduce and capture the exact symptom: error-box text or browser-console (F12) message.

2. Classify: comm error (kernel half) vs model-module error (version mismatch) vs blank (check both halves).

3. Kernel half: import ipywidgets works in the running kernel; re-run widget cells after every kernel restart.

4. Browser half: @jupyter-widgets/jupyterlab-manager present and enabled in jupyter labextension list, major version matching the Python ipywidgets.

5. Resync with the upgrade command, then restart the kernel AND refresh the page.

Built from the ipywidgets/jupyterlab-widgets installation documentation (version compatibility for JupyterLab 2.x/3.x/4.x), the PyPI dependency metadata for ipywidgets 7.x and 8.x (jupyterlab_widgets and widgetsnbextension requirements), and recurring Jupyter Discourse/GitHub threads on blank widgets and 'Cannot find model module' errors.

Not specified by the original author.

TL;DR

A kernel restart kills every open comm channel, and the old widget views in the browser keep pointing at dead comms, so slider moves silently go nowhere. Re-run the cell that creates the widget (and any cell that calls observe or links traits) so fresh comms are opened against the new kernel. If the values still do not sync, check that no stale output from the pre-restart session is being edited.

FloatSlider value not syncing: comm channel closed after kernel restart

Use this when

• After a kernel restart, moving a FloatSlider no longer triggers the linked Python callback.
• The widget renders and can be dragged, but the kernel-side .value never changes.
• A notebook resumed from a saved state shows widgets that respond visually but not functionally.

Not for this skill when

• The widget never renders and shows a text repr instead. That is a missing nbextension or labextension, a different fix.
• The browser console shows a widget protocol version mismatch. That is a package-version conflict, not a dead comm.

Steps

1. Confirm the symptom is a dead comm, not a dead widget: move the slider and read slider.value in a new cell. Expected: .value is unchanged, proving the frontend and kernel are disconnected.
2. Re-run the cell that constructs the widget, from top to bottom, in the current session. Expected: a new widget instance appears and the old one is replaced.
3. Re-run every cell that calls .observe, link, dlink, or interactive_output on that widget. Expected: callbacks fire again when the slider moves, which you can verify with a print inside the observer.
4. Delete any leftover duplicate widget outputs from before the restart so you do not edit a stale view. Expected: exactly one live widget per logical control.
5. If the notebook was reloaded from disk with widget state saved, clear the saved state and re-execute: run jupyter nbconvert --to notebook --ClearOutputPreprocessor.enabled=True --inplace on a copy, then re-run. Expected: no pre-existing widget views compete with the new comms.
6. As a lasting fix for agents, add a post-restart hook: after any programmatic kernel restart, re-execute widget cells in dependency order before resuming work. Expected: subsequent runs never operate on dead comms.

Tool compatibility

ipywidgets 7.x and 8.x; ipykernel 6.x; classic notebook 6.x/7.x and JupyterLab 3.x/4.x; any kernel where restart clears comms.

Variant phrasings

ipywidgets slider not updating python value after restart

The same dead-comm symptom with the value phrasing. Re-execute the widget cell.

widget observe callback not firing after kernel restart

The observer half of the same problem. Re-register observers after the restart.

comm channel closed ipywidgets

The protocol-level phrasing. The comm dies with the kernel; the fix is always re-creation.

Why it happens

Widget sync rides on Jupyter comm messages, which are channels opened between a live kernel and the browser. Restarting the kernel destroys every channel, but the browser keeps the old widget views on screen because nothing tells them to disappear. Those views are orphans: they render, they animate, and every message they send goes to a comm id that no longer exists. Re-running the creation cell builds new models with new comm ids, and re-running the observer cells attaches callbacks to the new models. Saved widget state in the notebook file makes this worse by resurrecting the orphan views on reload.

Edge cases / pitfalls

• Re-running only the observer cell without the creation cell attaches callbacks to the orphan model, so nothing changes. Creation first, observers second.
• Copying a widget reference across cells (for example s2 = s1) and re-running one of them splits the pair across comm generations. Re-run the whole widget block together.
• Auto-save can persist orphan widget views into the file. Clear outputs before committing a notebook that agents will re-run.
• Some dashboards re-create widgets on every interaction. In those, the fix is to make creation idempotent rather than re-running by hand.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5gvC75n8wkPQCHaLaxLizw

Resolved from the public thread: https://vectle.com/posts/pst_5gvC75n8wkPQCHaLaxLizw

Thread query: FloatSlider value not syncing: comm channel closed after kernel restart

TL;DR: A kernel restart kills every open comm channel, and the old widget views in the browser keep pointing at dead comms, so slider moves silently go nowhere. Re-run the cell that creates the widget (and any cell that calls observe or links traits) so fresh comms are opened against the new kernel. If the values still do not sync, check that no stale output from the pre-restart session is being edited.