Notebook occasionally scrolls to top

[nwalters512]

Description

Since updating to the lab-3.6.1 image from 2.2.9, we've had a lot of complaints from students using RTC that the notebook is (seemingly) randomly scrolling to the top. It sounds like it may be related to autosaving, but I can't tell for sure. This is understandably frustrating to students, who unexpectedly lose their place in a long notebook.

Reproduce

Unfortunately I haven't been able to reproduce this for myself yet, and from the user reports I can't tell exactly what triggers this. I'm working on getting more details, including hopefully screen recordings, from affected students. I'm filing this report in the meantime in case any maintainers might have an idea about what's happening.

Expected behavior

I would expect notebooks to retain their scroll position unless the user explicitly scrolls them.

Context

• Operating System and version: Docker is running on Amazon Linux 2; we're using a slightly-modified version of the jupyter/datascience-notebook:lab-3.6.1 image (https://github.com/PrairieLearn/PrairieLearn/pull/4685/files)
• Browser and version: Various
• JupyterLab version: 3.6.1

[welcome[bot]]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

[rob-potter]

This is happening regularly to me since turning on RTC.

[rob-potter]

Also, can provide that it's a JS error happening:

TypeError: Cannot read properties of undefined (reading 'model')

2jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2 
    at jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:858602
    at k (jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:1381838)
    at re (jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:858581)
    at m.ie [as expandParent] (jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:858867)
    at jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:823603
    at g (jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:1605476)
    at Object.c [as emit] (jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:1605136)
    at e.emit (jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:1603225)
    at set activeCellIndex [as activeCellIndex] (jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:908773)
    at de.onCellRemoved (jlab_core.3e11c5239452d671150c.js?v=3e11c5239452d671150c:2:915346)```

[drorspei]

Happening to me too. I looked at this a bit, it looks like every save or so all the cells are removed and then put back. Right after the removal of the last cell there's a call to onCellRemoved, which asks for activeCellIndex. Since there are no cells - we just removed them all - it returns -1, which is set back into activeCellIndex, so we jump all the way to the top.

The point of the code in onCellRemoved seems to be that if we remove a cell above the current active cell, the current active cell index should be lowered by one, but this clashes with some logic that removes all the cells and then puts them back.

I'm not sure what triggers the big removal, but it looks like what's changing in all the cells is the clock attribute in the id attribute of each cell.

(This is all guessing based on looking at the code a bit, and seeing the big removal and then inserts in debug mode)

[JasonWeill]

If possible, could you try using JupyterLab 4 alpha and see if this bug recurs? Some RTC fixes are only on the master (4.0.x) branch. Thanks!

[rob-potter]

I cannot, our system is used for critical-path projects so we've had to disable. Looking forward to V4, to try again.

[nevercast]

My team is also experiencing this behaviour, I'll see if we can try 4.x today and let you know if the problem is still present.

Fwiw a workaround for us was to disable Autosave Documents from the Settings menu. RTC still seems to save anyway.

[ellisonbg]

Thanks, this sounds pretty severe, we should try to fix this before the 4.0 release.

[rafaelgm]

I was also experiencing this behaviour, and it stopped when I disabled collaborative mode (autosave is on)

[TwoUnderscorez]

If possible, could you try using JupyterLab 4 alpha and see if this bug recurs? Some RTC fixes are only on the master (4.0.x) branch.

I am on 4.0.0 and it has gotten worse. i.e. it jumps up every few minutes.

[stevesimmons]

I am on 4.0.1 and the display jumps down several cells after executing a cell. So the newly active cell is way off the screen and I have to scroll back up again. Very painful when having to do this a hundred times a day. I'll downgrade to 3 if a fix doesn't appear soon.

[krassowski]

Can you provide reproducers?

One scenario in which I see an annoying scroll is pressing Tab when text in output of a cell is selected - this jumps to first cell in the notebook.

[stevesimmons]

Hi Michal @krassowski.

My guess is there are two distinct issues: (a) several different scrolling behaviours when cells' code and/or output blocks are longer than the viewport height; (b) unexpected capturing of input focus by an different cell or the "Click to add a cell." hover thing.

I encountered (b) with output text 900 lines long that had a strange faint watermark around 20 lines from the bottom that turned out to be the "Click to add a cell." hover indicator even though there were cells below it. No idea why it was appearing at the wrong time, but it seemed to be associated with grabbing the focus and forcing a surprising viewport scroll. I can't reproduce that easily though. I've also had the "Notebook occasionally scrolls to the top" from this issue's title, and haven't figured out any cause there.

Here's is how to reproduce (a):

• Create new Jupyter notebook
• Type print('\n'.join(f'a{n}' for n in range(200))) in cell 1 and print('\n'.join(f'b{n}' for n in range(200))) in cell 2, without executing either.
• Hit Shift + Enter in cell 1. I'd expect to see the tail end of cell 1's output (lines a119-a199) and that cell 2 has the focus. But the viewport stays in the same place, with output lines a0-a78 visible. The focus has moved to cell 2, which is now off the bottom of the screen so I can't see which cell has the blue highlight for next input or tell whether I am in command mode or editing cell 2. Jupyter has placed me in command mode.
• Now hit Shift + Enter in cell 2. The viewport shows output lines b121 to b199 (whereas in the previous case it was a0-a78), with a new cell 3 in edit mode visible at the bottom of the screen. I'm not sure why before I ended in command mode and now am in edit mode.
• This inconsistency in cmd vs edit mode is potentially dangerous because if JupyterLab is in edit mode, the first keystroke scrolls the viewport so the code cell is in view. But if in command mode, the keystrokes execute commands without scrolling. So I can accidentally type dd, for example (starting to type def ... for instance, and trying d again when I see nothing on the screen), and not be aware I've deleted the code cell below the bottom of the screen.
• There's also an inconsistency in arrow key behaviour depending on whether in command or edit mode. In edit mode, up and down arrows move through a cell's code area, with the viewport shifting to keep the region with the cursor in view. So you can scroll up repeatedly and always know where you are. Whereas in command mode, the up and down arrows seem to mostly scroll to keep the bottom of the output area in view, which keeps the code hidden if there is more than a screenful of output. If you then start typing, the code area doesn't scroll into view when it gets input focus, but only when the next character is typed. This is confusing and again potentially dangerous, because you can't see what mode you are in and therefore may not be aware what will happen as the result of typing the next character.
• Also if you keep hitting up, at the top, JupyterLab will stop at the bottom of the first cell's output. If that cell's output is long, you can't see you are back at the top, and more up arrows never makes its code visible.
• And sometimes, scrolling using the arrow keys has a slightly different behaviour where it brings me to somewhere in the middle of the cell's output. This seems dependent on the scroll position at the start, and maybe whether there is a cell below or now and whether it or its output is longer than one screen.

My suggestion to make these behaviours more predictable is:

1. Ensure that after hitting any of Shift/Ctrl/Alt + Enter, at least some of the now active cell's code area is visible, so the user can see the blue bar and tell if the code area has started editing or if Jupyter is still in command mode.
2. If the edit area ever becomes active while not visible, the viewport is scrolled so it is immediately made visible. No more waiting for the second keystroke (after the first which made it active).
3. Scrolling up will always end at the top of the first cell's code area. Currently it mostly stops at the bottom of the first cell's output area.
4. If a cell is longer than a screen, then scrolling up shows the top of the code area, and scrolling down shows the bottom of the output area. Ideally these would also show the bottom couple of lines of the previous cell when scrolling up and the first couple of lines of the next cell when scrolling down. That means when scrolling quickly with the arrow keys, the screen always shows some context of a neighbouring cell and the [nn] input or output cell number indicator.

[TwoUnderscorez]

@stevesimmons correct me if I'm wrong, but I don't think that what you're describing is what @nwalters512 and I are experiencing.

@JasonWeill @krassowski Here is a video of what I'm talking about and the mentioned notebook. Hopefully you can reproduce this behavior.

https://github.com/jupyterlab/jupyterlab/assets/25303006/99c1610c-56de-4594-bb5a-c0f4afbd4aef numanal.zip

Also JS console log: console-export-2023-6-3_22-29-21.txt

And here is my configuration (this is JupyterLab 4.0.1): jupyterhub.zip

[eul94458]

Can confirm this bug. It is very confusing since who knows what trigger that. It jumps in the middle of typing.

[krassowski]

This could be an interaction of tab focus problem which is getting fixed in #14115 with windowed rendering.

[krassowski]

Related to #13343.

[jakeau]

This may help I have a habit of hitting cntrl + s with RTC on with auto save on and off, it happens more often then not when I press cntr+s

[MoritzWeber0]

I can confirm that the bug does still exist in jupyterlab version 4.0.5. According to my observations, this always happens when saving. Sometimes the save doesn't seem to work properly, then all changes since the last save are lost. Also, the cursor jumps to the first cell.

[ellisonbg]

Thanks for the update, @andrii-i can you investigate?

[echuber2]

I was also experiencing this behaviour, and it stopped when I disabled collaborative mode (autosave is on)

(quoted from @rafaelgm)

This comment in particular makes me wonder if the issue is related to collaborative syncing features. It sounds like those were introduced in v3.1.0: https://github.com/jupyterlab/jupyterlab/releases/tag/v3.1.0 If I understand correctly from the comments on another issue (https://github.com/jupyterlab/jupyterlab/issues/15083), OP @nwalters512 ended up rolling back to v2.x specifically because it didn't have this scrolling issue. So perhaps someone could bisect on the v3.x releases.

[hbcarlos]

Hi everyone.

I have spent a bit of time debugging this issue, and in my opinion, we have three different issues. Here are my thoughts:

1. Comment https://github.com/jupyterlab/jupyterlab/issues/14106#issuecomment-1574273088 by @krassowski

One scenario in which I see an annoying scroll is pressing Tab when text in output of a cell is selected - this jumps to first cell in the notebook.

There's not much to say here; it is happening, is easy to reproduce, and is annoying.

2. Comment https://github.com/jupyterlab/jupyterlab/issues/14106#issuecomment-1574991785 by @stevesimmons

Create new Jupyter notebook

Type print('\n'.join(f'a{n}' for n in range(200))) in cell 1 and print('\n'.join(f'b{n}' for n in range(200))) in cell 2, without executing either.

Hit Shift + Enter in cell 1. I'd expect to see the tail end of cell 1's output (lines a119-a199) and that cell 2 has the focus. But the viewport stays in the same place, with output lines a0-a78 visible. The focus has moved to cell 2, which is now off the bottom of the screen so I can't see which cell has the blue highlight for next input or tell whether I am in command mode or editing cell 2. Jupyter has placed me in command mode.

Now hit Shift + Enter in cell 2. The viewport shows output lines b121 to b199 (whereas in the previous case it was a0-a78), with a new cell 3 in edit mode visible at the bottom of the screen. I'm not sure why before I ended in command mode and now am in edit mode.

This happens because the cursor moves to the next cell in command mode when executing a cell, so the viewport doesn't move. Instead, when running the last cell, we create a new one at the end and set the focus in the new cell in edit mode so the viewport scrolls to that cell.

To fix this, we would need to review the scroll/focus behavior of three different parts of the notebook to make them work smoothly together. When in edit mode, in command mode, and the transitions between them. In addition, we should look into the new feature that allows closing/shorting the outputs to behave similarly to the classic notebook.

3. Comment https://github.com/jupyterlab/jupyterlab/issues/14106#issuecomment-1575160899 by @TwoUnderscorez

From the resources @TwoUnderscorez shared, they use JupyterLab v4 with multiple extensions from JupyterLab v3. There is one extension in particular that could cause this issue, JupyterLab-LSP. This extension doesn't support JupyterLab v4. In addition, we can see in the video that the first jump comes after selecting a completion, and their logs show multiple LSP errors.

Nevertheless, from what I see in that video, we might have an issue with the autosave from RTC. Every time the cursor jumps to the first cell, the notebook's content gets restored to the last saved state. Looking carefully at the video, we can see that the cursor jumps back to the first cell when the user types something while the backend saves the document. Immediately after jumping, the "dirty" indicator is cleared, and the content gets restored to the last saved state.

In my opinion, we might have a race condition with the autosaving action in the backend.

[andrii-i]

I can confirm that the bug does still exist in jupyterlab version 4.0.5. According to my observations, this always happens when saving. Sometimes the save doesn't seem to work properly, then all changes since the last save are lost. Also, the cursor jumps to the first cell.

@MoritzWeber0 could you please check if you are getting this problem only with RTC on?

[MoritzWeber0]

I can confirm that the bug does still exist in jupyterlab version 4.0.5. According to my observations, this always happens when saving. Sometimes the save doesn't seem to work properly, then all changes since the last save are lost. Also, the cursor jumps to the first cell.

@MoritzWeber0 could you please check if you are getting this problem only with RTC on?

We experienced the issue after the installation of jupyter-collaboration. Before that, we never observed the problem, so I strongly assume that it is related to RTC.

[andrii-i]

Thank you @MoritzWeber0

[krassowski]

@hbcarlos there is a related issue:

• #14878

I am also experiencing a fourth scenario which is I believe is related to ToC and basically prevents scrolling past a cell at all. It is difficult to isolate but if I manage, I will post a reporducer.

[hbcarlos]

Thanks @krassowski !

[krassowski]

Here it is @hbcarlos:

Extracted out to https://github.com/jupyterlab/jupyterlab/issues/15352

1. Use Firefox or Chrome latest or stable (I reproduced across multiple versions) 2. Go to JupyterLab settings, change `Windowing mode` to `full` 3. Create a notebook with ~200 empty cells 4. Convert a cell into markdown and type `# test` creating a heading 5. In a code cell below enter `print('\n'.join(str(i) for i in range(100)))` and execute 6. Perform the motion as on the screencast:  7. See that all is good 8. Enter the markdown cell with a heading 9. Try to repeat the motion as in point (6) 10. See annoying, disorienting jump which makes me disable the `full` windowing mode: in the first attempt it took me up to the selected cell and then back down; I experienced a very distressing circumstance when I was stuck and unable to navigate past a cell by scrolling up at all but it is not as reliably reproducible  in take two it just jumped over the output of the cell preventing me from reading the lines in between 

CC @afshin

I though that ToC is to blame because it does trigger this behaviour because when you click on a cell heading it enters the cell into markdown mode (which is super annoying too and I believe someone else reported it but cannot find the issue).

[krassowski]

Also, there is another case of annoying scrolling on splitting cells:

• #14728

[krassowski]

I though that ToC is to blame because it does trigger this behaviour because when you click on a cell heading it enters the cell into markdown mode (which is super annoying too and I believe someone else reported it but cannot find the issue).

Well, these were just numerous comments not a standalone issue - I created one collating the two comments that I was able to find easily: https://github.com/jupyterlab/jupyterlab/issues/15228