diff options
author | Shawn Rutledge <shawn.rutledge@qt.io> | 2024-06-20 16:47:22 -0700 |
---|---|---|
committer | Shawn Rutledge <shawn.rutledge@qt.io> | 2024-06-21 13:32:56 -0700 |
commit | e94bd61da37270f9fa54c3b2202b13a3f388118d (patch) | |
tree | bfa4af8ebbc72f8193fc1b225f3417cf8d1d8cbc /src/quickcontrols/imagine/design/9-patch-export.sketchplugin/Contents/Sketch | |
parent | 1bee5e0e3841b5134f680a61e2cb54b5004709cb (diff) |
If a TapHandler is used to open a menu:
TapHandler {
acceptedButtons: Qt.RightButton
onPressedChanged: if (pressed) backgroundContextMenu.popup()
}
and popup() blocks and then eats the mouse release (as
QCocoaMenu::showPopup() does), it means QQuickTapHandler::setPressed()
is not allowed to finish executing before being blocked, and it has no
chance to get the mouse release afterwards either (that release may have
been the one that selected a menu item, which presumably is why macOS
eats it). But it behaves well enough if we cancel the grab, and thereby
cause QQuickTapHandler::onGrabChanged() to be called with
CancelGrabExclusive or CancelGrabPassive. setPressed(false) will be
called before setPressed(true) has finished: that works OK in practice,
because it doesn't do much else after the `emit pressedChanged()` line.
But when QQuickTapHandler::onGrabChanged() calls setPressed(false)
after the grab is already canceled, the event is not passed along;
so check for null before calling setExclusiveGrab(event, point, false).
TapHandler has just been informed that the grab was canceled, so it
doesn't need to ungrab again.
Pick-to: 6.8
Fixes: QTBUG-126539
Change-Id: I657a6e9b4581df4dd284d6f488e4101c2a2faf4c
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Diffstat (limited to 'src/quickcontrols/imagine/design/9-patch-export.sketchplugin/Contents/Sketch')
0 files changed, 0 insertions, 0 deletions