Render an empty widget if we don’t have a renderer for the mimebundle types.

[jasongrout]

References

Fixes #6216

Code changes

This does render a blank non-classed div for outputs corresponding to things we can’t render, since we need the list of widgets to correspond to the output messages. So it's not exactly like the classic notebook (which doesn't render anything for things it doesn't understand), but from a user perspective perhaps this is good enough.

I suppose another way to do this is instead of all of the special-casing with adding class names, just hide the widget, which should do a display:none. However, we should check to make sure that the widget children iteration counts hidden widgets.

User-facing changes

There no longer is an error if we try to display a display_data message that has no recognizable mimetypes.

Backwards-incompatible changes

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[ian-r-rose]

Looks good to me, thanks @jasongrout!

[vidartf]

Can we at least have a console log/warning? It seems bad to fail to render a cell output, with no hints to the user about what can have gone wrong.

[ian-r-rose]

A warning to the console sounds reasonable to me.

[jasongrout]

Note that in this case (with papermill workflow), having an unrecognized mime type was supposed to happen, so it could generate quite a few errors with a console log/warning. I think generally things will have at least a text/plain mimetype.

[vidartf]

Sure, I just won't respond to any ipywidgets questions that are about why they are only getting the repr string ;)

[jasongrout]

Those cases aren't affected by this, because they do have a text representation, so the code is happy before and after this change just the same.

[jasongrout]

(this codepath is only exercised if there is no mimetype understood - that should be extremely rare in most cases. Except when using papermill, apparently.)

[vidartf]

@jasongrout Or if the mimetype is unsafe.

[jasongrout]

@jasongrout Or if the mimetype is unsafe.

Right, no mimetype understood includes the current safety level allowed. But again, the vast majority of mimebundles should have a text/plain representation (I thought all would), so this codepath isn't exercised hardly ever.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related discussion.