ipywidgets randomly missing (again) in test notebook

[parente]

Tasks:

• Fix it
• Update to jupyter-js-services 0.10.2
• Update to next version of ipywidgets/jupyter-js-widgets

---

Original Description:

Using:

• dashboards_server 0.5.0
• ipywidgets 5.0.0
• jupyter-js-widgets 1.0.0
• decl widgets 0.5.1

OR:

• dashboards_server 0.6.0-dev (master)
• ipywidgets 5.1.1
• jupyter-js-widgets 1.1.1
• decl widgets 0.5.2

And deploying this notebook:

https://gist.github.com/parente/bcdaab0b004d22dadd60c811240ea048

Sometimes the labels on the ipywidgets widgets go missing. Sometimes the entire widgets go missing. It varies from refresh to refresh.

Expected (seen in notebook):

Result (seen in dashboard server):

Worth noting

• The notebook uses ipywidgets (heavily) AND declarative widgets. Some of our simple test notebooks do this to, but not to the extent used here. (Another timing issue?)
• It appears that when the decl widgets are removed from the notebook, the ipywidgets work as expected and never have issues.

[jhpedemonte]

See this comment (and others in that issue) from Sylvain about potential timing issues around Label.

[parente]

Looks to be another ipywidgets timing bug. Can't be related to requirejs because we're now webpacking all of ipywidgets into our build to avoid jupyter-widgets/ipywidgets#561. But the consequence sure looks like the issue we reported before against ipywidgets.

/cc @SylvainCorlay @Carreau because I get the feeling the bug mentioned on standup yesterday and the timing issues we've seen are intertwined.

[parente]

Findings so far

• The same notebook works in Jupyter Notebook server 4.2 with ipython 4.2.0, declarative widgets 0.5.2, and ipywidgets 5.1.3.
• With all of the same versions as the above, remove code that initializes declarative widgets from the dashboard server, and suddenly all of the ipywidgets work in the dashboard server.
• Strictly sequence the ipywidgets version validation followed by the initialization of decl widgets, and the ipywidgets are still broken the dashboard server.
• Strictly sequence a comm_request followed by the initialization of decl widgets, and the ipywidgets are still broken in the dashboard server.

Thought: We're webpacking all of ipywidgets, but loading declarative widgets asynchronously. Decl widgets also loads all of its modules async. Is the use of async require for decl widgets somehow tripping up ipywidgets thereafter?

/cc @lbustelo

[SylvainCorlay]

I have experienced the same timing issue in an example corresponding to

web3 example + custom widgets (asynchronously loaded model)

[parente]

web3 example + custom widgets (asynchronously loaded model)

Yep. Root cause here is the same as in jupyter-widgets/ipywidgets#561: when loading any modules asynchronously, classes from jupyter-js-widgets also start getting resolved asynchronously because of the logic in the utils.js loadClass and stop working properly. So it's not the async load that's the problem per se. It's some code in ipywidgets that is depending on the load promise getting resolved immediately.

More details about what's happening here in dashboard server with decl widgets vs not ...

As soon as window.requirejs.defined('jupyter-js-widgets') becomes true, loadClass function in ipywidgets starts taking the branch that uses window.require instead of immediately resolving with the webpacked version of jupyter-js-widgets. When we have a notebook that only uses ipywidgets, defined('jupyter-js-widgets')remains false because nothing requires it explicitly. This is why a notebook with only ipywidgets works fine. When we have a notebook that uses declarative widgets, defined('jupyter-js-widgets') becomes true because the declarative widgets require jupyter-js-widgets explicitly. Once defined is true, everything takes the window.require path in loadClass, including all requests for jupyter-js-widgets. This should not be a problem since the require call ultimately returns the same webpacked widgets module. But it is a problem because somehow the async require causes labels, default values, or sometimes entire widgets not to appear on the page.

@jhpedemonte is going to add more detail to jupyter-widgets/ipywidgets#561. We should continue the convo there. (This defect is just a symptom.)

[parente]

The remaining work here is to update to jupyter-js-services 0.10.2 and whatever version of ipywidgets ends up containing the other half of the fix (5.1.5?).

[SylvainCorlay]

Yeah I will continue making minor releases of ipywidgets.