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 <https://www.chromium.org/developers/design-documents/oop-iframes>
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. On Tue, Sep 3, 2019 at 1:12 PM 'Aaron Watters' via Project Jupyter < [email protected]> wrote: > 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 > > On Tuesday, September 3, 2019 at 3:19:31 PM UTC-4, Afshin T. Darian wrote: >> >> 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 >> >> On Tue, Sep 3, 2019 at 8:17 PM Jason Grout <[email protected]> wrote: >> >>> 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 >>> >>> >>> On Tue, Sep 3, 2019 at 12:09 PM 'Aaron Watters' via Project Jupyter < >>> [email protected]> 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 >>>> >>>> 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 >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jupyter/f625f4c4-1ea5-48a6-853c-89afd09ac2d6%40googlegroups.com >>>> <https://groups.google.com/d/msgid/jupyter/f625f4c4-1ea5-48a6-853c-89afd09ac2d6%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jupyter/CAPDWZHz%3DQOh_E_RwuobM9Ye3zGNQ2QMi3UmYM1HD3PW_REKZfQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/jupyter/CAPDWZHz%3DQOh_E_RwuobM9Ye3zGNQ2QMi3UmYM1HD3PW_REKZfQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jupyter/39b73eb6-0b13-480b-b643-a53edd334118%40googlegroups.com > <https://groups.google.com/d/msgid/jupyter/39b73eb6-0b13-480b-b643-a53edd334118%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CACvpcBEddR47TCUJh1PjGZnTntvKLsbr8tX1KH2_d0%2BtYYXFjw%40mail.gmail.com.
