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 <ja...@jasongrout.org > <javascript:>> 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 < >> jup...@googlegroups.com <javascript:>> 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 jup...@googlegroups.com <javascript:>. >>> 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 jup...@googlegroups.com <javascript:>. >> 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 jupyter+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/39b73eb6-0b13-480b-b643-a53edd334118%40googlegroups.com.
