And also thanks Pete for detailing how an iframe's js execution affects the rest of the page!
On Wed, Sep 4, 2019 at 12:52 AM Afshin T. Darian <[email protected]> wrote: > 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. > > On Wed, Sep 4, 2019 at 12:25 AM Pete Blois <[email protected]> wrote: > >> 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 >> <https://groups.google.com/d/msgid/jupyter/CACvpcBEddR47TCUJh1PjGZnTntvKLsbr8tX1KH2_d0%2BtYYXFjw%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/CAJ%2BUHtcy4iaxE5fJ86%3DEtP4SNodwp6wJr2z5%2B2sEUz7CG9anJg%40mail.gmail.com > <https://groups.google.com/d/msgid/jupyter/CAJ%2BUHtcy4iaxE5fJ86%3DEtP4SNodwp6wJr2z5%2B2sEUz7CG9anJg%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/CAPDWZHyo%3DVeQhGm3p%3DgoRzh5QX0vo7na8Xj%3Dgm0bmFLZCxQoqQ%40mail.gmail.com.
