Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scrollbar too slow to show, grab #3454

Closed
heaths opened this issue Nov 6, 2019 · 11 comments · Fixed by #14047
Closed

Scrollbar too slow to show, grab #3454

heaths opened this issue Nov 6, 2019 · 11 comments · Fixed by #14047
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) good first issue This is a fix that might be easier for someone to do as a first contribution Help Wanted We encourage anyone to jump in on these. Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone

Comments

@heaths
Copy link
Member

heaths commented Nov 6, 2019

Environment

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.18363.0 Microsoft Windows NT 10.0.18363.0

Terminal version: 0.6.2951.0

Problem (no steps)

Even with the default visibility of the scrollbar, it's too small to grab and the full size doesn't show fast enough - it's a productivity drain. Using my scroll wheel on my mouse is great when I have to scroll a few pages, but when I need to go back further in the output buffer I want to grab the scroll bar. Now, I have to wait a second or so before I can. Please give us a setting to always show it, like "hidden", "visible", or (new) "always" (or something like that). I want it always fully visible - at full size - ready to use like conhost.

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Nov 6, 2019
@zadjii-msft
Copy link
Member

zadjii-msft commented Nov 6, 2019

You know, I really want the scrollbar to have these options too. Actually getting the XAML scrollbar to behave that way was a lot tricker than we had originally hoped, but maybe we can still get this in.

To clarify: this proposal is to have the scrollbar have three visibility states:

scrollbarState Description
"always" The scrollbar is always visible, like conhost.exe
"visible" (default) The scrollbar "reveals" on mouseover, as it does currently.
"hidden" The scrollbar is always hidden

Right now we support "visible" and "hidden", but we want an "always" state added.

If someone with more XAML experience would be willing to help us with this one, that'd be much appreciated.

<technical details>

From a internal mail thread back in April:

Mike is partially correct. On windows versions where conscious scroll bars are available (RS3+) the TouchIndicator state is nearly equivalent to the mouse indicator state. The only difference is that when conscious scroll bars are disabled by windows system setting, scrollbars in the touch indicator state are not hit test visible, meaning you cannot drag the thumb to scroll. On older versions of the OS MouseIndicator and TouchIndicator behave quite differently, essentially how mike described it.

Unfortunately as far as I am aware, there is no easy way to force the scroll bar to remain in its expanded state for your app, if that is desired I think your only option would be to retemplate your scrollbar control and edit the VisualStates for the ConsciousStates group so that the Collapsed and CollapsedWithoutAnimation are eqivalent to the expanded states and to remove the Expanded to Collapsed transition.

So we'll need to basically make a custom scrollbar template for the TermControl scrollbars. Not impossible, but certainly not easy.

As another fun challenge, the TerminalControl project doesn't currently have any XAML files or resources, so we'd need to add those, or find a way to define them in TerminalApp and have them used by TermControl.


EDIT: July 2020 update

This will be substantially easier to do nowadays. As of late 2019, the TerminalControl project has XAML resources as well, so adding the appropriate XAML files shouldn't be that big of a pain.

@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Nov 6, 2019
@zadjii-msft zadjii-msft added Area-Settings Issues related to settings and customizability, for console or terminal Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) Help Wanted We encourage anyone to jump in on these. Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal. labels Nov 6, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Nov 6, 2019
@DHowett-MSFT DHowett-MSFT removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Nov 7, 2019
@randomascii
Copy link

Can you push back on the XAML team or the OS team or somebody to make this behavior more accessible? I want always-visible scrollbars in the terminal, but I also want them in all programs that I use.

Always visible-scrollbars are much faster to grab and use (as the original bug filter said), and they also give a visual indication of how big your document is, and where you are in it. And, I can't see any advantages to having them disappear - the disappearing doesn't give you more window space for text.

@kg
Copy link

kg commented Mar 17, 2020

The current XAML/WPF/whatever scrollbar thumb is also just way too small. My vision is good so I can see it but it's low-contrast and only about 2 pixels wide on both of my monitors. If it's going to collapse it should not be doing it in such a low-accessibility way.

@ZhaoMJ
Copy link
Contributor

ZhaoMJ commented Mar 17, 2020

@randomascii If you want to make the scrollbar always visible for all programs, there is a setting under Ease of Access->Display, namely "Automatically hide scroll bars in Windows". You can just search and disable it.

@zadjii-msft
Copy link
Member

@randomascii Probably the best place to push for that would be filing an issue over in the WinUI repo.

We'd definitely be willing to back up a request, though knowing what I know about their resourcing currently, it'd almost certainly be easier for us to add a custom templated scrollbar than for them to add the behavior we're looking for to the platform. This is at least in the near term - sure, the platform fix would be better for the ecosystem, but if you want a fix now for the terminal, doing it here is going to get you the fastest results.

Fortunately, quite a bit has changed since November, and we've got quite a bit more XAML in our project than we used to. So I actually don't think that the changes that were outlined above would be terribly difficult to implement. I'd think the hardest part would be supporting both the current behavior and the requested behavior in one control class. It would probably be really easy to just have two control classes, and just instantiate one or the other. In fact, if we were able to get it figured out here, we'd probably be able to ingest the changes upstream in WinUI.

@randomascii
Copy link

If you want to make the scrollbar always visible for all programs

Done

@WaseemRakab

This comment has been minimized.

@DHowett

This comment has been minimized.

@AltitudeApps
Copy link

@randomascii If you want to make the scrollbar always visible for all programs, there is a setting under Ease of Access->Display, namely "Automatically hide scroll bars in Windows". You can just search and disable it.

This works, but it seems to only take effect for new instances of Windows Terminal.

I think that existing instances of Windows Terminal should immediately respond when the value of this system-wide setting changes. And perhaps the title of this issue should be adjusted to reflect how the discussion has evolved?

I would really like to be able to configure this per-profile, as per the idea above. But I've found that only "visible" and "hidden" are valid values. I'd like the ability to specify "always" for certain profiles, regardless of the value of the platform wide "Automatically hide scroll bars in Windows" setting in Ease of Access.

@leogott
Copy link

leogott commented Apr 22, 2021

@randomascii If you want to make the scrollbar always visible for all programs, there is a setting under Ease of Access->Display, namely "Automatically hide scroll bars in Windows". You can just search and disable it.

This works, but it seems to only take effect for new instances of Windows Terminal.

It looks like that was fixed, and the Accessibility option is effective immediately and on existing windows now.

@zadjii-msft zadjii-msft removed this from the Terminal Backlog milestone Jan 4, 2022
@zadjii-msft zadjii-msft added this to the Backlog milestone Jan 4, 2022
@ghost ghost added the In-PR This issue has a related PR label Sep 20, 2022
@ghost ghost closed this as completed in #14047 Sep 21, 2022
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Sep 21, 2022
ghost pushed a commit that referenced this issue Sep 21, 2022
This fixes #3454 by adding support for an "always" mode for the scroll bar.

This change uses a custom VisualStateManager to keep the scroll bar from collapsing if the profile is using the 'always' setting.

## Validation Steps Performed
Tried updating settings.json directly and using the UI and making sure the scroll bar behaves as expected.

Closes #3454
@ghost
Copy link

ghost commented Jan 24, 2023

🎉This issue was addressed in #14047, which has now been successfully released as Windows Terminal Preview v1.17.1023.:tada:

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Area-TerminalControl Issues pertaining to the terminal control (input, selection, keybindings, mouse interaction, etc.) good first issue This is a fix that might be easier for someone to do as a first contribution Help Wanted We encourage anyone to jump in on these. Issue-Task It's a feature request, but it doesn't really need a major design. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

11 participants