QWindowPrivate::forwardToPopup: fix QMenu touch press-drag-release

QMenu doesn't handle touch events, but depends on mouse synthesis.
QGuiApplicationPrivate::processTouchEvent() calls
QWindow::forwardToPopup(), which sends it to the popup window, which
sends it to QMenu. The inherited QWidget::event() calls
QEvent::ignore(). It's important for forwardToPopup() to return nullptr
when the event is not handled, so that processTouchEvent() goes on to
create the synth-mouse event and send it to processMouseEvent(), which
calls forwardToPopup() again, which QMenu::mouseMoveEvent() handles.
And we also follow the usual pattern that when an event is duplicated
for delivery (as a synthetic event, or just to remap it), the accepted
state of the original event must be updated to reflect whether or not
the cloned event was accepted.

QTabletEvents are handled similarly.

Amends e4ef0f03e6

Change-Id: I0c6c03452a5b952161c9898d84d2c17afa52fc95
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
bb10
Shawn Rutledge 2024-05-30 21:26:15 -07:00
parent 7afff8c16e
commit d06047698c
1 changed files with 5 additions and 2 deletions

View File

@ -2446,8 +2446,11 @@ const QWindow *QWindowPrivate::forwardToPopup(QEvent *event, const QWindow */*ac
/* Popups are expected to be able to directly handle the
drag-release sequence after pressing to open, as well as
any other mouse events that occur within the popup's bounds. */
if (QCoreApplication::sendEvent(popupWindow, pointerEvent.get()))
ret = popupWindow;
if (QCoreApplication::sendEvent(popupWindow, pointerEvent.get())) {
event->setAccepted(pointerEvent->isAccepted());
if (pointerEvent->isAccepted())
ret = popupWindow;
}
qCDebug(lcPopup) << q << "forwarded" << event->type() << "to popup" << popupWindow
<< "handled?" << (ret != nullptr) << event->isAccepted();
return ret;