Change:
} }; <del> function scrollWillGoToParent(event: WheelEvent) { </del> <ins> let scrollTimeout: any /* NodeJS.Timeout */ | undefined; let scrolledElement: Element | undefined; function flagRecentlyScrolled(node: Element) { scrolledElement = node; node.setAttribute('recentlyScrolled', 'true'); clearTimeout(scrollTimeout); scrollTimeout = setTimeout(() => { scrolledElement?.removeAttribute('recentlyScrolled'); }, 300); } function eventTargetShouldHandleScroll(event: WheelEvent) { </ins> for (let node = event.target as Node | null; node; node = node.parentNode) { if (!(node instanceof Element) || node.id === 'container' || node.classList.contains('cell_container') || node.classList.contains('markup') || node.classList.contains('output_container')) { return false; } <ins> if (node.hasAttribute('recentlyScrolled') && scrolledElement === node) { flagRecentlyScrolled(node); return true; } </ins> // scroll up if (event.deltaY < 0 && node.scrollTop > 0) { // there is still some content to scroll <ins> flagRecentlyScrolled(node); </ins> return true; }

Discussion:
Testing Have the following code in an notebook cell. Run the code Scroll the output. Notice as your scroll reaches the top you can continue scrolling and it will scroll the whole notebook file. This is unexpected and I think no other widget in VS Code behaves this way. I suggest instead the following strategy when scrolling: If a mouse is in the Cell then scrolling it will only scroll that cell. You can not scroll the large notebook while the mouse is in the cell. Same way you can not scroll the Cell with the mouse unless the mouse is in the cell IMHO this is what makes the current experience feel weird.
We don't often have nested scrollable elements in VS Code workbench and also this is how browsers handle nested scrolling. Current behavior feels right to me. I can see the value of scrolling only when the focus is inside/on the output, there is a catch with that though, users need to move cursor to outside of the cell output to scroll the notebook, and the hit area for that is very narrow most of the time.
Thanks for providing more info. But what other UI element scrolls like the notebook does right now - so that you can scroll the element until it hits the end, and then if you continue scrolling that the outer element starts scrolling? This really felt unnatural to me, but I might have missed this pattern in other parts of the workbench. Or what do other Notebooks products do in this case?
the peek view actually behaves this way. That's the only other nested scrollable element that I know of.
Thanks! If I am the only user that it complaining feel free to close this one as designed :)
I tried using notebook in VSCode again last week, and came to GitHub to open this exact issue. I feel this scroll is extremely unintuitive. Here's an example. A cell is outputting more lines than , so we're currently viewing it's last line. I want to scroll to top. I speed scroll up, but this reaches the top and keeps scrolling the notebook, so now I'm all the way up. I have to scroll back down to my cell. If I go fast, I might miss it. If I go slowly, some other cell's output might catch my scroll and scroll that to bottom, before the notebook scrolls again. Same happens to my cell.

I need to be frustratingly precise to scroll this output to the top. Here's a recording to illustrate (I hope you can see it, recorded on MacOS, encoded as AV1; can add YT link if not viewable here): It took me 15 seconds to manage to get that top. And I knew exactly what I wanted to achieve, for the sake of the video. Now here's the same experience in native Jupyter Notebook (exact same notebook and cell). First, I can easily toggle the output scrolling. If untoggled, the output scrolls natively with the notebook, and since it expands downwards, without the notebook jumping, I can immediately see the top, which is right next to the cell. Then I toggle the scrolling again, to illustrate the behaviour compared to VSCode. I initiate scrolling inside the output area, and so only that area is scrolled. No matter the speed, or direction, I can easily reach the top or bottom as many times as I need, without losing context of my notebook. If I do want to scroll the notebook, I need to scroll outside the output area. This is easy because the cell does not take the whole width. This is in relation to what said above: Yes, but the cell does not need to take the complete visible width. In native notebook, cell's width is limited, and there's still plenty of space for code. But even if the cell does take the entire width, the user can initiate the scrolling outside the output area, i.e. over a cell. In this case, it scrolls the notebook, and never the outputs. The outputs do not steal the scrolling from the notebook, like it happens in VSCode. So: scroll initiated on cell or outside the cells area -scrolls notebook only, never output scroll initated in scrollable output area -scrolls only that output area, never the notebook
should we reopen this? What do you think?
sure, that's a reasonable request. It would be inconsistent with how the peek view scroll works, but the possibility for many scrollable regions makes these cases more noticeable in notebooks. - one thing that might help - you can toggle output scrollability per output in vscode as well with , by default
I have the same issue.

The usability of the scrollable element suffers greatly due to the current crazy behavior - when the scrolling inertia reaches the end of the scrollable output and scrolls the whole notebook! If different users want different behavior, this can be an option in the settings, e.g.: current behavior behavior like in the native Jupyter Notebook (in the video above), i.e. the notebook never scrolls if the pointer is inside the scrollable element there may be a 3rd option: the scroll that reaches the end of scrollable area doesn't scroll the notebook, but the subsequent scrolls in the same direction (even if the mouse pointer is inside the scrollable area) - scroll the notebook
for verification, please check with a mouse wheel and scrolling with a trackpad, since they behave quite differently. Hitting the boundary of the inner scrollable region will prevent further scrolling for that same scroll action. After a short pause you should then be able to scroll the outer region since the inner region can't be scrolled any further. (similar behavior to a browser)
Verified on trackpad. Still have to verify with a mouse wheel.
verified on mouse! there was a pause/delay, but wonder if there should be a larger delay - I find that sometimes I spam scroll and it moved up a little quicker than I anticipated. if it matches browser tho, should be all good ~
hello , thank you a lot for the work on this issue! I hate to say this, but I think it's not solved: It looks like only a certain "scroll length" is ignored, and the rest of the scroll inertia is still applied. Here I do: one fast scroll (as you see, the notebook moves) then I scroll back down then one fast (a bit slower) scroll (the notebook moves) Only if the scroll isn't fast enough the "scroll length" will be small enough to be completely ignored. <br /Here I do: one long scroll - all the way until the end of the video: <br /The behavior in the native jupyter notebook is certainly different. Here I do: one fast scroll - different than in VSCode (the notebook doesn't move) one long scroll- different than in VSCode (the notebook doesn't move) one after-scroll (the notebook moves as expected) Could this issue please be re-opened?
which version of vscode was this on?

Version: 1.88.0 (Universal) Commit: Date: 2024-04-03T13:28:18.899Z (1 day ago) Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Darwin arm64 23.3.0
ok, yeah. looks like I broke the behavior with a related bugfix
Version: 1.89.0 - still isn't completely fixed: If I scroll hard enough, the notebook scrolls.