mathjax affects dropdown options inconsistently

[mheilman]

I noticed some strange behavior where dropdown options get rendered (I think) as equations by mathjax, but only when multiple dropdowns are displayed at the same time.

As a workaround, is there a way to disable MathJax for a single dropdown?

versions:

• notebook==5.1.0
• ipywidgets==7.0.3
• Python 3.6.2 :: Continuum Analytics, Inc.
• Chrome on MacOS

[mheilman]

It looks like if v only has one $ in it (e.g., '$0 - 10'), then mathjax doesn't ever get triggered. (That's probably my workaround for now.)

[jasongrout]

You can use \$ to get a single dollar sign as well: \$0 - \$10.

[mheilman]

Hmm... if I do \$0 - \$10, then I get the opposite behavior, but thanks, that might be a better workaround if I know there's gonna be multiple dropdowns.

[jasongrout]

I'm testing this - and I'm not getting mathjax rendering dropdown options (notebook 5.2, though). I'm checking notebook 5.1 right now.

[jasongrout]

Never mind, I just reproduced the issue.

[jasongrout]

I think it has to do with the display call, and display triggering a math rendering run. With the original code, either HBox([d,d]) or display(HBox([d,d])) works for me.

[mheilman]

Interesting. Are you on notebook 5.2? Putting the dropdowns in an HBox doesn't seem to solve it for me.

[jasongrout]

I tried that in notebook 5.1.0:

I think this will reproduce my environment:

conda create -c conda-forge --override-channels -n delete-1777 notebook=5.1 ipywidgets
source activate delete-1777
ipython kernel install --name delete_1777 --sys-prefix

[jasongrout]

I just checked JupyterLab, and it doesn't have a problem at all.

[jasongrout]

Definitely something weird going on. With the above environment setup, here's what I get:

[mheilman]

fwiw, this doesn't seem to affect Label but does seem to affect RadioButtons and Select. I haven't tried all the _Selection subclasses.

[jasongrout]

I think this may be a bug in the notebook display logic. For example, see https://github.com/jupyter/notebook/blob/master/notebook/static/notebook/js/outputarea.js#L651 - you'll notice that the code just checks to see if there is an html mimetype in the message, and if so, it appears to typeset the entire output area. In contrast, the JupyterLab implementation explicitly just typesets the specific output if needed (IIRC), not the entire output area.

[mheilman]

Ah, nice find.

probably related: jupyter/notebook#2444, jupyter/notebook#2450

[jasongrout]

I just traced this down in the Chrome debugger to the issue in the notebook. Let's track this at the notebook issue, where the real problem is.

Note that we probably didn't trigger this until #1674, when we added an html mimetype to the widget display messages so we could have links to the documentation. It may make sense for us to roll back the #1674 because of this notebook bug.

The purpose in having an html mimetype in the display message was so that one message could show up in a notebook, while a different message could show up in the terminal.

[jasongrout]

@ssanderson - given the above (breaking things in the current notebook because of a bug in the current notebook), what do you think of reverting #1674 so that we don't have an html error message anymore?

[jasongrout]

Moving to 7.x - I think we'll really need to change the html error message to work around this bug.

[ssanderson]

@jasongrout is there somewhere else we can put that error message that will still be visible without causing this bug (e.g., in the regular text repr)?

[jasongrout]

The text mimetype is already being used for a very simple rendering. We could probably put a small message there if we needed to.

[jasongrout]

The notebook issue is at jupyter/notebook#2980.