Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
5.15.2, 5.15
Description
If input widgets like `QSpinBox`, `QComboBox` and `QFontComboBox` (any that change value in reaction to scroll events) are children of a parent for which vertical scrolling is active, then during a scroll action on the parent, if such a widget happens to move under the cursor then that widget hijacks the scroll action and the user suddenly finds themselves changing the value of the widget rather than scrolling the "page"/"panel" the widget is a part of.
I'm experiencing this with a touchpad. I have "two-finger scrolling" enabled in Gnome settings.
What I expect to happen is that for the duration of the scroll action any such widgets moving under the cursor should simply pass under it without interaction. Scrolling of the value of an editable widget should only occur if the cursor was over the widget when the scroll action started.
This is an issue for the preferences interface of VLC media player, for which I'm trying to investigate this issue. Looking for other example applications with similar scrollable interfaces, I found that Keepassxc (Qt based) is also affected, whilst the presumably GTK-based Gnome tweaks tool is not.
This behaviour is surprising and very problematic. For instance within the VLC preference interfaces there are many "panels" that have enough settings widgets that vertical scrolling is needed to see them all. If a user moves their cursor over such a "panel" and then using two fingers on their touchpad in a dragging motion they initiate a scrolling action, there's a high chance that something will pass underneath the cursor and thus run into this problem. This not only interrupts the "page" scroll action, but now a setting has unintentionally been changed. At best, if the user happens to know the original value of the setting then they can just set it back, move the cursor and resume scrolling. At worst either the user has noticed the problem and has to close the dialog to throw away the unintended change and then start over, or worse they have not even noticed/understood what has happened and end up saving changes they never intended to make.
I have tried changing the focus policy of the `QComboBox` widgets used within the VLC preferences interface to `Qt::StrongFocus` (to avoid `Qt::WheelFocus`), but that had no impact. I am not aware of any attribute that I could toggle to change this behaviour. I am not aware whether or not this could be fixed with a custom event handler, but that would be a very undesirable solution even if it would work. I feel that this behaviour is simply bad and needs fixing within the Qt framework itself.
I only have a Linux system available to test this on. I'm using Debian Sid.
Attachments
Issue Links
- relates to
-
QTBUG-38053 Disabled QGraphicsItem prevents view scroll with mouse wheel
- Open