aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix QQuickShortcut::setContext so re-grab all shortcutsAndreas Buhr2021-01-131-0/+44
| | | | | | | | | | | | A while ago, QQuickShortcut was extended to not only have a shortcut m_shortcut but in addition a list m_shortcuts. During this extension, the setContext method was missed: Shortcuts in m_shortcuts are not re-grabbed on context change. This patch fixes this. Task-number: QTBUG-88682 Pick-to: 6.0 5.15 Change-Id: Ie73d516f2a325a328b6e975d69490eea29a18401 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Blacklist failing tests for QEMU ARMv7Samuli Piippo2021-01-073-0/+12
| | | | | | | | | QEMU has a bug that prevents fontconfig to work correctly, which causes font related testcase to fail. Blacklist those when running them in CI. Task-number: QTQAINFRA-4127 Change-Id: Id6970be0db49128fb46838dbec04bc6f26048761 Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Refactor QQuickTextInput test to use QKeyCombinationVolker Hilsheimer2020-12-101-75/+35
| | | | | | | | | | Makes the code typesafe, simplifies the data structures, and fixes a compiler warning from implicit conversion from/to int. Pick-to: 6.0 Fixes: QTBUG-89356 Change-Id: I52d834811fa7325788fc71ea20f78b4afe3fdb86 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* CMake: Regenerate projects using pro2cmake one last timeAlexandru Croitor2020-12-104-3/+9
| | | | | | | | | And fix up some incorrect qmake project files Pick-to: 6.0 Change-Id: Ia6d27ac68195635021fe7c4a5f06386a60f3f323 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Show a tableview even if the syncView has an empty modelAndy Shaw2020-12-091-0/+43
| | | | | | | | | | By showing the tableview, we can be sure that headerviews will be visible even in the syncView has an empty model. Fixes: QTBUG-87526 Change-Id: I68c8b119122a2d2f88c2afbeb2d6c71a83a3ce33 Pick-to: 5.15 6.0 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Blacklist testTransitionsWithImplicitFrom on openSUSE againLiang Qi2020-12-081-1/+1
| | | | | | | | This amends f87c4c7c2a0866662143fdbb3060e7d6ccaf337c. Task-number: QTBUG-89023 Change-Id: I4d3e03df6071b4fbaef3d1c60605dc68ca37aaad Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
* QML engine: Deprecate DefaultMethodFabian Kosmale2020-12-031-1/+3
| | | | | | | | | | | | | | | | | | | | | | Assigning objects to signal handlers can be convenient, as seen in the examples which use it together with ListView.onRemove. However, that convenience makes it hard to reason about what actually happens. Moreover, the only user of that functionality are the Animation classes, and the usage of DefaultMethod is not documented anywhere. [ChangeLog][QtQml] Assigning an object to a signal handler is deprecated. Instead, create the object, give it an id, and call the desired slot from the signal handler. For instance, instead of of ListView.onRemove: SequentialAnimation {...} use SequentialAnimation {id: removeAnimation; ...} ListView.onRemove: removeAnimation.start() A warning will be printed whenever an assignment of an object to a signal handler occurs. The warning can be controlled via the qt.qml.defaultmethod logging category. Change-Id: I001ddf4d7933871977f84a5e012d020fb043cc64 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Un-blacklist tst_TouchMouse::hoverEnabledShawn Rutledge2020-12-011-3/+0
| | | | | | | Task-number: QTBUG-86729 Task-number: QTBUG-40856 Change-Id: I6936833236b584d9f91cca1583434fa9982ec569 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Blacklist testTransitionsWithImplicitFrom on openSUSELiang Qi2020-12-011-0/+1
| | | | | | Task-number: QTBUG-89023 Change-Id: I620d47ef6f519d59436fe096ccaa78216b23d98a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Blacklist testTransitionsWithImplicitFrom on Ubuntu 20.04Fabian Kosmale2020-12-011-0/+3
| | | | | | Task-number: QTBUG-89023 Change-Id: I76b3920de3cd933f573f1a800fe800a8d5413798 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Relax the timings on the new testTransitionWithImplicitFrom testRobert Griebl2020-11-301-6/+6
| | | | | Change-Id: Ie9fae8a7edb07c6df499a06fdc9d539e114b789e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Allow parent to filter out-of-bounds synth-mouse for grabbing handlerShawn Rutledge2020-11-305-40/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider Flickable { Text { TapHandler { gesturePolicy: TapHandler.ReleaseWithinBounds } } } On press, TapHandler gets the exclusive grab. Now drag vertically. The Text is short in stature, so your finger soon strays out of bounds of the Text, likely before you have dragged past the drag threshold. In this case, we want Flickable to continue to filter the move events because of the fact that TapHandler is the grabber. If it was a MouseArea instead of a TapHandler, it already worked that way; so this makes behavior of handlers more consistent with that. More specifically: QQuickPointerTouchEvent::touchEventForItem() now generates a touch event even if the touchpoint is not within the bounds of the given item, but is grabbed by one of that item's handlers. Until now, we had that exception only if it was grabbed by the item itself. tst_FlickableInterop::touchAndDragHandlerOnFlickable now always drags the delegate at index 2 (the third one) from its upper-right corner, upwards and to the left. The first drag goes outside the delegate's bounds, but the Flickable/ListView/TableView filters and takes over anyway (on the next drag), to prove that it is correctly depending on the grab that the TapHandler (or DragHandler) took on press. Pick-to: 5.15 Pick-to: 6.0 Fixes: QTBUG-75223 Change-Id: Ie4e22c87be0af9aa3ff0146067b7705949b15c40 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Speed up tst_FlickableInterop::touchAndDragHandlerOnFlickableShawn Rutledge2020-11-296-0/+54
| | | | | Change-Id: I9d01dc00c68979aa9288820fddaaa7b0208bec9b Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix Animators requiring an explicit from valueRobert Griebl2020-11-284-4/+142
| | | | | | | | | | | | | | | | | | | Contrary to the documentation, Animators have always had the requirement that an explicit from value was specified, which isn't very convenient e.g. in Transitions. This patch was tested against a (quite big) real world customer application using Qt 5.12 and Qt 5.15. Also a new unit test was added to test this feature. I couldn't find another way to access the actual AnimatorJob besides querying the window's AnimatorController, so I had to add an auto-test only export on that class. Task-number: QTBUG-66475 Pick-to: 6.0 6.0.0 Change-Id: Icc2a220a13f587d69594a4b2ed345abf0438e29e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Modernize the Animators auto test buildRobert Griebl2020-11-282-10/+12
| | | | | | | | | The pro file was adapted to the state of the qquickanimations one and the cmake part regenerated. Pick-to: 6.0 6.0.0 Change-Id: I5dbc2c985a84019e42c974468db4b8dc0fa3d210 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Correct height properties for QQuickText with reducing lineHeightReinhard Raschbauer2020-11-261-2/+16
| | | | | | | | | | | | | | | If the property lineHeight is used to reduce the line height, either by setting a proportional factor smaller 1.0 or a pixel size smaller than the font size, the offset calculated in lineHeightOffset is not taken in to account to calculate the height properties. But the offset is used to position the the rendered text. In the current implementation the property lineHeight does not have an effect on single line texts. This change takes that into account and adds lineHeightOffset to all height properties. Fixes: QTBUG-88229 Change-Id: Iab7d9b39a4c7876c7c95e43be6846623c10b0607 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Purge renderpass refs from renderer when redirecting via QRhiRtLaszlo Agocs2020-11-241-1/+32
| | | | | | | | Pick-to: 6.0 Fixes: QTBUG-88761 Change-Id: Ia5df65a4a09a7554a7d0cca4533f766cb5abe97b Reviewed-by: Miikka Heikkinen <miikka.heikkinen@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Attempt to stabilize tst_QQuickListView::sectionsSnapShawn Rutledge2020-11-242-4/+2
| | | | | | | | | | It only failed due to being in a "bad" sequence with other tests somehow. Fixing by reordering is lame, but I can't find the actual reason that it fails, so far. Task-number: QTBUG-86729 Change-Id: I8450c2e4b3119326c8518a526801cd10e933dca0 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix qmake build of tst_qquickview_extraAndrei Golubev2020-11-242-0/+4
| | | | | | | | | | While dev/6.0 uses CMake as a main build system, just in case we will run qmake tests in CI, make sure it works Leftover of 3a5617dc45e281552b9c1f7a04f0561b8fa14d94 Pick-to: 6.0 Change-Id: I32efba9140206f0dfb2e8458fe5c6a2d4d51dbc7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Don't deliver to non-grabbing pointerhandlers if a point is grabbedShawn Rutledge2020-11-231-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular, on press when QQuickFlickable::filterPointerEvent() calls captureDelayedPress() and will return true, it also accepts the event to stop propagation. It becomes the grabber as a consequence of that. On a future move event, when the drag threshold is exceeded while the delayed press timer is still running, Flickable already has the grab (but it accepts the event again), and QQuickFlickablePrivate::drag() calls setKeepMouseGrab(true). In this case we still want to prevent any children's DragHandlers from seeing the event, because a DragHandler will also see that the drag threshold was exceeded and try to steal the grab. A DragHandler can steal the grab only if there was no press delay: then it sees the initial press because Flickable does NOT stop event propagation (does not accept the event), so it can take a passive grab and continue to wait for the drag threshold to be exceeded, regardless of what else happens. In case of multiple touchpoints, allPointsGrabbed() returns false if the Flickable has only grabbed one point; but we want to avoid delivering handlers in children just on the basis of that grabbed touchpoint being within their bounds, even though other points may be delivered to various handlers. This fixes tst_FlickableInterop::touchAndDragHandlerOnFlickable. The blacklisting of dragHandlerInSiblingStealingGrabFromMouseAreaViaTouch was bogus (it's in the mousearea_interop test). Pick-to: 6.0 Task-number: QTBUG-86729 Change-Id: I9f0d42e97de4f4a3b4f7773800a8d59dc34a0553 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix QML property cache leaks of delegate itemsAndrei Golubev2020-11-235-0/+156
| | | | | | | | | | | | | | | | | | | | | The delegate items are destroyed through an event loop by a call to a deleteLater(). This, however, doesn't work when the application is in the process of exiting and the event loop is already closed (i.e. we're in a stack unwinding part that starts after app.exec()) Combat this situation by setting a parent of the to-be-deleted object to some QObject that will be destroyed e.g. QCoreApplication::instance() before the program finishes. As QObjects clean their children on destruction, this will make sure that we cleanup the previously leaking thing regardless of the event loop Added a test to check that delegates are destroyed (as a separate binary due to differences in main() function) Fixes: QTBUG-87228 Pick-to: 6.0 5.15 Change-Id: I59066603b77497fe4fd8d051798c3e4b47c119f0 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix multipointtoucharea_interop testsShawn Rutledge2020-11-232-19/+15
| | | | | | | | | | | | | | | | | | | | | | In several places these were doing stuff like touch.press(1, p1).commit(); QTRY_VERIFY(devPriv->pointById(0)->passiveGrabbers.contains(drag)); The point ID is really the key in activePoints, it doesn't necessarily start from 0; so pointById() has to be given the same point ID that was used in the event, otherwise it will construct a new point(0). But now tst_MptaInterop::touchesThenPinch fails further down: after the complicated series of events, when only one point is still being dragged, DragHandler fails to grab it and start dragging for some reason. dragHandlerInParentStealingGrabFromItem() uses mouse not touch. Pick-to: 6.0 Task-number: QTBUG-86729 Change-Id: I7ad0d3f30cb5fee15fe83183d62ee10a020c14df Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix tst_TapHandler::componentUserBehavioralOverrideShawn Rutledge2020-11-232-4/+2
| | | | | | | | | | | | | The QQuickPointerHandler::grabChanged() signal now has QEventPoint by value rather than by pointer (because it's a value type, whereas in Qt 5 it was a QObject). Amends a97759a336c597327cb82eebc9f45c793aec32c9 Pick-to: 6.0 Task-number: QTBUG-86729 Change-Id: I5514dc1b49a0b47276c41264e18f6a541bc2a3f0 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix tst_PointHandler::pressedMultipleButtonsShawn Rutledge2020-11-232-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | QQuickWindowPrivate::deliverPressOrReleaseEvent() calls QPointerEvent::clearPassiveGrabbers() for every QEventPoint that has the Pressed state. This is consistent with the idea that for every press (a different mouse button or a different touchpoint), we start over with event delivery so that different items and handlers can see what's going on and decide whether it's relevant for them. But QQuickPointerHandler::onGrabChanged() reacts with setActive(false). So for example if we press left mouse button, then keep holding it and press right mouse button, PointHandler changes its active state twice, because its passive grab was cleared and then we visit it again; it's still interested in tracking the mouse, so it takes another passive grab and becomes active again. Avoiding emitting activeStateChanged in this case would seem a bit contrived. As long as the release of one button doesn't make PointHandler completely lose interest prematurely, QTBUG-66360 can still be considered fixed, I think. Pick-to: 6.0 Task-number: QTBUG-66360 Task-number: QTBUG-86729 Change-Id: I132a8c5d1878769481b8afcc62ba237b4498b069 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix compiler warningsVolker Hilsheimer2020-11-231-15/+15
| | | | | | | | | | The bit flags in QAccessible::State are unsigned, numeric literals are signed, resulting in compiler warnings when comparing. Instead of QCOMPARE'ing bitflags that are used for booleans, use QVERIFY. Pick-to: 6.0 Change-Id: I9fd6906a8c1c1e356f8e6c5b36d40f6c41590ee8 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* tst_qquicktextinput: Do not construct illegal QCharFabian Kosmale2020-11-231-4/+17
| | | | | | | | | | | This change does the minimal amount of work to get the test to run without crashing due to triggering a QChar assert. Note that Key::toString does not check whether the QChar value it tries to construct is actually valid; but all values in the test case are. Fixes: QTBUG-88712 Change-Id: Ie484e66de46ad1d78573c31d90d40c99b8fd7caa Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Clean up and un-blacklist tst_QQuickMouseArea testsShawn Rutledge2020-11-202-436/+251
| | | | | | | | | | | | | | | | - Use QQuickTest::showView() consistently to reduce boilerplate - Use QTest::mouse*() where possible rather than constructing QMouseEvents (and potentially getting them wrong) - Use QPointingDevicePrivate::firstPointExclusiveGrabber() on a specific device to check grab state rather than QQWindow::mouseGrabberItem() - The warning "event went missing during delivery!" has been removed, so tst_QQuickMouseArea::nestedEventDelivery() shouldn't expect it Pick-to: 6.0 Pick-to: 6.0.0 Task-number: QTBUG-86729 Change-Id: Ieb1af38c118dadf8cdf8ae19f92002207d71d5b5 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Un-blacklist tests that grafana says are passingShawn Rutledge2020-11-202-6/+0
| | | | | | | | | | | canvas::test_implicitlySizedParent tst_qquicktext::dependentImplicitSizes Task-number: QTBUG-41043 Task-number: QTBUG-75786 Task-number: QTBUG-76608 Change-Id: Id90669e58eac4cbe1a3b73406641a8e42f9523b1 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tests: blacklist tst_QQuickGridView::snapToRow() and snapOneRow() on MSVCLiang Qi2020-11-201-0/+3
| | | | | | Task-number: QTBUG-88644 Change-Id: I363763788b53b0722f680599c08e17d0cb40fcac Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
* tests: blacklist tst_qquicktext::contentSize() on MSVCLiang Qi2020-11-201-0/+1
| | | | | | Task-number: QTBUG-88646 Change-Id: Ia37fc8c4f5c0e56eeaef4f8f82974ee749dd74fc Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
* QML Text doesn't reset lineCount when text is emptyShinichi Okada2020-11-201-0/+37
| | | | | | | | | | | lineCount is not reset when replacing a multi-line QML Text 'text' property with an "" empty string. Also, the lineCountChanged signal is not emitted Pick-to: 5.15 Task-number: QTBUG-84458 Change-Id: Ic3c02e6a90e6675eadbaafc6af6ab0356ee98123 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix tst_QQuickMouseArea::notPressedAfterStolenGrab againShawn Rutledge2020-11-193-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Most of the time, QQuickWindowPrivate::deliverMatchingPointsToItem() doesn't need to call item->mouseUngrabEvent() because all grab changes are notified via the connection from signal QPointingDevice::grabChanged to slot QQuickWindowPrivate::onGrabChanged(). But in this case, MouseArea only accepts the event, rather than taking the grab itself. Therefore at the time the grab is "stolen", there was not yet any grabber, because grabbing is done after delivery. But we still need to inform MouseArea that it's not getting the grab it expects to get, so that it can reset its pressed state. But we don't want it to be redundant (other tests are counting events, and we don't want repeated ungrabs to show up in those); so now we have to track whether the item on which we're about to call mouseUngrabEvent() has already gotten it. This illustrates another problem with the tradition of accepting events and being unclear about what it means. Grabbing is one thing, ending delivery is another. Amends a97759a336c597327cb82eebc9f45c793aec32c9 Task-number: QTBUG-55325 Task-number: QTBUG-86729 Change-Id: I8150f901e00e7a71499fc98ab54f0ba75370f3ec Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Stop ungrabbing due to FocusAboutToChangeShawn Rutledge2020-11-181-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* tst_ma::pressedCanceledOnWindowDeactivate: don't pop up second windowShawn Rutledge2020-11-182-13/+2
| | | | | | | | | | | | | | I guess I must have thought it would be more realistic that way; but sending an explicit WindowDeactivate as we had it in early Qt 5 seems to keep the test passing now, and is probably more reliable. The original purpose of the test seems to be to verify the recursive delivery to all items via virtual QQuickItem::windowDeactivateEvent(), which MouseArea (and no other item!) overrides to ungrab the mouse. This mostly reverts commit 1c451b40aee66a38ca3d61e5beec4ae8c986c8ed. Change-Id: I0c6f953514095a491120a0aac9944dc8b04ca17d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Use metatype and remove unused variableDavid Skoland2020-11-182-4/+1
| | | | | Change-Id: I709c6a74dc6a3eb0cdd3e94168921274f90df4a4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix tests that used out-of-context mouse grabsShawn Rutledge2020-11-173-9/+8
| | | | | | | | | | QQuickItem::grabMouse() is deprecated, and cannot be used at all when there is no current event being delivered. But we can still use QPointingDevicePrivate::setExclusiveGrabber(). Task-number: QTBUG-86729 Change-Id: I215de471e6dc44551720bc4c766b22cdfee94423 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Clean up tst_TouchMouseShawn Rutledge2020-11-171-424/+358
| | | | | | | | | | - The view-showing boilerplate is reduced - Uncommented and fixed up some statements that were failing at one time - Fixed override warnings - Use qCDebug not qDebug Change-Id: Ib437cc985c03776492da2502ecdb5176afadadf2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add QQuickTest::showView(); give QQuickTest::initView() default argsShawn Rutledge2020-11-172-13/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now the boilerplate for most QML-using C++ tests can be reduced from QQuickView window; QByteArray errorMessage; QVERIFY2(QQuickTest::initView(window, testFileUrl("myitems.qml"), true, &errorMessage), errorMessage.constData()); window.show(); QVERIFY(QTest::qWaitForWindowExposed(&window)); QVERIFY(window.rootObject() != nullptr); to QQuickView window; QVERIFY(QQuickTest::showView(window, testFileUrl("myitems.qml"))); The idea to dump the QML error output was nice, but the engine already generates QWARN output like this (lines partially wrapped, URL elided for brevity): QWARN : tst_TouchMouse::touchPointDeliveryOrder() [ 0.000 W] default unknown - file:/...rder.qml:14:29: Cannot assign to non-existent property "pill" Rectangle { anchors.pill: parent; color: "lightsteelblue" } ^ FAIL! : tst_TouchMouse::touchPointDeliveryOrder() 'QQuickTest::showView(window, testFileUrl("touchpointdeliveryorder.qml"))' returned FALSE. () Loc: [/home/rutledge/dev/qt6/qtdeclarative/tests/auto/quick/touchmouse/tst_touchmouse.cpp(1343)] Improves on a804f31ee2665501c1894cbae8302db181090bd5 Change-Id: I92b8e3720bb5b1d009580bb74566690ad3d5292c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* When Flickable filters UngrabMouse, react as if it was ungrabbed itselfShawn Rutledge2020-11-171-2/+0
| | | | | | | | | | | | | | | | | | | | | Fixes tst_QQuickListView::touchCancel again. In this scenario, a TouchCancel is sent, but gets turned into an UngrabMouse for delivery to the MouseArea which is the current grabber. We try to avoid calling QQuickWindow::mouseGrabberItem() because it's too vague a question to ask (which mouse? or did you mean the synth-mouse during synthesis from a touch or tablet event?); and now it acts different anyway, because eventsInDelivery.top() is an UngrabMouse, which did not include a pointer to the QPointingDevice until now. So now we turn the UngrabMouse event into a QSinglePointEvent so that it's possible to get exclusiveGrabber() and check that the grabber is not the same Flickable. (Otherwise, the grabber that's getting ungrabbed is usually the child receiver item sent to childMouseEventFilter().) Task-number: QTBUG-86729 Task-number: QTBUG-74679 Change-Id: I6dfd96686bdfb54723bbe093406b6ab1f75de855 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add tst_qquickflickable::parallelTouchShawn Rutledge2020-11-172-0/+110
| | | | | | | | | | | Prove that we can drag multiple Flickables with multiple touchpoints now. [ChangeLog][QtQuick][Flickable] Flickable now handles touch events directly: you can now drag multiple Flickables with multiple touchpoints. Fixes: QTBUG-30840 Change-Id: I0a3e58595a67f5afb4b93ad64d5280cb3fc52f7a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Add tst_qquicktextedit::inFlickable testsShawn Rutledge2020-11-172-0/+126
| | | | | | Task-number: QTBUG-88169 Change-Id: Iaea3959365a580f3f8d2dd7ab2b227933e79cf59 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix incorrect assumptions with Metal in tst_qquickwindowLaszlo Agocs2020-11-171-4/+8
| | | | | | | | | Two cases fail due to attempting to query the MTLRenderCommandEncoder in a state where QRhi::beginPass() was not yet called. This is invalid and we should not test for it either. Change-Id: Ieaaaabd275db68be98365fb76a39f30a635d3543 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Don't synthesize mouse from touch for items that accept touchShawn Rutledge2020-11-175-146/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Followup to 1457df74f4c1d770e1e820de8cd082be1bd2489e : if an item that has acceptTouchEvents() == true merely fails to accept one touch event, that does not mean a mouse event should be sent. Finish changing the default to false: handling touch events is opt-in, just like handling mouse events; most items don't. And if you opt in, then you MUST handle touch events, because you will NOT receive mouse events as a fall-back. Now that Flickable handles touch, filtering multi-touch events becomes relevant. There was a failure in tst_touchmouse::mouseOnFlickableOnPinch when Flickable grabs a stationary touchpoint at the same time as another touchpoint is pressed, preventing a child PinchArea from reacting. So there's a new rule: just as we start over with event delivery when a new point is pressed, QQuickFlickable::filterPointerEvent() should also not immediately grab when any point is newly pressed; it can afford to wait, because it's filtering, so it will be able to see if one point is dragged past the drag threshold later on. When a parent (such as Flickable) contains only mouse-handling items (such as MouseArea), the parent should filter the touch event if it is able (if acceptTouchEvents() returns true). Flickable is now able to. Filtering parents that are not able to filter touch events can still filter a synth-mouse event as before. But filtering both must be avoided: then we would have the problem that Flickable filters a touch move, sees that it's being dragged past the drag threshold, and sets d->stealMouse to true to indicate that it wants to steal the _next_ event; then it filters a synth-mouse move, and that's perceived as being the next event even though it's just a different view of the same event, so it steals it. In tst_qquickflickable::nestedMouseAreaUsingTouch we rely on the delay caused by waiting for the next event: the MouseArea is trying to drag an item and the Flickable wants to flick; both of them decide on the same event that the drag threshold is exceeded. But MouseArea calls setKeepMouseGrab() immediately, whereas Flickable doesn't try to steal the grab until the next event, and then it sees the keepMouseGrab flag has been set, so it doesn't do it. If Flickable could filter the same event twice (once as touch, once as synth-mouse), this logic doesn't work, so it's effectively "more grabby" than intended. So it works better to have it filter only the actual touch event, not the synth-mouse that comes after. When the child has pointer handlers, we need to visit them, and therefore we should let Flickable filter a touch event on the way. tst_FlickableInterop::touchDragFlickableBehindButton() depends on this. [ChangeLog][QtQuick][QQuickWindow] In Qt 6, a QQuickItem subclass must explicitly call setAcceptTouchEvents(true) to receive QTouchEvents, and then it must handle them: we no longer fall back to sending a QMouseEvent if the touch event is not accepted. If it has additionally called setFiltersChildMouseEvents(true), then it will filter touch events, not any synthetic mouse events that may be needed for some children. Task-number: QTBUG-87018 Fixes: QTBUG-88169 Change-Id: I8784fe097198c99c754c4ebe205bef8fe490f6f4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Stabilize tst_QQuickMultiPointTouchArea::inFlickableWithPressDelayShawn Rutledge2020-11-161-9/+17
| | | | | | | | Flickable moves after taking over the grab, but this test was failing anyway. Might as well check for everything in one loop of move events. Change-Id: Iafa21cdfb88df36337e4350934d3bf569418bdca Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Blacklist tst_qquickpointhander::tabletStylus on macOSShawn Rutledge2020-11-161-0/+2
| | | | | | Task-number: QTBUG-88541 Change-Id: I35b3f99c4268b6615da373f90b53b6ca6ef16fce Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Don't copy or assign QEvent instances in testsVolker Hilsheimer2020-11-164-570/+756
| | | | | | | | | | | | | | | Copying/assigning polymorphic types is a code smell, use separate instances instead in the tests. Those should perhaps be rewritten to use a data driven testing approach, there's a lot of code repetition. In the test API implementation, first evaluate the parameters for the event, then construct the event once with the correct values. Change-Id: I2572772698cb0204f5ff950741b9fe3805fae15d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickViewTestUtil: mark QAIM method overridesShawn Rutledge2020-11-121-6/+6
| | | | | | | | Fixes a few -Wsuggest-override warnings with gcc 10.2 (but there are more). Change-Id: I36c29c6f2dc1577a05514950ce1a6b3a24da4f55 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: David Skoland <david.skoland@qt.io>
* Fix QQWinPriv::deliverSinglePointEventUntilAccepted for wheel, gesturesShawn Rutledge2020-11-121-3/+0
| | | | | | | | | | | | | | | | | | | | | | WheelHandler was only reacting to one wheel event between mouse moves, because it got added to the QQPointerHandlerPriv::deviceDeliveryTargets() vector, and was not removed at the beginning of delivery of subsequent events, as QQuickWindowPrivate::deliverPointerEvent() does. (In Qt 5 the equivalent vector was cleared in QQuickPointerMouseEvent::reset().) Wheel events are delivered via deliverSinglePointEventUntilAccepted() (grabbing the wheel is still not implemented). Native gesture events are delivered that way too; and sure enough, the same bug happens on the macOS trackpad, whether you are attempting to do pinch zoom or just two-finger-flick. tst_QQuickWheelHandler::nestedHandler() sends multiple wheel events in a row, so we do have some test coverage, and hopefully this issue explains why it needed to be blacklisted. Fixes: QTBUG-88428 Task-number: QTBUG-86729 Change-Id: Id1ed4a38dfa3eb2253c4a60f09f80aea0f69707e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Mostly un-blacklist Flickable and MultiPointTouchArea testsShawn Rutledge2020-11-112-25/+2
| | | | | | | | At least they pass again locally. Ubuntu is being problematic still. Task-number: QTBUG-86729 Change-Id: I3085b4070475f52f6e1f37b8455429a5bad08177 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* blacklist tst_QQuickListView::sectionsSnap in CI on macOSShawn Rutledge2020-11-111-0/+2
| | | | | | Task-number: QTBUG-86729 Change-Id: I38048b9b76de5356d50cf0313a06c3fbb3b35d89 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-20 02:23:57 +0000