A modest proposal: jupyter lab should present notebooks in iframes

225 views
Skip to first unread message

Aaron Watters

unread,
Sep 3, 2019, 3:08:49 PM9/3/19
to Project Jupyter
I have reservations about Jupyter lab and I don't want to see "classic notebooks" going away primarily for the following reason:

My strongest attraction to Jupyter is that it provides a platform for combining the Python interpreter with Javascript based tools
and visualizations.  For that reason I want to use and develop lots of Javascript for use inside Jupyter.

If in "classic" notebook the javascript interpreter falls in to an infinite loop or has a memory leak or some other performance issue...
just close the browser tab.  Other notebooks are usually unaffected. Nice!

If in the Jupyter lab interface  the javascript interpreter falls in to an infinite loop or has a memory leak or some other performance issue...
all the notebooks and other features in the Jupyter Lab interface stop working.  Not nice.

It might be possible to make the lab interface as robust as "classic" if Jupyter lab embedded each notebook in an iframe with an independent web context.
I'm unsure of the details of managing iframes or other implications.

I think that this is the approach adopted by google colaboratory for example https://colab.research.google.com/notebooks/welcome.ipynb

Thanks to everyone for all the great work on Jupyter related projects -- I just needed to get this comment off my chest.
Please comment or correct me.

   -- Aaron Watters

Jason Grout

unread,
Sep 3, 2019, 3:17:45 PM9/3/19
to Project Jupyter
Thanks for commenting on this! Do you want to open an issue on the JupyterLab repo about this where we can discuss more in detail the implications?

For example, someone could write a notebook opener that would use iframes for isolation and would work alongside everything else in jlab. That might be a really interesting extension idea to explore.

Thanks,

Jason


--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/f625f4c4-1ea5-48a6-853c-89afd09ac2d6%40googlegroups.com.

Afshin T. Darian

unread,
Sep 3, 2019, 3:19:31 PM9/3/19
to jup...@googlegroups.com
Hi Aaron,

Thanks for writing. If you have a test case that you can contrive to crash JupyterLab, we'd love to try to address the issue head on.

But in the absence of that, here's what I surmise would happen if you did run into a notebook that causes a runaway JS thread to cause JupyterLab to become unresponsive:

1. Let's say you execute a cell and its result is that the web app becomes unresponsive.
2. Like many web apps, you would either refresh the tab or you would close it and open a new one.
3. When the new tab opens, it would restore the state of JupyterLab to the last known saved state.
4. Your broken notebook would be open and you could either close it or modify the contents of the offending cell.

I think you'd basically be in the same situation you were in the classic notebook because of JupyterLab's layout/state restoration.

As far as using iframes, they bring with them a lot of trouble, which makes them unsuitable for an application like JupyterLab. They become a "dead zone" in terms of drag and drop interoperability with the rest of what is on your screen. Also, they don't have programmatic access to the rest of the JupyterLab application and it makes interacting with other extensions quite difficult.

Thanks again for reaching out. If you do have a test notebook you'd like us to look at, please reach out again or please file an issue https://github.com/jupyterlab/jupyterlab/issues/ so we can track it!

Cheers!

-Darian

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAPDWZHz%3DQOh_E_RwuobM9Ye3zGNQ2QMi3UmYM1HD3PW_REKZfQ%40mail.gmail.com.

William Stein

unread,
Sep 3, 2019, 3:50:48 PM9/3/19
to jup...@googlegroups.com
On Tue, Sep 3, 2019 at 12:08 PM 'Aaron Watters' via Project Jupyter
<jup...@googlegroups.com> wrote:
>
> I have reservations about Jupyter lab and I don't want to see "classic notebooks" going away primarily for the following reason:
>
> My strongest attraction to Jupyter is that it provides a platform for combining the Python interpreter with Javascript based tools
> and visualizations. For that reason I want to use and develop lots of Javascript for use inside Jupyter.
>
> If in "classic" notebook the javascript interpreter falls in to an infinite loop or has a memory leak or some other performance issue...
> just close the browser tab. Other notebooks are usually unaffected. Nice!
>
> If in the Jupyter lab interface the javascript interpreter falls in to an infinite loop or has a memory leak or some other performance issue...
> all the notebooks and other features in the Jupyter Lab interface stop working. Not nice.
>
> It might be possible to make the lab interface as robust as "classic" if Jupyter lab embedded each notebook in an iframe with an independent web context.
> I'm unsure of the details of managing iframes or other implications.
>
> I think that this is the approach adopted by google colaboratory for example https://colab.research.google.com/notebooks/welcome.ipynb


