From ec9aa9f12142de82315eb6d37f121311ec8408bc Mon Sep 17 00:00:00 2001 From: J-P Nurmi Date: Mon, 12 Mar 2018 13:27:59 +0100 Subject: Sliders and Dials: keep mouse grab on press Since Qt 5.9, Sliders and Dials react immediately on mouse press. Thus, the old logic to keep mouse grab if the drag threshold was exceeded no longer makes sense with mouse. Don't allow e.g. Drawer to steal mouse press if a Slider or Dial is already being dragged. Task-number: QTBUG-66637 Change-Id: I76f7ab59180c1f3fb66db8412d7cccfbd373aee3 Reviewed-by: Mitch Curtis --- tests/auto/qquickdrawer/tst_qquickdrawer.cpp | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'tests') diff --git a/tests/auto/qquickdrawer/tst_qquickdrawer.cpp b/tests/auto/qquickdrawer/tst_qquickdrawer.cpp index bba1cf45..e3a6ccf2 100644 --- a/tests/auto/qquickdrawer/tst_qquickdrawer.cpp +++ b/tests/auto/qquickdrawer/tst_qquickdrawer.cpp @@ -1263,13 +1263,17 @@ void tst_QQuickDrawer::nonModal() void tst_QQuickDrawer::slider_data() { QTest::addColumn("mouse"); - QTest::newRow("mouse") << true; - QTest::newRow("touch") << false; + QTest::addColumn("delta"); + + QTest::newRow("mouse") << true << 2; + QTest::newRow("touch") << false << 2; + QTest::newRow("mouse,delta") << true << 296 / 8; } void tst_QQuickDrawer::slider() { QFETCH(bool, mouse); + QFETCH(int, delta); QQuickApplicationHelper helper(this, QStringLiteral("slider.qml")); QQuickWindow *window = helper.window; @@ -1295,7 +1299,7 @@ void tst_QQuickDrawer::slider() QTest::touchEvent(window, touchDevice.data()).press(0, from); int distance = qAbs(from.x() - to.x()); - for (int dx = 2; dx < distance; dx += 2) { + for (int dx = delta; dx <= distance; dx += delta) { if (mouse) QTest::mouseMove(window, from - QPoint(dx, 0)); else -- cgit v1.2.3 From 79964673d1587f9e6a254cb6a1f0dd0645b946e6 Mon Sep 17 00:00:00 2001 From: J-P Nurmi Date: Mon, 12 Mar 2018 13:07:12 +0100 Subject: ComboBox: fix key search in the popup ComboBox does not change its current index, but highlighted index, when navigating in the popup. If the popup is accepted, the currently highlighted index is applied as the new current index. However, if the popup is rejected, the old current index is kept intact. This is why there is a separation between current and highlighted index. The newly added key search functionality (added together with ComboBox::editable) was missing a check whether the popup is visible. It was unconditionally changing the current index, which lead to a wrong behavior when the popup was open. Task-number: QTBUG-61348 Change-Id: Ic0295db609495ccefbccb7c425a817926786014e Reviewed-by: Mitch Curtis --- tests/auto/controls/data/tst_combobox.qml | 54 +++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) (limited to 'tests') diff --git a/tests/auto/controls/data/tst_combobox.qml b/tests/auto/controls/data/tst_combobox.qml index 5389a04a..30d6a93c 100644 --- a/tests/auto/controls/data/tst_combobox.qml +++ b/tests/auto/controls/data/tst_combobox.qml @@ -629,36 +629,90 @@ TestCase { compare(control.currentIndex, 0) compare(control.currentText, "Banana") + compare(control.highlightedIndex, -1) keyPress(Qt.Key_C) compare(control.currentIndex, 1) compare(control.currentText, "Coco") + compare(control.highlightedIndex, -1) // no match keyPress(Qt.Key_N) compare(control.currentIndex, 1) compare(control.currentText, "Coco") + compare(control.highlightedIndex, -1) keyPress(Qt.Key_C) compare(control.currentIndex, 2) compare(control.currentText, "Coconut") + compare(control.highlightedIndex, -1) keyPress(Qt.Key_C) compare(control.currentIndex, 4) compare(control.currentText, "Cocomuffin") + compare(control.highlightedIndex, -1) // wrap keyPress(Qt.Key_C) compare(control.currentIndex, 1) compare(control.currentText, "Coco") + compare(control.highlightedIndex, -1) keyPress(Qt.Key_A) compare(control.currentIndex, 3) compare(control.currentText, "Apple") + compare(control.highlightedIndex, -1) keyPress(Qt.Key_B) compare(control.currentIndex, 0) compare(control.currentText, "Banana") + compare(control.highlightedIndex, -1) + + // popup + control.popup.open() + tryCompare(control.popup, "opened", true) + + compare(control.currentIndex, 0) + compare(control.highlightedIndex, 0) + + keyClick(Qt.Key_C) + compare(control.highlightedIndex, 1) // "Coco" + compare(control.currentIndex, 0) + + // no match + keyClick(Qt.Key_N) + compare(control.highlightedIndex, 1) + compare(control.currentIndex, 0) + + keyClick(Qt.Key_C) + compare(control.highlightedIndex, 2) // "Coconut" + compare(control.currentIndex, 0) + + keyClick(Qt.Key_C) + compare(control.highlightedIndex, 4) // "Cocomuffin" + compare(control.currentIndex, 0) + + // wrap + keyClick(Qt.Key_C) + compare(control.highlightedIndex, 1) // "Coco" + compare(control.currentIndex, 0) + + keyClick(Qt.Key_B) + compare(control.highlightedIndex, 0) // "Banana" + compare(control.currentIndex, 0) + + keyClick(Qt.Key_A) + compare(control.highlightedIndex, 3) // "Apple" + compare(control.currentIndex, 0) + + verify(control.popup.visible) + + // accept + keyClick(Qt.Key_Return) + tryCompare(control.popup, "visible", false) + compare(control.currentIndex, 3) + compare(control.currentText, "Apple") + compare(control.highlightedIndex, -1) } function test_popup() { -- cgit v1.2.3 From 5c2b1bee5258981800c623dc3f054b15d7875484 Mon Sep 17 00:00:00 2001 From: Simon Hausmann Date: Mon, 12 Mar 2018 15:01:06 +0100 Subject: Fix doubly connected signals in SignalSequenceSpy We call __setup() from two different onFooChanged signal handlers. If we access the second property from within that method, we may end up being the first one to read that property and consequently require an initialization of the binding to that property first, which will write the value (before returning) and trigger the signal handler, recursively calling __setup() and thus calling connect() twice for each signal the spy wants to connect to. This used to be fine as we ended up with a _third_ evaluation that called __setup() and thus cleared the connections first, but after commit f514451cc2e3610e160b5dc8ccd1e390730ecc67 in declarative we avoid unnecessary binding evaluations if possible and therefore uncovered this bug. Task-number: QTBUG-66995 Change-Id: I83ef9c80978a88c1490174d3cdb21b149733a78f Reviewed-by: J-P Nurmi --- tests/auto/controls/data/SignalSequenceSpy.qml | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) (limited to 'tests') diff --git a/tests/auto/controls/data/SignalSequenceSpy.qml b/tests/auto/controls/data/SignalSequenceSpy.qml index fe47a3c1..d14a5ee6 100644 --- a/tests/auto/controls/data/SignalSequenceSpy.qml +++ b/tests/auto/controls/data/SignalSequenceSpy.qml @@ -72,10 +72,15 @@ QtObject { property var __connections: [] onExpectedSequenceChanged: reset() - onTargetChanged: __setup() - onSignalsChanged: __setup() - function __setup() { + // We may call __setup from onTargetChanged and as we would read the signals property + // inside __setup, we may be initializing the binding for signals for the first time, which + // will write the value to the property and trigger onSignalsChanged and call __setup + // again. One easy way to protect against it is to evaluate those two dependencies upfront + onTargetChanged: __setup(target, signals) + onSignalsChanged: __setup(target, signals) + + function __setup(target, signals) { if (__oldTarget) { __connections.forEach(function (cx) { __oldTarget[cx.name].disconnect(cx.method) -- cgit v1.2.3