Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.9.5, 5.12.1, 5.12.8, 5.15.9, 5.15.2, 6.4.0 Beta1
-
None
-
-
d7b5a48558 (qt/qtdeclarative/dev) d7b5a48558 (qt/tqtc-qtdeclarative/dev) 8e1c3f4dbe (qt/qtdeclarative/6.3) 8e1c3f4dbe (qt/tqtc-qtdeclarative/6.3) 5b30ba3436 (qt/qtdeclarative/6.4) 5b30ba3436 (qt/tqtc-qtdeclarative/6.4)
Description
I'm trying to place a MouseArea as a child of a Flickable, with the MouseArea filling and overlayed on top of the Flickable. The MouseArea is supposed to detect when the user begins to drag horizontally while the Flickable scrolls vertically. It is also supposed to let through Clicked events so the items inside the Flickable may act on clicks, so propagateComposedEvents is set to true.
I'm running into an issue where the first vertical drag on the MouseArea is not stolen by the Flickable as expected. Instead, the drag is registered as a Click event at the point of its release. This is demonstrated by the following minimal code snppet (taken from this StackOverflow question): test.qml
To test for this issue, run the snippet in qmlscene and perform the following:
- Try to scroll the Flickable vertically by dragging with the mouse
- Observe the "clicked" message in the console
- Try to scroll by dragging again, which works normally
After the first complete mouse event (which may be a drag or a click), the Flickable steals mouse events as expected. Before that, the MouseArea holds the event and registers it as a click.
I've worked around this issue by explicitly denying the first Pressed event on my MouseArea: https://github.com/ubports/unity8/pull/116/files. The StackOverflow asker worked around it by setting propagateComposedEvents to false. Either option disables some behavior that is potentially useful, at least for the first mouse event after the program starts.
Attachments
Issue Links
- duplicates
-
QTBUG-38765 When propagateComposedEvents is set, drag does not always move the flickable
- Closed
- relates to
-
QTBUG-107239 DragHandler propagates tap event through Flickable to underlying TapHandler
- Reported