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 e4ef0f0

Change-Id: I0c6c03452a5b952161c9898d84d2c17afa52fc95
Reviewed-by: Shawn Rutledge <[email protected]>

src/gui/kernel/qwindow.cpp

@@ -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;