Erratic Scroll Jump just when scrolling

[burnpanck]

Description

Recently, in the standalone Jupyter notebook mode, I started to occasionally observe a scroll glitch.

Scroll.glitch.mov

Reproduce

It is unfortunately unclear what exactly is required to trigger this issue initially.

1. My notebook is relatively long.
2. The cell re-writes some text (using display.clear_output(wait=True), which ultimately fails with an exception.
3. After the cell stopped executing, start to scroll upwards, from the cell output towards the cell content
4. At some point roughly when the top of the just executed cell becomes visible, the view suddenly jumps to align the top of the next cell with window
5. You can do this several times
6. If you bring another browser window into foreground and then go back, the glitch is sometimes gone.

Expected behavior

Normal scroll.

Context

• Operating System and version: macOS 14.4
• Browser and version: Chrome 122.0.6261.112
• JupyterLab version: 7.1.1
• Windowing mode: defer

Related issues:

• Switch off the new overreactive interface jump to end of output behaviour? #14878 -> suggests windowing mode full -> layout is completely broken in this mode for me (cells expand out of the right of the window due to long lines)
• Erratic scroll jumps when performing actions in notebook #15693 -> appears to be connected with notebook "actions". no "action" is triggering the glitch here, just scrolling on it's own.

[JasonWeill]

Do you have JupyterLab installed? If so, which version are you using, and do you see this same behavior in Lab?

#14106 concerns the scroll bar jumping to the top, but that's not what you're reporting here.

[burnpanck]

I was able to reproduce the same behaviour in JupyterLab, basically on first try on a notebook cell that had shown the same behaviour right before in the classical notebook interface.

[burnpanck]

A few more random observations:

• There is no message on the developer console.
• It seems to be associated with a specific cell in the notebook - scrolling over other cells does not trigger it.
• Not all executions of that particular cell seem to cause that behaviour.
• It appears to me that it happens more often when that cell executes for a long time, repeatedly clearing the cell output before failing with an exception
• The cell input is about two screens high, and so is the output. In this particular case, there is maybe just one more screen of cells above, but not much more (it's a different notebook than the one from the screencast above, though similar cell).
• Once that cell entered that "glitching mode", it's pretty persistent (for a while). You can sometimes scroll over it (by scrolling very fast), but even afterwards, scrolling down and up again still triggers it.
• Re-executing the cell seems to recover out of the "glitching mode".
• Re-loading the jupyter lab interface (i.e. browser reload) also recovers out of the "glitching mode"

[burnpanck]

Is there anything I can do to help resolve or at least mitigate this issue. It still happens regularly to me, and it is extremely disorienting and annoying, to the point that I am putting back all work involving a jupyter notebook.

[krassowski]

@burnpanck in fact, yes. Can you test JupyterLab 4.2.0a2 and see if this still happens?

[burnpanck]

Unfortunately, the issue seems to persist. This was with jupyterlab==4.2.0a2 and notebook==7.1.1, which, officially, are incompatible. Obviously, I did a restart of the server followed by a hard reload of the browser window of the affected notebook.

[burnpanck]

I just found the older bug report #15795, which, from the description, matches the behaviour I see.

[krassowski]

This was with jupyterlab==4.2.0a2 and notebook==7.1.1, which, officially, are incompatible

I am confused, did you see the behaviour in Notebook or in JupyterLab interface?

I just found the older bug report #15795, which, from the description, matches the behaviour I see.

The author of #15795 says that they cannot reproduce this when switching to full windowing mode. In JupyterLab 4.2.0b0 it is on by default but you can also change it in Settings Editor → Notebook → Windowing mode. Do you still see this in 4.2.0beta0?

Also, are you using a trackpad or a mouse?

[burnpanck]

I mostly use the notebook interface, but I previously was able to reproduce it in juptyterlab as-well. I was under the assumption that it is therefore a manifestation of a bug in the shared code-base, and thus observation in either interface counts as confirmation. This may have been a wrong assumption though. The comment you referred to above was in fact an observation from the notebook interface. I will try to verify from the jupyterlab interface again later today.

I observed the described behaviour both when scrolling using two-finger scroll on the MacBook Pro trackpad, as-well as when attempting to scroll by clicking and dragging the hidden scroll bar (which appears when initiating a scroll via trackpad), click-drag still done using that same trackpad. This is within Google Chrome.

[tillahoffmann]

I observe similar behavior in Jupyter Lab with Safari on macOS 14.4. See below for installed versions.

$ python --version
Python 3.10.9
$ pip freeze | grep jupyter
jupyter==1.0.0
jupyter-console==6.6.3
jupyter-events==0.9.1
jupyter-lsp==2.2.4
jupyter_client==8.6.1
jupyter_core==5.7.2
jupyter_server==2.13.0
jupyter_server_terminals==0.5.3
jupyterlab==4.1.4
jupyterlab_pygments==0.3.0
jupyterlab_server==2.25.4
jupyterlab_widgets==3.0.10

I'll update Jupyter Lab to the most recent version to double check it's not resolved in a recent release.

[burnpanck]

I just reproduced it again in JupyterLab 4.2.0b1 (i.e. lab interface), after observing it in Jupyter Notebook 7.2.0a0. "windowing mode" was set to defer. I'm now switching to none, in the hope of an improvement of the situation.

[burnpanck]

Does that "windowing mode" only affect the lab interface, or also the classic notebook interface? In classic notebook, same behaviour with none even after a hard reload.

[burnpanck]

Also reproduced with jupyter lab in none mode.

[burnpanck]

Same with full.

[burnpanck]

I see that @jtpio did merge two changes on the release candidate branch (in 7.2.0b1, the one that I tested last) that may potentially interact with this (i.e. if I read the description correctly, basically inactivating the windowing mode selector). If windowing-mode full was indeed a workaround for this issue before as suggested by @krassowski in #15693, then that commit actually worsened the situation here.

Unfortunately, this issue is extremely frustrating, because it completely prevents the user from navigating a notebook, with the only remedy to re-load the notebook from disk or re-executing the offending cell (if you can still reach there). It is happening erratically with no clear pattern visible except that it seems to be triggered by a cell output - though both "instant" cells and long-running ones.

[jtpio]

If windowing-mode full was indeed a workaround for this issue

Was it? Previously it was more the opposite, with the full windowing mode causing more scrolling issues than defer (#13343).

Otherwise yes Notebook currently still has issues with the full windowing mode, which hopefully will be fixed at some point (jupyter/notebook#7318).

So jupyter/notebook#7335 forces to defer for now, but this should not change the windowing mode in JupyterLab anymore like it used to when changing the settings.

[burnpanck]

I never confirmed full being a workaround. It was suggested by @krassowski that #15288 fixed #14878 and potentially #15693 which may be related (at least they are scrolling-related issues), but the fix was only done for full. When I first opened this issue, I did not try full for an extended period of time exactly because of jupyter/notebook#7318, which is even worse than this issue here and at that time I was under a lot of pressure from my paid work. So I did not exhaustively test windowing modes before 7.2.0b1. But I can roll back to 7.2.0b0 if you think it's reasonable, switch to full and see if I still observe the issue.

[burnpanck]

So jupyter/notebook#7335 forces to defer for now, but this should not change the windowing mode in JupyterLab anymore like it used to when changing the settings.

Maybe I still don't understand well enough how the notebook interface in the lab interface relates to the classic notebook interface. I do prefer the latter, so I only use the lab interface to help debug this issue. My testing on 7.2.0b1 basically involved using the "Notebook settings" section in the lab settings interface to (attempt to) change the windowing mode, then working with a notebook until the issue next appears - both in the classic interface and the lab interface. If I understand correctly, with 7.2.0b1, this did in fact effectively change the windowing mode for the lab interface but not in the classic notebook interface? Since I observed the scrolling issue with all three settings in both interfaces, it appears that it is unlikely that full fixes anything in this regard.

[jtpio]

with 7.2.0b1, this did in fact effectively change the windowing mode for the lab interface but not in the classic notebook interface?

Correct. But we should indeed fix Notebook 7 to allow for using the full windowing mode, even though there are still some issues with it in Notebook 7.

@burnpanck would you be able to try the version of Notebook built by the check_release job in this PR? jupyter/notebook#7321. You can download the artifact from https://github.com/jupyter/notebook/actions/runs/8816599093?pr=7321, extract the archive, and then install the wheel. This PR makes full the default in Notebook 7, like in JupyterLab.

[burnpanck]

It appears that issue is still present in that 7.2.0b2 from the check_release CI artefact. I just encountered another case of scroll jump. Here is what I observed:

• In the classic notebook interface, I executed a cell which raised an exception; when attempting to scroll to the top of this fairly large cell, my viewport consistently jumps back to the following cell (you can still get to the top of the notebook by dragging the scroll-bar).
• A "normal" reload (i.e. no cache flush or similar) of the page breaks that behaviour. Now, scrolling over that exception output works normally.
• Re-executing the failing cell triggers the behaviour again.
• After a hard-reload (context menu option in Chrome when developer tools are open), some executions of the cell don't seem to trigger the issue; but ultimately, it appeared again.

I have made a gist from that particular notebook: https://gist.github.com/burnpanck/490837926c841c00122366137b21dc57
You will find two cells towards the end of the notebook which raise exceptions. Executing those cells a few times, then trying to scroll up does trigger the issue pretty reliably for me. The gist also includes a Google Chrome Developer Tools Performance Profiler trace of ~ 4 seconds length, containing a single such scroll jump event. Let me know if that helps.

[krassowski]

@burnpanck Would you be able to create a reproducer which does not require installing packages? If the issue is around cell size + timing + exception traceback display, then it should be possible to create a set of cells with just sleep() calls, a number of new lines, and a raise Exception() calls.

[burnpanck]

Unfortunately, the issue seems to appear even with cells that execute rather quickly, so I the timing could be a matter of milliseconds... I have no clue how I would transform that failing example above (or any other for that matter) into a series of sleep calls which still trigger the issue. I will try, but it may take a few days, we're in the middle of a release.