Change:
Steps to Reproduce: notebook a cell in the notebook outline Actual Behavior: Cell selected ends up ~middle of the window/notebook + doesn't have any selection on the cell that was picked so it's hard to identify where it is. Expected Behavior: Cell to be at the top + selected mode indicator
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.592 --- <!-- score: 0.545 --- <!-- score: 0.529 --- <!-- score: 0.523 --- <!-- score: 0.506 --<!-- potentialduplicatescomment --
Couldn't find the original issue and thought that I forgot to file it but turns out it was closed. Received customer feedback (4/4) in interviews that they expected selecting a cell in the table of contents would bring the cell to the top and currently they have a hard time identifying where the cell is. (I have also struggled with this same issue, when I click on a cell in the outline I find my eyes scattering to figure out where the cell actually is) This also deviates from Jupyter behavior which is why it could be hard to adapt to
not sure if we want a different experience in notebook.
Some thoughts here: Markdown is typically used in a notebook to separate logical blocks of cells. It would seem to make sense to be able to see as much of that logical set of cells as possible when navigating to it. With a regular text editor seeing code context around the navigation point can make more sense. Jupyter's behavior is to scroll markdown to the top. It's unclear what would be appropriate if Show Code Cells for outline view is on and the user clicks on a piece of code in the outline view. Scrolling to the middle or top of the screen doesn't necessarily seem right. What about scrolling such that the cell that contains the piece of code is set at the top of the workbench window and the selected piece of code is highlighted temporarily? Of course we'd have to deal with large cells where the selected line appears below the bottom of the editor window. In that case, scrolling the code to the middle of the screen makes more sense (now you're more in the editor mode in this situation). Most notebooks do not contain large cells; however.
I'd also point out that the current behavior is quite buggy, which doesn't help. If you open this notebook and use breadcrumbs or the outline view to navigate the markdown, you'll easily run across them. I.e. sometimes the selected markdown is up off the top of the viewport (possibly because a cell is large below it), you'll also sometimes see headers getting rendered and then erased.
This is still bothersome. And I also noticed that the scroll position for notebooks when clicking on one of the outline items is further down vertically than even regular code: <img width="761" alt="image" src="https://user-"<img width="761" alt="image" src="https://user-"I still think that when any item is clicked in a notebook outline it should be scrolled to the top as it's not likely that prior code/cells will be interesting to see in context. But barring that, the scroll position should at least be identical to that of pure code. Jupyter, Google Colab and probably others scroll the selected item to the top of the window.
I know I filed this issue but just wanted to add this is actually why I don't use the TOC in the notebook. It doesn't actually help me find where I am in the notebook, my eyes end up scattering all over the page to find where I am anyway
From all feedbacks above, there seem to be three issues: Hard to find the focused/selected cell. We have the focus indicator on the gutter since the original issue was created. Cell top is revealed to the viewport center. Instead we should try to reveal the middle of the cell to the viewport center. I have pushed a fix for it, see below screen recording Lastly, if we should always reveal focused/selected cell into the top of the viewport. The reasoning behind this can be that notebook cells are richer and the focused cell is less noticeable compared to active line in a text editor (especially when there are outputs in the view). It's not just TOC as you get the same behavior when clicking on cells on problems panel, debug view, etc. It makes sense to me but I'd love to wait a bit for more feedback before making this significant change. https://user-
Thanks for the update! I can't tell in your recording if the gutter indicator is...passive or active? (I'm probably labeling that wrong) What I call passive (gray): ! vs. What I call active (blue): ! I was really hoping to see "active" since there is so much more gray on the canvas and it is so delicate I don't end up seeing the gutter indicator, the blue has enough contrast to where I can see it clearly and quickly
passive colors are meant to the "passive" but you can always update the color to something stands out by tweaking
Oh perfect, thanks! I'll go ahead and update that
Please note that Google Colab also scrolls to the top. Note that I'm not sure why the "Setup" navigation at the beginning of this animation does NOT scroll to the top. I couldn't repro the behavior. May just be some bug. !
The behavior across our different editor types should be the same.
IMHO, perusing notebooks is a different workflow than perusing code. Code does not have markdown headers that signify the beginning of a new "investigation" or "section". There's much less need to be able to see prior context when perusing a notebook than there is with code.
Verification steps - clicking a cell in the outline that is out of the view should reveal that cell at the top 5th of the viewport. If already in the viewport, it just focuses the cell. Same behavior as the text editor outline.
! See gif. When I select feature request missing labels I would expect it to scroll so the entire cell is in view. Only a very small sliver of the header is showing I wouldn't call that in the viewport. You can see when I scroll away it does what is expected.
Thanks. I think I just want to compare elementBottom to wrapperBottom here: but I will fix in June since that will affect many reveal scenarios.
Maybe it's not a big deal

Discussion:
if (ignoreIfInsideViewport && elementTop >= scrollTop <del> && elementTop < wrapperBottom) { </del> <ins> && elementBottom < wrapperBottom) { </ins> if (revealPosition === CellRevealPosition.Center && elementBottom > wrapperBottom