diff options
| author | Shawn Rutledge <shawn.rutledge@qt.io> | 2020-11-17 21:56:10 +0100 |
|---|---|---|
| committer | Shawn Rutledge <shawn.rutledge@qt.io> | 2020-11-18 23:13:55 +0100 |
| commit | cb3cfdf661483ada83a2189b220ad893d5acf223 (patch) | |
| tree | ebdad38d79d41acdecd6dcdd51ec03666eff8492 | |
| parent | 423a9124e74f89bf91fd9f5a75491bd6f3a28897 (diff) | |
Stop ungrabbing due to FocusAboutToChange
The goal is to un-blacklist the test for QTBUG-60123. To that end:
revert 7b2e2117162594a2d0234bb02408f5b5a446488b and its followup
6933b7e8e6dc279a8eb34e1f4c60bc109dfb7d26. There is no detailed bug
report explaining exactly why those were done, just the comment on code
review: "This fixes the desktop components' combo box on linux
re-opening at random times", probably referring to a combobox popup
window in Controls 1. But when using QWidget::createWindowContainer()
in two different windows and clicking MouseAreas in each of them, it
turns out that this change of focus is causing the mouse grab to be
canceled. The grab should be naturally given up after mouse release;
canceling prematurely doesn't make sense.
The Qt 5 fix for this bug was e0c30279ec1fad88346ed3fb483bc3c672fdd01b
which tracked the grab on a per-window basis. It would be difficult to
do that again now (change QPointingDevicePrivate::setExclusiveGrabber()
to store a separate grabber for each window in which a grab occurred?
what could go wrong...) It seems odd to have the same QEventPoint
grabbed in two different windows at the same time, but popups need event
forwarding so maybe that was why (if a MouseArea triggers the popup,
should it stay pressed and keep its grab? the subsequent mouse moves and
the release need to be forwarded to the popup, so maybe something inside
the popup needs a grab, simultaneously or not). Anyway we don't have
actual popup windows in Controls 2 right now; and we know that event
forwarding for popups needs work in QtGui so that it will be easier when
we try again to have them in Qt Quick (QTBUG-68080). So perhaps the
original workaround has outlived its usefulness: popup event forwarding
needs to be handled at the lower layer, not in Qt Quick.
Task-number: QTBUG-57253
Task-number: QTBUG-60123
Task-number: QTBUG-86729
Change-Id: I56dbc3bb94f66a7f26f79a97bcb2f2bbc0b7aa92
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
| -rw-r--r-- | src/quick/items/qquickwindow.cpp | 2 | ||||
| -rw-r--r-- | tests/auto/quick/qquickitem/BLACKLIST | 2 |
2 files changed, 0 insertions, 4 deletions
diff --git a/src/quick/items/qquickwindow.cpp b/src/quick/items/qquickwindow.cpp index e09723e973..8a10befe45 100644 --- a/src/quick/items/qquickwindow.cpp +++ b/src/quick/items/qquickwindow.cpp @@ -1961,8 +1961,6 @@ bool QQuickWindow::event(QEvent *e) if (d->activeFocusItem) qGuiApp->inputMethod()->commit(); #endif - if (mouseGrabberItem()) - mouseGrabberItem()->ungrabMouse(); break; case QEvent::UpdateRequest: { if (d->windowManager) diff --git a/tests/auto/quick/qquickitem/BLACKLIST b/tests/auto/quick/qquickitem/BLACKLIST index af5b63e1bc..d94a3ef102 100644 --- a/tests/auto/quick/qquickitem/BLACKLIST +++ b/tests/auto/quick/qquickitem/BLACKLIST @@ -1,4 +1,2 @@ [contains:hollow square: testing points inside] xcb -[qtBug60123] -* # QTBUG-86729 |