Bug 446014 - Don't allow change the options of a dropdown menu through the mouse scroll without opening the dropdown menu first
Summary: Don't allow change the options of a dropdown menu through the mouse scroll wi...
Status: RESOLVED FIXED
Alias: None
Product: frameworks-qqc2-desktop-style
Classification: Unclassified
Component: general (show other bugs)
Version: 5.88.0
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Marco Martin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-24 05:24 UTC by Photon
Modified: 2022-01-07 03:04 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: Frameworks 5.90 with Plasma 5.24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Photon 2021-11-24 05:24:50 UTC
STEPS TO REPRODUCE
1. Right click in the up arrow from the system tray > Configure system tray > Entries.
2. Place the mouse on any dropdown (don't open it) and scroll the mouse.

OBSERVED RESULT
The options will change. This can cause inadvertently changes that may lead the user into a bad state. For example, a user change some option just for the battery icon, but at some point the he/she "scrolled" the mouse on the Audio Volume dropdown menu. After hitting the apply button, the two options will be applied.

EXPECTED RESULT/PROPOSED
Changing the options through the mouse scroll should only be possible after opening the dropdown menu.
Comment 1 Photon 2021-11-24 05:27:45 UTC
The example I gave might be simple, but this happens throughout the entire shell and applications. Really sensitive settings can be changed without the user noticing. I don't know if it's a Qt thing.
Comment 2 Nate Graham 2021-11-24 16:40:13 UTC
It is a Qt thing. Some people like it, others don't. We are working on a way to make the control only react to a scroll when you actually scroll while the cursor is deliberately over it, rather then when you scroll the view and the control happens to move under your cursor.

However I submitted a MR to make this happen only when the control itself is focused: https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/99

That became controversial though, so I don't know if it will be merged. Keeping this open to see how the discussion there shakes out.
Comment 3 Photon 2021-11-30 14:48:36 UTC
Whoops, my bug report is a duplicate of https://bugs.kde.org/show_bug.cgi?id=399324
Comment 4 Nate Graham 2021-11-30 14:57:00 UTC
Not exactly; It's the same issue, but this bug report tracks fixing it in the qqc2-desktop-style, which is used for QtQuick apps. Bug 399324 tracks fixing it for QtWidgets apps. The different user interface frameworks require different fixes in different places.
Comment 5 Nate Graham 2022-01-06 16:57:15 UTC
This has been fixed by Noah Davis with https://invent.kde.org/frameworks/kirigami/-/commit/f6ca218607ff7e5d5066eb3224154c3256cb9516 in Frameworks 5.90 with Plasma 5.24.

The fix is as follows: Now when you scroll on a scrollable view, any controls on the view which handle scroll events (like the sliders here) will not start changing when the cursor passes over them. They will only respond to a scroll when the cursor *starts* over them, not when it just happens to pass over them because the view is scrolling. This fixes the annoyance described here while preserving the controls' ability to be modified by scrolling on them, giving us the best of both worlds. Thanks Noah!
Comment 6 Photon 2022-01-07 03:04:49 UTC
Wow, incredible work!