Auto scroll outputs

[jtpio]

Problem

The classic notebook has some logic to auto scroll outputs when they become too long:

https://github.com/jupyter/notebook/blob/a9a31c096eeffe1bff4e9164c6a0442e0e13cdb3/notebook/static/notebook/less/outputarea.less#L12

This is useful becomes it saves screen real estate and doesn't confuse users when outputs are really long and take a lot of space.

For example:

https://user-images.githubusercontent.com/591645/147687989-137c0b6a-fea4-4271-8472-8b7c53e40d0b.mp4

Proposed Solution

There is an effort to mimic that behavior in RetroLab: https://github.com/jupyterlab/retrolab/pull/288

If the result ends up being useful and working, we should consider moving it to JupyterLab so it's available by default in the notebook. And fixes parity with the classic notebook.

Additional context

This was also reported in https://github.com/berkeley-dsep-infra/datahub/issues/2992 and https://github.com/berkeley-dsep-infra/datahub/issues/2994

auto is also specified in the nbformat spec: https://nbformat.readthedocs.io/en/latest/format_description.html#code-cells

Also linking to https://github.com/jupyterlab/jupyterlab/issues/5897 as related.

[PAGWatson]

I thought I'd ask has the retrolab solution been tested with code that gives a mix of warnings from modules and output from print statements? This is because I found that a workaround for jupyterlab using the Stylus browser extension did not work in this case (mentioned at https://github.com/jupyterlab/jupyterlab/issues/5897#issuecomment-1381894481). In that case, warnings produced by modules seem to be treated as distinct from script output, so sections of script output divided by warning messages can become very long without being scrolled. So it would seem good to include this as a test case.

[jtpio]

Thanks @PAGWatson for the suggestion.

Would you be able to try with the latest Notebook 7 pre-release?

You can install it with pip install --pre notebook. Notebook 7 is based on RetroLab and has support for auto scrolled outputs.

[PAGWatson]

Thanks for responding quickly. Not right at the minute. But it works fine in Notebook 6, so if the function isn't very different to that then I guess it's probably fine.

[jtpio]

It's also possible to try the Notebook 7 pre-release more easily on Binder: https://mybinder.org/v2/gist/jtpio/d368ab89cee5123ecee60683115e15f3/master?urlpath=/tree

[PAGWatson]

I tested it and it seemed to work for my case.

Is there a way to set the default height of the scroll window? I use a large screen and would like to be able to set the scroll window so it takes up all of the available height, in order to view large figures. I see there is a grab thing that lets the window be resized with the mouse, but it would be better not to have to do this each time. In notebook 6, I used commands like

from IPython.display import display, HTML
display(HTML("<style>div.output_scroll { height: 55em; }</style>"))

at the top of my notebooks, but now this does not seem to have an effect.

[jtpio]

Thanks @PAGWatson for testing.

Is there a way to set the default height of the scroll window?

Not at the moment but maybe this could be made possible via the settings? Currently there is a threshold hardcoded here.

at the top of my notebooks, but now this does not seem to have an effect.

The class name is different in Notebook 7. Maybe using jp-mod-outputsScrolled would work.

[krassowski]

Not at the moment but maybe this could be made possible via the settings? Currently there is a threshold hardcoded here.

+1. Shall we track this in an older issue, https://github.com/jupyterlab/jupyterlab/issues/7567?

[PAGWatson]

Thanks.

I didn't manage to set the scroll window height with a command - doing e.g. display(HTML("<style>div.jp-mod-outputsScrolled { height: 100em; }</style>")) seems to increase the spacing underneath scroll windows, but not actually make the windows taller to fill the space.

[krassowski]

A relevant piece in JupyterLab code:

https://github.com/jupyterlab/jupyterlab/blob/dd38238cbf02927163466c93a51f8b738134e0b2/packages/cells/src/widget.ts#L1243-L1246

[jtpio]

Bumping to 4.1.0 as this could likely be added without introducing breaking changes.

[burnpanck]

Not sure if this is this is the right place - let me try anyway: I just upgraded to jupyter notebook 7.0, thus migrating from the "classic" experience to the "jupyterlab" based version. With that migration, my user-experience has degraded significantly. I have a notebook that hosts a number of weakly related interactive tasks that I run sporadically while exploring a problem. The output from some of these cells can sometimes be 100s of lines long. In general, that output being collapsed is great, but while a specific task is running, I want to be able to use the full screen real-estate to monitor the (long-running) task as it goes. Previously, I would un-collapse the output after it started, and then be able to just follow the output, as it is generated. Now, if I attempt to do that, after a several seconds and potentially hundreds of lines of output later, it auto-collapses again. All of a sudden, this leaves me (who followed the output in the uncollapsed state) in the middle of nowhere far away in that document. It appears, previously, it would only auto-collapse once per execution, but now it does it repeatedly. Where is the right place to discuss this issue?

[jtpio]

@burnpanck would it be possible to provide a screencast to highlight the issue you are experiencing?

Auto scrolling outputs in currently only implemented in Notebook 7 at the moment. So we could track that specific issue in the notebook repo if you would like to open one there: https://github.com/jupyter/notebook

[burnpanck]

Ping me again in a week, I have an urgent deadline that I need to make. I have downgraded to notebook 6.5 in the meanwhile so I can work.

[Ddystopia]

@burnpanck you've probably asked for a ping

[burnpanck]

@Ddystopia I'm not fully clear what you are asking me at this point. My message above asked for a couple of days time until I can make a screencast of the issue, if I remember correctly. That was more than a year ago, so I don't remember any details. I did upload that screencast a couple days later, as part of #7003 in the notebook repo, as asked by jtpio. In the meantim, I haven't been bothered by this anymore, most likely because I simply disabled the auto-scroll behaviour completely. For me the feature is not important, it could be completely removed for all I care. On the other hand, it seems that version 7 brought a number of "features" that scroll on our behalf, multiple of which turn into a major annoyance when they fail. The worst of that set is #15968, which bit me severely again today. Unfortunately, its still not clear what the exact conditions are that cause it.

[stefansimik]

As this is useful feature in general, it is good to note, that it should be at leat configurable.

If one wants the read the output at the beginning, it should not scroll him to the end again and again.

So optimal implementation should be:

1. autoscroll be default (while user does not execute any scrolling)
2. if user scrolls manually, stop autoscrolling immediately and leave the position to the user, so he can read comfortably.