BUG: Vertical Scrolling Issue with Touchpad

[3C0D]

Checks

• [X] I have checked that this issue has not already been reported.

• [X] I am using the latest version of Flow Launcher.

Problem Description

Vertical scrolling is way too sensitive on a laptop

To Reproduce

1. ...
2. ...
3. ...

Screenshots

No response

Flow Launcher Version

1.18.0

Windows Build Number

10.0.22631.3958

Error Log

Replace this line with the important log contents.

[deefrawley]

Going to need some more detail here please. What is "way too sensitive"? Compared to a desktop? Not sure how they would differ, could it be a laptop touchpad/mouse issue?

[3C0D]

How can I say that, for example, the sensitivity is normal here, on this page. If I want to make a small movement, it works fine. However, when using Flow Launcher, like when I'm browsing the list of plugins, it goes super fast (on a touchpad, HP). Maybe enabling smooth scrolling could help reduce this issue if it's not already turned on.

[deefrawley]

I didn't think each app uses its own mouse scroll logic/setting - I thought it was a system setting. Certainly on my desktop and laptop the scroll speed in Flow is the same as any other app or window. Will let a core dev comment more specifically for Flow.

[jjw24]

I think mouse scroll speed is fine but touchpad is actually scrolling a lot faster when scrolling though the plugin settings.

[kPepis]

I got here because I searched for Flow Launcher scrolling issues. The issue is that the step size is huge when scrolling in the launcher or the settings. By the way, I'm using a mouse on Windows 11, not a trackpad.

In case anyone else gets here after a search, like I did, the culprit for me was SmoothScroll. Disabling SmoothScroll for Flow Launcher makes scrolling return to normal. I'm not sure whether this is a SmoothScroll or Flow Launcher issue, but in my limited use of SmoothScroll on Windows, this is the only app that has misbehaved.

[Tamnac]

Same issue with trackpad on all pages, but it works fine with mouse.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 60 days.\n\nAlternatively this issue can be kept open by adding one of the following labels:\nkeep-fresh

[dhakkann]

Same issue. Scrolling is fine with mouse, but scrolling with trackpad is way too fast in launcher or settings page. This is only the case for flow launcher, in other programs scrolling with touchpad works as intended.

[ErnstHot]

Same issue here, scrolling is fine in all other apps but FlowLauncher where even the smallest movement I can make on the track pad scrolls more than a page. I don't have SmoothScroll installed, nor to my knowledge any other app that might interfere with scrolling.

Windows 11, Zenbook S 16 UM5606

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 60 days.\n\nAlternatively this issue can be kept open by adding one of the following labels:\nkeep-fresh

[github-actions[bot]]

This issue was closed because it has been stale for 7 days with no activity. If you feel this issue still needs attention please feel free to reopen.

[TechySC23]

same here, Laptop user here. WAY, WAYYYYY too sensitive. i use a mouse normally, and actually am a keyboard user, so I use arrow keys primarily. But after seeing this issue I finally investigated, and yes this is true. tbh the settings page isnt that of a big deal to me as i have tricks for too sensitive pages, that is to anchor my two fingers at one place (center of touchpad) then move the fingers like levers, which compensate for the high sensitivity. But touchpads arent meant to be used like that.

[TechySC23]

Same issue here, scrolling is fine in all other apps but FlowLauncher where even the smallest movement I can make on the track pad scrolls more than a page. I don't have SmoothScroll installed, nor to my knowledge any other app that might interfere with scrolling.

Windows 11, Zenbook S 16 UM5606

True for me as well

[onesounds]

@Jack251970 I'm not entirely sure, but as far as I know, switching frameworks doesn't really solve this issue. Even putting ModernWPF aside, I believe it's tied to two problems: the scroll settings and the layout logic (specifically the code that aligns the scroll position based on item height). From what I understand, you'd need to completely refactor both the XAML and the item height-related code together.

It seems that the recent CmdPal results window has addressed this by simply using a standard scroll without implementing any positioning logic based on item height. PowerToys probably handles result item heights more flexibly as well — which is why the height doesn't snap cleanly to exact boundaries.

[Jack251970]

@Jack251970 I'm not entirely sure, but as far as I know, switching frameworks doesn't really solve this issue. Even putting ModernWPF aside, I believe it's tied to two problems: the scroll settings and the layout logic (specifically the code that aligns the scroll position based on item height). From what I understand, you'd need to completely refactor both the XAML and the item height-related code together.

It seems that the recent CmdPal results window has addressed this by simply using a standard scroll without implementing any positioning logic based on item height. PowerToys probably handles result item heights more flexibly as well — which is why the height doesn't snap cleanly to exact boundaries.

Please see ScrollViewerEx control in UI.WPF.Modern. I found that if I enabled RewriteWheelChange property, the sensitivity of mouse wheel and touch board should be the same (they are both very fast).

And I also make a PR for wheel sensitivity support (https://github.com/iNKORE-NET/UI.WPF.Modern/pull/240).

[onesounds]

Do you think this is important? From my perspective, it's relatively low priority, so I haven't looked into it in detail. Assuming you're right, it seems like we could just implement our own ScrollViewer for the result output section. If you think it's necessary, I can take a closer look.

[Jack251970]

Do you think this is important? From my perspective, it's relatively low priority, so I haven't looked into it in detail. Assuming you're right, it seems like we could just implement our own ScrollViewer for the result output section. If you think it's necessary, I can take a closer look.

Not necessarily, but if this can be resolved using the built-in functionality of the new UI framework, we could address it when implementing the framework migration.

[H5820121]

@Jack251970 I am also experiencing this issue on two laptops that I use ASUS & LENOVO WIN11, scrolling in FL is significantly faster than other applications and makes it difficult to use FL. I would be very grateful if you could resolve this issue soon, and I'm sure others will too!

[Jack251970]

@Jack251970 I am also experiencing this issue on two laptops that I use ASUS & LENOVO WIN11, scrolling in FL is significantly faster than other applications and makes it difficult to use FL. I would be very grateful if you could resolve this issue soon, and I'm sure others will too!

I am afraid we cannot resolve this very soon. Currently, I would like to resolve it with new UI framework https://github.com/iNKORE-NET/UI.WPF.Modern, and based on its development progress, I think we cannot introduce it in such a short time.

[H5820121]

@Jack251970 Thank you, I'm glad to hear that at least there is progress towards the fix, and that the issue is in your good hands!

[H5820121]

@jjw24 @Jack251970 Thank you very much, now it's great!

[jjw24]

No worries, Jack did all the great work to get this fixed 💯