Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
5.14.0 Alpha
-
None
Description
Every WheelHandler eventually deactivates because of the timeout (100ms by default) after no more events have been received. But it would be an improvement if it would deactivate immediately when its parent has moved relative to the mouse cursor (or the mouse cursor has moved relative to it) such that it will no longer receive events, especially if another WheelHandler instance will now receive them. Currently multiple WheelHandlers can be active at the same time when this happens; that is not strictly correct.
Also, Mac users expect not to have the "focus" of scrolling change when there is "momentum" on a Magic Mouse and it is dragged to another widget, especially if it was unintentional. (You can't see the wheel spinning, but the mouse acts like it is until the virtual momentum stops.)
The trouble is that QQuickWindowPrivate::deliverSinglePointEventUntilAccepted() does the delivery only to the first WheelHandler whose wantsPointerEvent() returns true, and there is no grab; so there is no way for the handler that is "losing focus" to find out. Maybe it would be more consistent if wheel events were also grabbed, so that the grab could be taken over by another handler. But it's the mouse that is normally grabbed; we don't yet have a way to record the grab of just one wheel (remember the mouse has two of them, horizontal and vertical) individually. But maybe we could use passive grabs for this, and have deliverSinglePointEventUntilAccepted() deliver the wheel events to passive grabbers at the end of regular delivery. Those handlers would be able to see that the event is already accepted, so wants() could return false, and thus the grab could be given up. https://codereview.qt-project.org/#/c/258886/
But changing deliverSinglePointEventUntilAccepted() would affect other event types too, such as native gestures. And maybe the same grab concept is appropriate for them too.
https://codereview.qt-project.org/#/c/259924/ shows that the autotest has a TODO about this.
Attachments
Issue Links
- relates to
-
QTBUG-50199 [OS X] Mouse scroll event started from one widget continues when moving mouse cursor over another widget
- Closed
- resulted from
-
QTBUG-68119 add a WheelHandler
- Closed