The ability in Jupyter Notebook to access IPython from the page’s JavaScript runtime is missing in JupyterLab (I think because of the web packer)

JupyterLab
1

I created a feature request for IPython to be exposed as a window object again but maybe any of you know a workaround.

I want to develop a platform within Jupyter with better styling than Widgets by using HTML/JavaScript. I don’t want to require the user to install a plugin (since I believe the functionality is there, just hidden by the code packer).

If you’re dubious about my use-case, that’s probably fair. Here’s what I have in mind:

The “missing” link (again I believe just hidden by the web packer during build) In Jupyter Notebook is the feature described in this StackOverflow question:

They’re complaining about something that’s not really a good use-case (trying to make the anync JS code affect the current cell’s synchronous output) but just the capability to access IPython is what I mean.

JavaScript executed within a cell accesses window.IPython and tells Jupyter to execute some Python. This works just fine in Jupyter Notebook: Javascript('''IPython.notebook.kernel.execute("my_out = 'hello world'");'''). But fails in JupyterLab.

1 Like
2

This is by design, and is unlikely to change in core.

You have a few options:

There may be some extension out there that shims the window-level object, but I don’t know, and wouldn’t really trust it.

1 Like
3

Any idea if expose_app_in_browser was a feature associated with some CVE related to XSS or something? Or do you know why Jupyter Notebook still supports this but Jupyter Lab chose to change it? Seems like both teams would be on the same page if it’s a security thing.

Thanks for the resources by the way.

4

It’s less about security (you’re in the browser, with a hot shell executor: there’s nothing to keep bad actors out) and more about stability and maintainability: notebooks (or worse, libraries) that heavily rely on “raw” js features are not portable across frontends, as differences like the multi-document nature of JupyterLab makes it much harder to reason about which Jupyter.kernel would do something.

With the modular nature of jupyterlab, many aspects of race conditions, acquiring third party libraries, etc. are resolved at build and install time instead of at runtime. This is less convenient for one-off apps, but is far easier for (volunteer) maintainers over time.

The forthcoming Notebook 7 will share this architecture, so the days of IPython.execute("eval()") are numbered, for certain.

1 Like
5

That makes more sense. Thanks for the answers.