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 <jupy...@darian.af> 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 <p...@blois.us> 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 <
>> jupyter@googlegroups.com> 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 <ja...@jasongrout.org>
>>>> 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> 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.
>>>>>> 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.
>>>>> 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
>>> <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 jupyter+unsubscr...@googlegroups.com.
>> 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 jupyter+unsubscr...@googlegroups.com.
> 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 jupyter+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jupyter/CAPDWZHyo%3DVeQhGm3p%3DgoRzh5QX0vo7na8Xj%3Dgm0bmFLZCxQoqQ%40mail.gmail.com.