In Colab each *output area* is a separate iframe, not the entire
notebook. That's a bit different than "embedding each notebook in an
iframe". It has pros and cons. I gather from Google's point of view
that it is absolutely necessary to use iframes in order to prevent
certain types of security vulnerabilities. (Of course, Google is a
major target for malicious attacks.) I think a significant technical
difficulty with this iframe approach is that each iframe has to load
some javascript in order to know how to render itself, and doing this
in an efficient way requires care -- Pete Blois at Google has done
clever things to make this approach work very well for colab,
especially with ipywidgets. Of course, try opening a notebook with
500 visible cells with output in Colab, and watch things die badly,
due to trying to create 500 nontrivial iframes.

In CoCalc we also provide no real isolation, just like JupyterLab
doesn't, except for our "Classic Mode" Jupyter notebook, which is
embedded in an iframe (see
https://doc.cocalc.com/jupyter.html#classical-versus-cocalc).

Afshin:
> If you have a test case that you can contrive to crash JupyterLab, we'd love to try to address the issue head on.

Put this in a Jupyter notebook and run it, then your browser tab is
instantly and completely locked.

%%javascript
while(1){}

For me I can't even refresh the page without opening the Task Manager
then killing the relevant process (which ends up killing several other
tabs too in my case, though that is random). I'm using a Pixel
Slate.

Trying this in colab isn't quite as bad, though I still had to kill
the whole tab and start over there.

(and my personal thoughts about this, in case anybody cares below...)

Personally, based on my experience with tens of thousands of users on
Cocalc.com, people don't use %%javascript and cause infinite loops
much -- we've never once had a support request related to this. So we
haven't prioritized addressing this problem. Also, as mentioned
above, using iframes doesn't guarantee things just work as you want in
practice, since what happens depends a lot on specific browser
implementations and optimizations. That said, I'm very interested in
pretty much everything related to Jupyter and all the possibilities to
make the experience better, so I'm glad to see this thread!

There are other similar problems with Jupyter that might be considered
as just as serious, e.g., if you type things like this (with a python
kernel), you'll quickly be very unhappy:

os.system("rm -rf /")

or

while(1) { open("a",'a').write("x"*10000) }



--
William (http://wstein.org)

Aaron Watters

unread,
Sep 3, 2019, 4:12:29 PM9/3/19
to Project Jupyter
Thanks Darian,

I'm concerned that there is precisely one Javascript thread shared by all notebook interfaces in Jupyter Lab.
I will try to come up with an example involving animation running in multiple notebooks that causes performance degradation.

I agree that iframes are difficult to deal with. I think the additional robustness might be worth it.  Regarding your specific objections:

1) dropping "dead zone" -- this may be -- I don't know.  I'm personally probably willing to sacrifice this use case.  I never "drop" anything into a notebook myself.
2) iframes can't communicate with the rest of the application -- I think you could mediate communication between iframes if necessary on the server side.

Thanks for the reply and comments!  -- Aaron Watters
To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.

Pete Blois

unread,
Sep 3, 2019, 7:25:17 PM9/3/19
to jup...@googlegroups.com
As a maintainer of quite of bit of Colab's iframing infrastructure: it does a good job of isolating for security but it's not great at preventing the `while (true) {}` case. The reason is that if the iframe is just a srcdoc iframe then it shares the same thread, so a hang there will still hang your entire page. If the iframe is using a separate origin then with Chrome's OOPIF feature it will wedge all iframes across all tabs, in even worse ways. OOPIF's are still pretty new. Today, when dealing with while (true), the non-iframed error model is superior.

I'm a strong believer in the value of the security model offered by iframes, but they are non-trivial to implement.

try opening a notebook with 500 visible cells with output in Colab, and watch things die badly, due to trying to create 500 nontrivial iframes.
Yeah, there are a number of tricks... If the 500 cells were generated by Colab then the resulting height of the output is also written to the notebook file so a placeholder can be rendered instead. Then IntersectionObserver is used to only render the output when it becomes visible. This also helps minimize resize jank when loading a large notebook. 500 cells is still... a whole lot of cells.

