Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
6.7, 6.8
-
None
Description
Seems like this may be the same as QTBUG-118454 except this time it came up while trying to use a TapHandler to open a popup menu which itself has menu items with TapHandlers in them (pure Qt Quick, no Controls, only on X11 not on Wayland):
1 QInputEvent::timestamp qevent.h 58
2 QQuickTapHandler::setPressed qquicktaphandler.cpp 409
3 QQuickTapHandler::onGrabChanged qquicktaphandler.cpp 478
4 QQuickDeliveryAgentPrivate::onGrabChanged qquickdeliveryagent.cpp 1787
5 QtPrivate::FunctorCall<QtPrivate::IndexesList<0, 1 qobjectdefs_impl.h 153
6 QtPrivate::FunctorCallBase::call_internal<void, Qt, qobjectdefs_impl.h 72
7 QtPrivate::FunctorCall<QtPrivate::IndexesList<0, 1 qobjectdefs_impl.h 152
8 QtPrivate::FunctionPointer<void (QQuickDeliveryAge qobjectdefs_impl.h 200
9 QtPrivate::QPrivateSlotObject<void (QQuickDelivery qobject_p.h 284
10 QtPrivate::QSlotObjectBase::call qobjectdefs_impl.h 487
11 doActivate<false> qobject.cpp 4111
12 QMetaObject::activate qobject.cpp 4171
13 QPointingDevice::grabChanged moc_qpointingdevice.cpp 296
14 QPointingDevicePrivate::setExclusiveGrabber qpointingdevice.cpp 516
15 QQuickDeliveryAgentPrivate::handleWindowDeactivate qquickdeliveryagent.cpp 1356
16 QQuickWindow::event qquickwindow.cpp 1624
- TapHandler has a grab
- its window is deactivated
- QQuickDeliveryAgentPrivate::handleWindowDeactivate() calls devPriv->setExclusiveGrabber(nullptr, epd.eventPoint, nullptr);
- QPointingDevicePrivate::setExclusiveGrabber() emits grabChanged(tapHandler, QPointingDevice::UngrabExclusive, null, eventPoint) : it's UngrabExclusive not CancelGrabExclusive because it's not a take-over: there's no new grabber
- QQuickTapHandler::onGrabChanged() calls setPressed(false, false, nullptr, eventPoint)
It's correct that TapHandler should no longer be pressed, but it can't access any event properties because there is no event. It should not crash, but it does. If the transition was CancelGrabExclusive we would not have this issue; but the question is did we define correctly what a cancel means? Currently it's decided just on the basis that there is no new grabber: the old grab is not being canceled by being taken over by another grabber. But in a way it's a cancellation of the gesture in progress (like a rug-pull: the window is no longer activated, either because it's no longer shown or because the popup window was activated instead).
Anyway we can add null pointer checks easily enough.
Attachments
Issue Links
- duplicates
-
QTBUG-118454 Crash in QQuickTapHandler::setPressed() with nullptr access
- Open
- relates to
-
QTBUG-110262 TapHandler "hangs" if QtQuick window looses focus during onPressedChanged
- Reported
-
QTBUG-78617 Ungrab does not work for Input Handlers
- Closed
Gerrit Reviews
For Gerrit Dashboard: QTBUG-124777 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
557654,8 | Ensure TapHandler.pressed==false if not active; tolerate null event | dev | qt/qtdeclarative | Status: NEW | 0 | -1 |