Bug 446014

Summary:	Don't allow change the options of a dropdown menu through the mouse scroll without opening the dropdown menu first
Product:	[Frameworks and Libraries] frameworks-qqc2-desktop-style	Reporter:	Photon <ncqm3qdz>
Component:	general	Assignee:	Marco Martin <notmart>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	ahiemstra, kde, nate, noahadvs, plasma-bugs
Priority:	NOR
Version:	5.88.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	https://invent.kde.org/frameworks/kirigami/-/commit/f6ca218607ff7e5d5066eb3224154c3256cb9516	Version Fixed In:	Frameworks 5.90 with Plasma 5.24

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!