To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/39b73eb6-0b13-480b-b643-a53edd334118%40googlegroups.com.

Afshin T. Darian

unread,
Sep 4, 2019, 3:51:59 AM9/4/19
to jup...@googlegroups.com
This has turned out to be an interesting conversation. Thanks, everyone!

William, I love your pathological case. You're right, of course. I think I am lumping all situations where you need to kill the tab as basically on the same tier of user irritation.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CACvpcBEddR47TCUJh1PjGZnTntvKLsbr8tX1KH2_d0%2BtYYXFjw%40mail.gmail.com.

Aaron Watters

unread,
Sep 4, 2019, 8:14:58 AM9/4/19
to Project Jupyter
 %%javascript
while(1){}

This is the kind of thing I'm concerned about, but occurring in more complex ways,
like from bugs in Javascript libraries used to build widgets.  In the case of classic notebook running in Chrome
on Mac this code locks up the notebook tab, but I can close the browser tab and other notebooks
are not affected (when I tried it just now).  In lab the entire web app locks up including all notebooks.

From my user perspective reloading the "lab" application is quite confusing -- I don't understand
what state the kernels for the Notebooks are in and how that state relates to widgets and other
aspects of the Javascript context.

I would like a situation as much like an "xterm" as possible -- where a poorly behaving component
can just be killed without adversely affecting other activities and a slow Javascript activity in one
notebook does not directly slow down the rest of the application.

Thanks again!  -- Aaron Watters


--
You received this message because you are subscribed to a topic in the Google Groups "Project Jupyter" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jupyter/jnsXG-RmbE0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jupyter+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CACLE5GCJC%3DgjOe9f%3Dz5ah7cNTf%3DX8SNuX%3Dy8KDEAqGGMwPLcZA%40mail.gmail.com.

Jason Grout

unread,
Sep 4, 2019, 10:57:58 AM9/4/19
to Project Jupyter
And also thanks Pete for detailing how an iframe's js execution affects the rest of the page!

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAJ%2BUHtcy4iaxE5fJ86%3DEtP4SNodwp6wJr2z5%2B2sEUz7CG9anJg%40mail.gmail.com.

vidartf

unread,
Sep 5, 2019, 6:30:01 AM9/5/19
to Project Jupyter

A possible suggestion when you are working on "experimental" JS could be to open lab in multiple browser tabs, and run the experiments separately. This will allow you most of the benefits of lab, with extra JS threads at the same cost as for classic notebooks (extra browser tabs).

If this seems reasonable, you could even make the experience smoother by adding a lab extension that allows you to open notebooks from the filebrowser in a new lab tab (take the URL as in "Copy shareable link" and open that in a tab). Or that could be contributed to core if it is popular enough?

I don't know if this is a tenable workaround or not.

Vidar

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.

Aaron Watters

unread,
Sep 5, 2019, 3:18:17 PM9/5/19
to Project Jupyter
For the record I put together a repository that documents animation anomalies that occur in "Lab" but not in "Classic"


thanks again for the comments! -- Aaron Watters

On Tuesday, September 3, 2019 at 3:19:31 PM UTC-4, Afshin T. Darian wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jup...@googlegroups.com.

sp...@draves.org

unread,
Sep 6, 2019, 9:41:27 AM9/6/19
to jup...@googlegroups.com
Could the jp_doodle package be updated to receive hide/show and create/destroy messages from Jupyter Lab's UI framework?

To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/7c40b10b-1708-48a4-83f1-32b4921d4bfa%40googlegroups.com.


--

Aaron Watters

unread,
Sep 6, 2019, 9:58:08 AM9/6/19
to Project Jupyter
The jp_doodle package could potentially be updated to detect these events.
Actually the jp_proxy_widget would need to be updated, since jp_doodle uses proxy wrappers
and then the jp_doodle independent JS components (which also work outside Jupyter)
would need hooks for those events somewhere...

In "classic notebook" detecting these event is not needed and I still think it would have many other robustness
advantages to isolate notebooks into separate independent frames that could just be closed "with extreme prejudice".

By the way maybe mail me privately about where these events are documented and how to detect them
from a widget context.  I haven't found the documentation.

Thanks!  -- Aaron Watters
Reply all
Reply to author
Forward
0 new messages