%%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
On Tue, Sep 3, 2019 at 3:50 PM William Stein <[email protected]> wrote:
> On Tue, Sep 3, 2019 at 12:08 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
>
>
> 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)
>
> --
> 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
> [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/CACLE5GCJC%3DgjOe9f%3Dz5ah7cNTf%3DX8SNuX%3Dy8KDEAqGGMwPLcZA%40mail.gmail.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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jupyter/CAMmMR%2BVYEjUDbTGOVbqcL_-9JfsodCmkpDSEn6zSw8hae%2Btc6w%40mail.gmail.com.
