feature-request: click below/above scrollbar handle moves one screen height

[jmeier]

When viewing the "release notes" on VSCode, I can click above/below the scrollbar handle to scroll up/down one screen height (kind of "relative scroll"). In a regular file to be edited in VSCode, a click above/below the scrollbar handle jumps to the (absolute) position. The latter does also not match with the default Windows behaviour.
This behaviour is also cumbersome in very large files: Even clicking on one of the markers shown in the scrollbar will send you somewhere near, if lucky. After that you have to use the scrollwheel or the scrollbars arrow buttons (both slow).
Therefore this feature-request: Please add a setting to enable a "page wise" scroll when clicking above/below the scrollbar handle. The same applied for the Minimap. But I'll suggest to create two seperate settings.

[maciejw]

lets make this configurable shall we? :) this absolute scroll with click by default is the most annoying thing in vscode. when I have node_modules expanded in explorer, its impossible to go only one page up, every windows scrollbar works like this: when I click below or above I get page down or up. in windows we can shift+click is scroll to absolute position. lets make it platform compatible first, and configurable if its not a problem second.

[nissimk]

There are several non-standard scrollbar behaviors here:

1. The jump to click position rather than page-up/down when clicking the scrollbar above/below the handle. System scrollbars do page up/down in Windows and mac.
2. The handle disappears when the mouse exits the element the scrollbar is attached to. This causes me not to know where in the long file I am looking at unless my mouse is hovering over the element with the text.
3. The up / down arrows also disappear when the element loses focus.
4. The scrollbar responds to right click (not the handle, just right clicking above / below the handle does the same thing as left clicking).

Would you accept a PR to change this or to change it based on a user preference setting?
If I could change 1, 2 and 4, would you prefer those to be under separate settings or all under one setting?

[gonhidi]

There are several non-standard scrollbar behaviors here:

1. The jump to click position rather than page-up/down when clicking the scrollbar above/below the handle. System scrollbars do page up/down in Windows and mac.

On macOS, the system behaviour can be GUI-configured per user to either “Jump to the next page” or “Jump to the spot that's clicked” via the “Click in the scroll bar to” setting in the General section of System Preferences; the setting is reflected in the AppleScrollerPagingBehavior key within the NSGlobalDomain / Apple Global Domain of the user defaults. Respecting this choice would be to me a good first step for this platform; adding a user preference to either follow it or to override it one behaviour or other would be a further enhancement. For completeness note that, whichever option of the two is active, it can be momentarily swapped by holding the Option/Alt key while clicking (similarly to the shift+click Windows possibility described above in
#43564 (comment)); implementing this behaviour to further mimic native capabilities would be a nice addition somewhat related to this feature request.

If I could change 1, 2 and 4, would you prefer those to be under separate settings or all under one setting?

The behaviours you describe look orthogonal to me, so whichever are made to be configurable would seem best set independently.

[SetTrend]

@nissimk 👍

See this issue for corresponding discussion. Please up-vote.

[jdtechsol]

@nissimk 👍

See this issue for corresponding discussion. Please up-vote.
@SetTrend
How does that issue correspond to the one you linked to? The definition of "corresponding" (correspond) is "have a close similarity; match or agree almost exactly". The most they have in common is that they are both feature requests and both reside within the same application. Please refrain from using one issue/feature request to try and increase the traction of another.

[jdtechsol]

Is this issue / feature request getting any traction? I HATE the fact that when I try to navigate the file list using the scrollbar by clicking above or below the scrollbar handle, that it jumps to the absolute position.

[SetTrend]

@jdtechsol : Oops, sorry for referencing the wrong issue. I updated the hyperlink now.

[antoniomolram]

I am also interested in this feature! on big screens some times is better to move the text to a place where you want to see.

[RedDragonWebDesign]

I am also interested in this feature. It is bugging me enough that I googled how to change it, and found this feature request. +1, fully support. Please add!

[betterbuiltcows]

The absolute scroll position might be handy on occasion, like I wouldn't mind being able to press Ctrl+Click to do it. I could see where some people might even prefer it as a default.

But for over 30 years, scrollbars have been paging when you click in the gutter, and that is a lot of user experience to ignore.

A good example...
This text box I'm typing in right now pages when I click above or below the scroll button. If I want to get to a particular spot fast I can grab the button and pull it, or click in the gutter and hold it down. If I want to nibble my way up or down I can use the arrows. The button-to-gutter ratio matches the visible-to-total text ratio. That's just how scrollbars work, since Smalltalk-80 at least, and possibly earlier. It's a thing of beauty.

Please add a configuration option to restore the de facto standard of scrolling one page length.

[leodamasio]

+1 here. this not standard scrollbar behaviour is not productive and makes navigation really complicated if you do not use a mouse with a scroll wheel.

[saclarky]

+1

[SetTrend]

Seems an inherent issue with open source software ... Everyone wants it but no-one wants to fix it for free. I don't want to take the task, either. So ... anyone else..?

[AE1020]

Seems an inherent issue with open source software ... Everyone wants it but no-one wants to fix it for free. I don't want to take the task, either. So ... anyone else..? @SetTrend

I wrote it, and submitted it in August, but it still hasn't been accepted, despite being optional and off by default:

#104923

If someone wants to go over to the PR and ping it to show support, maybe it would help!

[SetTrend]

Great work!