Code change:
} const focused = this.getFocus(); <del> if (!focused.length) { return this.view.updateElementHeight(index, size, null); } const focus = focused[0]; if (focus <= index) { return this.view.updateElementHeight(index, size, focus); } // the `element` is in the viewport, it's very often that the height update is triggerred by user interaction (collapse, run cell) // then we should make sure that the `element`'s visual view position doesn't change. </del> <ins> const focus = focused.length ? focused[0] : null; </ins> <del> if (this.view.elementTop(index) >= this.view.getScrollTop()) { return this.view.updateElementHeight(index, size, index); </del> <ins> const anchorFocusedSetting = this.configurationService.getValue(NotebookSetting.anchorToFocusedCell); const allowScrolling = this.configurationService.getValue(NotebookSetting.scrollToRevealCell) !== 'none'; const anchorToFocusedCell = anchorFocusedSetting === 'true' || (allowScrolling && anchorFocusedSetting !== 'false'); if (focused && anchorToFocusedCell) { this.view.updateElementHeight(index, size, focus); </ins> } <del> this.view.updateElementHeight(index, size, focus); </del> <ins> this.view.updateElementHeight(index, size, null); </ins> } // override

Related discussion:
text: a notebook that has several cells, and put this code in the second to last cell the cell so that it has output, and shrink the window so that the single cell+output takes up the whole scrollable region the cell again with shift+enter :bug: the notebook ends up scrolling up, instead of showing the full output and next cell. !
The current behavior of the list view is to use the second visible element as an anchor which can cause some strange behavior. In this scenario: next cell is focused and revealed, making that cell the anchor as second visible, since the executing cell takes up the rest of the visible region. output is removed, moving more elements into view from above is and the initial anchor is no longer the second element, so it is scrolled out of view I'll try to play around with some options, but my initial thought would be to use the executing cell as the anchor. The output could expand and push the next cell out of view, but typing in that cell will bring it back into view. cc
I wanted to see the behavior locally. I really can't seem to repro this, my notebook stays pretty stable as the cell shrinks and grows. What am I missing?
I think I found it. I believe you have disabled, am I correct? Can you reproduce this when flipping that setting back to the default value of ?
It repro's with or without - you just need to scroll down enough so that the resized cell is only partially visible. The strange behavior is due to the notebook cell list setting different anchors depending on whether the element top is above the render top.
As I looked into the remaining open issue and PR , I was trying to grasp what the issue really is, what has been actually fixed and what's left to fix. Then, I pulled latest and ran out of sources and this is even worse than my last recording. Everything jumps around even when the cell is fully in view: Did just break this even more? I suggest reverting , pausing, simplifying the problem, narrowing in on a solution and consider fixing it in debt week so as to not cause regressions during this endgame week. cc
thanks for the testing, the two recordings you posted above were using different execution commands so I want to ensure we refer to the same behavior: in , it's re-executing the active cell (ctrl+enter), which should always stay visually stable.