aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/quick/pointerhandlers
Commit message (Collapse)AuthorAgeFilesLines
* tst_HoverHandler::window: Place window away from menu bar on macOSTor Arne Vestbø2025-11-251-1/+1
| | | | | | Pick-to: 6.10 6.8 6.5 Change-Id: I783d368dc9dffd20dad4b238e55d26da57d11d7b Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Fix QQuickItemPrivate::eventHandlingBounds()Shawn Rutledge2025-11-192-1/+5
| | | | | | | | | | The second two arguments are width and height, not bottom-right coordinates. So after shifting the rectangle left and upwards, we need to add twice the margin to width and height, to have the same margin all the way around. Amends 8115731466b579f33295d5c8a71506475750284e Change-Id: I83797ffd460ee47599170090aefcda544c3e4483 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Add effectivelyClipsEventHandlingChildren; skip event delivery when irrelevantShawn Rutledge2025-11-172-2/+287
| | | | | | | | | | | | | | | If a QEventPoint is clearly outside an item _and_ the bounds of all its children, or is simply outside the bounds of an item that clips its children, we can stop recursion, for purposes of QPointerEvent delivery, finding which items/handlers are hovered, or which could control the cursor shape. effectivelyClipsEventHandlingChildren() is also recursive, but at least the result gets cached. Task-number: QTBUG-140340 Task-number: QTBUG-115179 Change-Id: I085e38964de6993fa82ad3bd1256868125fde090 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* tst_HoverHandler::movingItemWithHoverHandler: check cursor changeShawn Rutledge2025-11-152-1/+2
| | | | | | | | | | | If an item with a HoverHandler with cursorShape moves under the mouse cursor, flushFrameSynchronousEvents() should cause the cursor to change shape, along with hovering the item. Amends cd7c5f94a0ed64c52d31998957134d099313932a Task-number: QTBUG-53987 Change-Id: I0fc3b093ac5377fd81205c6f50498bd8f817aa51 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Stabilize tst_HoverHandler::movingItemWithHoverHandlerShawn Rutledge2025-11-062-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | We know QCursor::setPos() doesn't work on Wayland; but let's detect when it doesn't work, at runtime, and skip the rest of the test. The reason for the change 1c7213dbc00fa595aeaa98ad5631bac56782599e was that if there is no mouse, or if it never moves, QGuiApplicationPrivate::lastCursorPosition might not have changed from its initial offscreen position. So that's why this test does not send any explicit mouse moves. But the window should receive an Enter event, and QGuiAppPrivate::processEnterEvent() should set lastCursorPosition. If that also didn't happen after showing the window with the cursor above it, it's not Qt Quick's problem. flushFrameSynchronousEvents() may not be able to hover and un-hover the moving item if it doesn't know where the cursor is. If you have no mouse, the item can't be hovered anyway (except that we might fake it with the touchmouse, but that is not being tested here). Fixes: QTBUG-76312 Fixes: QTBUG-81884 Fixes: QTBUG-103065 Fixes: QTBUG-111294 Change-Id: I76512ccf717385f32fe123b7c6898bff4eb17385 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Blacklist tst_HoverHandler::twoHandlersTwoTouches for now; rearrangeShawn Rutledge2025-10-232-1/+5
| | | | | | | | | | | | | So when we touch-press the right HoverHandler, the left stays hovered sometimes. Hmm. Let's check the right one first, and see if that's also flaky. Subsequent hover patches may affect behavior here: that's what we are checking for. Task-number: QTBUG-141430 Change-Id: I10709cc454f25be91159c520a385603de7067acf Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Add tst_HoverHandler::twoHandlersTwoTouchesShawn Rutledge2025-10-212-0/+70
| | | | | | | | | | | | | | | | | | | | Clarify that the touch-hover behavior doesn't depend on touch->mouse synthesis. We started faking hover on touchscreens because MouseArea can handle synth-mouse events coming from touchscreens, so containsMouse was reacting to touchpoints: then QTBUG-40856 came along, and the fix for it cemented some rules in place. Then HoverHandler was added, and it was deemed reasonable to get similar behavior, even though it handles touch events directly: if your fingertip is touching, then the rest of your finger is hovering (just as the mouse cursor is hovering at the same time that the mouse button is pressed). In this test case, HoverHandler directly handles touch events, and there is no touchmouse. So far, we still have Qt 5 behavior: HoverHandler is a single-point handler, and if you try to press two of them with two fingers, the first one "wins". But this might need to change later, to support multi-finger hover. Task-number: QTBUG-40856 Change-Id: If46d766d80534d729d254ca12ed1069c1d94e7a4 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* tst_HoverHandler::touchDrag: QCOMPARE(QPoint, QPoint)Shawn Rutledge2025-10-211-2/+2
| | | | | | | | | QCOMPARE(QPointF, QPoint) requires too much precision: it can fail by a fractional pixel. Amends ff4c2c311f1957ebacb66f0d35406a51da2a544e Pick-to: 6.10 6.8 Change-Id: Icdcc895e855ea305090d1d4863b7c0f078922427 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tst_HoverHandler::deviceCursor: more feedback about hovered stateShawn Rutledge2025-10-172-0/+38
| | | | | | | | | See which HoverHandlers are hovered when testing by hand, even if cursor-changing is buggy. Also check the mouse HoverHandlers after sending a QTabletEvent. Change-Id: I7ffa165235eaa8ac726733a27de728ef9a88a7c4 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tst_qquickhoverhandler::asProperty(): remove redundant codeOliver Eftevaag2025-10-151-2/+0
| | | | | | | | | QQuickTest::showView() already ensures that a window becomes visible. We don't need to repeat that manually in the test after calling it. Pick-to: 6.10 Change-Id: Id8cadeb619544ee7b871fdff98f4b93a8a0c52ed Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* DeliveryAgent: stop sending hovering mouse moves to grabberShawn Rutledge2025-08-133-11/+72
| | | | | | | | | | | | | | | | | | | | For applications running under Qt Wayland compositors, touch events may be accompanied by fake mouse moves coming from the touchscreen device. That might or might not be useful: but since most of Qt Quick ignores such stray mouse moves, and PinchHandler was getting deactivated by them, we now make an effort to avoid delivering them to PinchHandler after it has become the exclusive grabber of those touchpoints (which looks the same as being the grabber of "that" mouse). Added a reminder to the handlePointerEvent() comment that tablet events are different: hover events are not enough, in fact we need to deliver TabletMove events to HoverHandler so that it has a chance to change the cursor (i.e. keep the tst_HoverHandler::deviceCursor test working). Pick-to: 6.8 6.9 6.10 Fixes: QTBUG-123985 Change-Id: I513caf277e2fb87401b3e0bb5547f9623467b423 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* PointerHandler: Add handler to parent also on componentComplete()Oliver Eftevaag2025-07-182-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | It was possible for a handler to not be added to its parent item via data_append() when the handler is created as a property binding: ``` Item { id: parentItem property HoverHandler handler: HoverHandler { parent: parentItem } } ``` In that case, the HoverHandler won't be added to the parent item's default list property (data), since it's being assigned to a different property instead (handler). data_append() was the main way that pointer handlers installed themselves to items, but it is skipped in this case. Now we also call QQuickItemPrivate::addPointerHandler() in componentComplete() if the pointer handler was not already added. Pick-to: 6.10 Change-Id: I5c797f6abcfb19af7e897354fba39dd536e66140 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix flaky dragHandlerInSiblingStealingGrabFromMouseAreaViaTouchFrédéric Lefebvre2025-07-081-0/+4
| | | | | | | | | | | | tst_MouseAreaInterop:: dragHandlerInSiblingStealingGrabFromMouseAreaViaTouch exhibits occasional flakiness on openSuSE 15.6. Fix the flakiness on openSUSE 15.6 Pick-to: 6.10 6.9 6.8 6.5 Change-Id: I823b522b54710e34788b718aa9f0a22254981f5c Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Fix flaky dragHandlerInSiblingStealingGrabFromMouseAreaViaMouseFrédéric Lefebvre2025-07-082-3/+4
| | | | | | | | | | | | tst_MouseAreaInterop:: dragHandlerInSiblingStealingGrabFromMouseAreaViaMouse is flaky on openSuSE 15.6 and is blacklisted on that platform. Fix flakiness on openSuSE and unblacklist the test. Pick-to: 6.10 6.9 6.8 6.5 Change-Id: I1f0c8935a1b95d773cf5364ec4eba0c20918d41b Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Only activate DragHandler if drag starts within itShawn Rutledge2025-06-241-0/+28
| | | | | | | | | | | | | | Previously, starting a mouse drag outside a DragHandler's parent and moving inside would activate it. This is unexpected behavior, inconsistent with touch behavior, and might interfere with other drags, so we only activate a DragHandler if at least one point was pressed inside the parent. Pick-to: 6.10 6.9 6.8 Fixes: QTBUG-127863 Change-Id: I2215636397ce9fc6a29b9a35165507e5b8d886f4 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Add PinchHandler and DragHandler 2-finger inside/outside testsShawn Rutledge2025-06-203-0/+151
| | | | | | | | | | | | | | | | | These should already behave the same with much-older Qt versions: so far, multi-point handlers require all points to be pressed inside the parent Item. Although DragHandler has long supported setting minimumPointCount to require more than one finger, we didn't have test coverage for that. So far the main "real" use case is the 2-finger tilt gesture in maps (in which case target is null), but it can also be used for dragging a target with more than one finger. Pick-to: 6.10 6.9 6.8 Task-number: QTBUG-127863 Change-Id: I2d4734f12a31a4b720bd11c05a61bc0cdc3b84ce Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Set flag FramelessWindowHint to tst_mouseAreaInterop::createViewFrédéric Lefebvre2025-06-171-0/+1
| | | | | | | | | | Set the FramelessWindowHint flag to tst_mouseAreaInterop::createview. Removes flakiness from tst_mouseAreaInterop::dragHandlerInSiblingGrabFromMouseAreaViaMouse. Pick-to: 6.10 6.9 6.8 6.5 Change-Id: I2cdbc9701a9e463bcf0a5f326df5726deb8fa093 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Map DragHandler delta to the sceneAleksandr Timofeev2025-05-152-0/+117
| | | | | | | | | | | | | Previously, DragHandler didn't account for scene transforms when calculating drag threshold. In the case when one axis is disabled, and the scene is rotated 90 degrees, the remaining axis should be activated by movements that are nominally the same as the disabled direction, because of rotation. Fixes: QTBUG-136354 Pick-to: 6.8 6.9 Change-Id: I6669949908b0d026850411c10056685648a109d9 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tests: do not leak QPointingDevice instancesShawn Rutledge2025-05-106-121/+119
| | | | | | | | | QTest::createTouchDevice() passes ownership of the device to the caller, so make sure it gets deleted. Pick-to: 6.8 6.9 Change-Id: I1289def6b40bf688a7334b9997f7e4319516d018 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Unblacklist tst_flickableinterop::pinchHandlerOnFlickable on openSUSEFrédéric Lefebvre2025-05-081-4/+0
| | | | | | | | | tst_flickableinterop::pinchHandlerOnFlickable is no longer flaky on openSUSE Pick-to: 6.9 6.8 6.5 Change-Id: Ib700766612f0b29c39be12ef2d5b6d8f50665579 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* DeliveryAgent: clear deviceDeliveryTargets before hover deliveryShawn Rutledge2025-04-161-0/+11
| | | | | | | | | | | | | | | | deliverPointerEvent() and deliverSinglePointEventUntilAccepted() already clear the QQuickPointingDeviceExtra::deliveryTargets list before each event delivery (since a97759a336c597327cb82eebc9f45c793aec32c9 and 262d7eb305e1dea8dac660bec3ccc50193258ea9). deliverHoverEvent() needs to do that too: in case there are a lot of hover delivery targets and the user doesn't move the mouse for a long time, but the scene is continuously updated, flushFrameSynchronousEvents() keeps sending hover events, and this list would keep growing if we don't clear it each time. Fixes: QTBUG-135975 Pick-to: 6.5 6.8 6.8.3 6.9 Change-Id: Ia91e3c977b45fc964228d3aad89938435f437449 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Tests: include QTest, not QtTestGiuseppe D'Angelo2025-04-1510-10/+17
| | | | | | | | | | | | | Never use module-wide inclusions. They blow up build times. For QtTest this is usually just a typo (QTest was meant instead). Add missing includes as needed. In the diffs I've spotted other huge inclusions (QtQuick, QtQml), but those need more attention. Task-number: QTQAINFRA-7110 Pick-to: 6.9 6.8 Change-Id: I74bf3fe212f50a7a3a6af2b1c80bbcaabc2516d7 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* tests: Swap QScopedPointer<QPointingDevice> for unique_ptr touchscreenShawn Rutledge2025-03-293-36/+35
| | | | | | | | | | | | The default device from QTest::createTouchDevice() is a touchscreen, so we should call it that, to disambiguate touchpads (a few tests use them). And QScopedPointer is discouraged nowadays. Task-number: QTBUG-132212 Pick-to: 6.8 6.9 Change-Id: I2aeaf8cee3c7b6041945506e11fa62d7c923c556 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io> Reviewed-by: Frederic Lefebvre <frederic.lefebvre@qt.io>
* Set fix position tst_QQuickHoverHandler::window to fix flakinessFrédéric Lefebvre2025-03-262-3/+3
| | | | | | | | | | | | | | | | tst_QQuickHoverHandler::window() is flaky on Opensuse, where the cursor is not hovering the window when it is failing. Set fix position to the window for the cursor to always hover at the right position. Unblacklist tst_QQuickHoverHandler::window() on Opensuse as it is no longer flaky. Fixes: QTBUG-122405 Pick-to: 6.9 6.8 6.5 Change-Id: I0c78e80d19c59e95d58765ce2f6e201121e14236 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Unblacklist dragHandlerInSiblingStealingGrabFromMouseAreaViaTouchFrédéric Lefebvre2025-03-251-4/+0
| | | | | | | | | Unblacklist tst_mouseareaInterop:: dragHandlerInSiblingStealingGrabFromMouseAreaViaTouch() on Opensuse as no longer flaky. Change-Id: I217766fa89e7bf85fba0e4bab6b5ddfdad4d41a6 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Unblacklist several tests from tst_flickableInterop on OpensuseFrédéric Lefebvre2025-03-252-13/+1
| | | | | | | | | | | | | | | Several tests in tst_flickableInterop are flaky on Opensuse due to asynchronicity when showing a quickview. Set the FramelessWindowHint flag in createView() to fix this flakiness. Unblacklist touchAndDragHandlerOnFlickable(), mouseDragSlider(), touchDragFlickableBehindButton(), mouseClickButton(), mouseDragFlickableBehindSlider() as no longer flaky. Fixes: QTBUG-95887 Pick-to: 6.9 6.8 6.5 Change-Id: Id24050fb2458868de88468378f8ec6f2e5ca8c07 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Unblacklist nativeGesturePinchOnFlickableWithParentTapHandler OpensuseFrédéric Lefebvre2025-03-251-3/+0
| | | | | | | | | Unblacklist tst_flickableInterop:: nativeGesturePinchOnFlickableWithParentTapHandler on Opensuse as it is no longer flaky. Change-Id: I62638910a979a8f8075f5e2dec1436551fae7cc8 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Ensure TapHandler.pressed==false when deactivated; tolerate null eventShawn Rutledge2025-03-061-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dating back at least to 507efe5a8a2390813fb620a91b0b3b6b383f599d the initial plan was that an ungrab calls setActive(false), and that ought to be enough, because every pointer handler can react to deactivation in its own way. But QQuickTapHandler did not override onActiveChanged(); and it would still not work very well to do that, because setPressed() takes various arguments that are not available in onActiveChanged(). So an odd state of dubious utility was possible: it could be inactive and pressed at the same time. That's now prevented, as long as TapHandler relies on an exclusive grab. If a TapHandler's window is deactivated while it has an exclusive grab, onGrabChanged() is called with a null event, because the deactivation event is not a pointer event. Don't crash, and don't get stuck in pressed state either. Currently in this scenario, the grab transition is UngrabExclusive, not CancelGrabExclusive. If we are sure that a TapHandler should no longer be pressed if its window is no longer active, and one symptom is that it's ungrabbed, probably it makes sense to be consistent that when it loses any kind of grab that it has taken, it should no longer be pressed. But then we would run into the issue with the null event as described above. So these changes are best done together. If a TapHandler's window is deactivated while it has a passive grab, the TapHandler cannot be deactivated or un-pressed, because it is not in active state in the first place. (As documented, `active` means it has an exclusive grab.) Fixes: QTBUG-118454 Fixes: QTBUG-124777 Change-Id: I855a0e0ddcb13866af5501f6164b6b18b41dda2a Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* tst_qquickpointerhandler: fix warning about mismatched enums; ctor castsShawn Rutledge2025-02-241-13/+13
| | | | | | | | | | | | | | | | | | | | | | | The GrabTransition enum has no "none" value: there's no reason we need one for public API. But this test records events and transitions, and needs a way to record that no grab transition happened. It's just an int anyway, so QCOMPARE_EVENT simply casts it before comparison; and in any ternary-if expression using NoGrab, we cast both arms to int. The warning was warning: enumerated mismatch in conditional expression: ‘<unnamed enum>’ vs ‘QPointingDevice::GrabTransition’ [-Wenum-compare] 549 | QEventPoint::State::Pressed, itemIgnoreMouse ? NoGrab : QPointingDevice::GrabExclusive); | ^ Next, there is -Wint-in-bool-context: fixed by surrounding the ternary if's with parentheses. Replace C-style with constructor-style casts while we're at it. Change-Id: I0796abc8e19c1842a6b2f4e343d566ff0cc226e6 Reviewed-by: Matthias Rauter <matthias.rauter@qt.io>
* Set window position to fix tst_TapHandler::longPress flakinessFrédéric Lefebvre2025-01-132-4/+5
| | | | | | | | | | | | | | | | | | | | | | | tst_QQuickTaphandler::longPress() was flaky due to a qquickview with a non-fixed position. When failing the mouse event was not received by the button. The change in position of the qquickview caused the mouse event to sometimes be done higher than it should. The frame position was given instead of the position of the widget itself, causing the issue. Give a fix position and verify it with QTRY_COMPARE to ensure that the position of the widget is correct and that the mouse event will be delivered on the button. Remove tst_QQuickTaphandler::longPress() from blacklisted test as it is not flaky anymore. Fix flakiness on Opensuse Fixes: QTBUG-132628 Change-Id: Ie1aba47e16377c2e8b3bab109d356708797001cc Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Blacklist tst_taphandler::longPress on opensuseUlf Hermann2025-01-081-0/+4
| | | | | | Task-number: QTBUG-132628 Change-Id: Ia6f7c2697b7daf48e991960d2f394198f0d94b2b Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Blacklist tst_FlickableInterop::pinchHandlerOnFlickableFabian Kosmale2024-12-071-0/+3
| | | | | | | | | | | | | | | | We're seeing again an increase of failures in the test (including BFAIL in some of the other test functions). The corresponding bug has been closed as "Won't Do" which is probably correct in the sense that this might need more work on QQuickTouchUtils/Testlib instead of on the test side. That doesn't change the fact that the test currenlty causes failed integrations, bo blacklist it for now. Task-number: QTBUG-95887 Change-Id: Ie9afcc34598c485679c02b3f29bf34b9f94dff51 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* PinchHandler: Set target properties only if respective axis enabledVladimir Belyavsky2024-10-261-29/+67
| | | | | | | | | | | If the user has disabled the rotation or scale axis, the target item's rotation or scale property must not be set at all, to avoid breaking bindings that were set differently. Fixes: QTBUG-130517 Pick-to: 6.8 6.5 Change-Id: I8f84f6845532f748bbdcc3af91a398d6659156ca Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Add Qt::Qml before Qt::QmlPrivate to auto testsKarim Pinter2024-10-2210-0/+10
| | | | | | | | | | The build for auto tests for VxWorks fails because Qt::Qml is not added before Qt::QmlPrivate resulting in many unresolved symbols from Qt::Qml library. When Qt::Qml is added before it solves this problem. Task-number: QTBUG-129113 Change-Id: I89d553ac1d6706e2e934665fed2f308e6b01ed78 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Stabilize tst_PointHandler::tabletStylus()Shawn Rutledge2024-10-211-15/+19
| | | | | | | | | | | | | - QQuickTest::showView() calls QCursor::setPos() (when possible) to move the mouse outside the window, so that PointHandler won't deactivate because of stray mouse events - call QWindowSystemInterface::handleTabletEvent() with an explicit timestamp to ensure valid velocity calculation during delivery of the second tablet event Fixes: QTBUG-129943 Change-Id: Ib89e92195dd7ab41e6409c95c77b291ae98848ea Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* tst_MptaInterop: replace Q(TRY)VERIFY with comparative test functionsShawn Rutledge2024-10-201-6/+6
| | | | | | | | | | When these fail, we'll get more information in CI logs. Pick-to: 6.8 6.5 Task-number: QTBUG-118062 Task-number: QTBUG-123499 Change-Id: I90cdb466ca29bf955c45d3918be429e5d4d86d1b Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* PointHandler: don't deactivate because of synth-mouse eventsShawn Rutledge2024-10-082-8/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is necessary after 0b7ee7a48f5f32fc916cc1914b110bdf68e37486. If QQuickPointHandler::wantsEventPoint() ever returns false, QQuickPointerHandler::handlePointerEvent() calls setActive(false). If AA_SynthesizeMouseForUnhandledTabletEvents is enabled, and PointHandler is the only handler trying to handle tablet events, it does not accept the events; so QGuiApplicationPrivate::processTabletEvent() sends a synth-mouse press for each tablet press. If the position doesn't match the last-known mouse position, QGuiAppPriv::processMouseEvent() sends a synth-mouse move, too. PointHandler doesn't care about either of these synth-mouse events, but it has to say that it "wants" them to avoid getting deactivated. But in spite of that, we don't want QQuickSinglePointHandler::handlePointerEventImpl() to call QQuickHandlerPoint::reset() with those synth-mouse events, because then the tablet-specific data from the previous QTabletEvent would get overwritten. In general, pointer handlers handle original device-specific events only, and we just have to avoid letting these synth-mouse events interfere. There were a couple of places that were assuming that if an event is not a QTouchEvent, then it's safe to cast it to QSinglePointEvent; that's usually true, but isSinglePointEvent() exists since qtbase 9a1a15b42fb526ad4f80944afb7761bfff1b5c9d so we might as well use it. Previously, we'd set acceptedButtons: Qt.LeftButton | Qt.RightButton to indicate that the PointHandler should respond to either one; but now it's better to set Qt.NoButton to indicate that it doesn't care. The synth-mouse move has no buttons set; if PointHandler only "wants" events with specific buttons, that buttonless move will deactivate it temporarily, and then the synth-mouse move would re-activate it, causing extra activeChanged and pointChanged signals. But so far, its default for acceptedButtons is still Qt.LeftButton. Perhaps we should change it. The special meaning in QQPointerDeviceHandler::wantsPointerEvent() for Qt.NoButton started already with HoverHandler in 1982d1b1aa55ae44a1a775a5745e5c2f11001398 and then fc636af3a723ee8b4ee42cf71864ae0df5ca4621 for PinchHandler. Those handlers fundamentally don't need to care about buttons, so they declare it by setting acceptedButtons = Qt::NoButton in their ctors, and the user should not set it differently; whereas with PointHandler, we do expect the user to set acceptedButtons. tst_PointHandler::tabletStylus now has code to test both with and without AA_SynthesizeMouseForUnhandledTabletEvents. But in the "true" case (the default), it won't pass until we also change QGuiApplicationPrivate::processMouseEvent() to send synth-mouse-moves from the same device that sends the mouse press, which itself is synthesized from the tablet press. [ChangeLog][QtQuick][PointHandler] If PointHandler is declared with acceptedButtons: Qt.NoButton it now means that the PointHandler does not care which buttons are pressed or not pressed: but it ignores synth-mouse events and responds only to events that come from the appropriate kind of device. If specific acceptedButtons are set, synthetic mouse-moves can deactivate it temporarily. Pick-to: 6.8 Fixes: QTBUG-111336 Change-Id: Ic48565f74d247803e338d2e368a5ef9d249296c2 Reviewed-by: Doris Verria <doris.verria@qt.io>
* Refactor, clarify and generalize tst_PointerHandlers::mouseEventDeliveryShawn Rutledge2024-09-261-130/+153
| | | | | | | | | | | | | | | | - findChild() doesn't need a string argument if there's only one instance of the type, and thus nothing to disambiguate - initialize member variables where declared - rename pointer->point - move relevant behavior flags from EventItem to EventHandler - since press events arrive pre-accepted, it makes more sense to test what happens if we ignore() - test all combinations of an item and/or handler ignoring the event - we could test weird combinations like a handler that ignores the event but also grabs... but aren't doing that so far Change-Id: I6b9da7120c779ad9d9cffc2ef468fdafb087bc20 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* DragHandler: Don't change QEventPoint accepted state in touch eventsDoris Verria2024-08-302-0/+101
| | | | | | | | | | | | | | | | | | | | | | QQuickDragHandler::handlePointerEventImpl() accepts the event to begin with. Since ca7cdd71ee33f0d77eb6bf1367d2532e26155cb2 we meant to stop event propagation for mouse events, at least to prevent Flickable from receiving the event via direct delivery after it has already filtered. But back then, QEvent::setAccepted() did not automatically accept the touchpoints; now it does (a questionable choice in Qt 6 that accept() and setAccepted(true) do not do the same thing). Now we leave QEventPoint:isAccepted state alone if it's a touch event, so the workaround to stop propagation of mouse events is the only case where it needs to be changed. And update the comment: since 3073a81e90c8d835dfccccf8b3a080a93ed0d2af Flickable handles touch events directly, it doesn't depend on touch->mouse synthesis. Fixes: QTBUG-124731 Pick-to: 6.8 6.7 Change-Id: I833a4d28f708e27cf01b108da1b886807725dc06 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Add tst_QQuickPinchHandler::dragVsPinchShawn Rutledge2024-07-292-0/+169
| | | | | | | | | | | | | | | | Test the case where two touchpoints are handled by some combination of DragHandlers and a PinchHandler on an underlying item. The details of how this works are described in internal docs such as src/quick/doc/src/internal/ideal-pointer-event-delivery-parallel-drags.dox and it's easier to have an autotest that reproduces the scenarios to verify, rather than needing to repeatedly test by hand on a touchscreen. Anyway it wasn't covered in existing autotests until now; and it's also good to verify the same snippet that we are describing in API docs: src/quick/doc/snippets/pointerHandlers/pinchAndDragHandlers.qml Change-Id: I772235c15e9a20d93769c844ae6a7f488a39c3b6 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* Tests: Move blacklisting to the right placeUlf Hermann2024-06-141-0/+3
| | | | | | | | | | | | The nativeGesturePinchOnFlickableWithParentTapHandler test function is in tst_FlickableInterop. Amends commit 87d61c4fe35aa115018a28f1bdd8d5c2beca6fe6. Pick-to: 6.8 6.7 Task-number: QTBUG-118063 Change-Id: I16fa796af10061f580dbf355cd8eb928bf26d059 Reviewed-by: Liang Qi <liang.qi@qt.io>
* tst_qquickpointerhandler: add Q_OBJECTGiuseppe D'Angelo2024-04-041-0/+1
| | | | | | | | | | The EventHandler class is used in calls to findChild. This requires it to have a Q_OBJECT macro since ce2585d0e9 in qtbase. Add the macro. Pick-to: 6.7 Change-Id: Iea8233231e32f4fcd73a75c6c385e06e9edd11ed Reviewed-by: Matthias Rauter <matthias.rauter@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* DragHandler: don't skip passive grab if state includes releaseShawn Rutledge2024-03-263-6/+3
| | | | | | | | | | | | | | | | If QQuickDragHandler::handlePointerEventImpl() is looking at an event with one released point and one stationary point, and minimumPointCount is 1, then it needs to have a passive grab of the stationary point in case it starts moving. The released point is irrelevant: it's not in d->currentPoints. We cannot rely on QTouchEvent::isEndEvent() as a precheck, because m_touchPointStates is Stationary | Released, and that includes Released, but it's not true that the whole touch sequence is ending. Fixes: QTBUG-123499 Change-Id: I20aeecc1f9c29200c324f3f7dc1e6b73fed21d30 Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* Flickable: don't start flicking on release unless grabbedShawn Rutledge2024-03-201-3/+1
| | | | | | | | | | | If Flickable grabbed a touchpoint on press and then the grab was stolen, do not start flicking in response to the release of the touchpoint. Fixes: QTBUG-113226 Pick-to: 6.7 Change-Id: I068a26f424afd655582b6415275df7a20e59d43c Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* Modify tst_FlickableInterop::touchDragSliderAndFlickable to passShawn Rutledge2024-03-202-3/+4
| | | | | | | | | | | | | | We have a behavior change since Qt 5: if one finger drags a DragHandler in a child of a Flickable, a "stray" finger that touches the Flickable does not flick it. Time will tell whether this is a good change or not. But it's been that way in Qt 6 so far; and in the meantime it's best not to keep this test blacklisted because of one line. Pick-to: 6.5 6.7 Fixes: QTBUG-123490 Task-number: QTBUG-86729 Change-Id: Iad22211b4fe102c2c1d4d7f4c7485decc0aa17a8 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
* tst_TapHandler: unblackist OpenSuSEAxel Spoerl2024-03-191-8/+0
| | | | | | | | | | The test is no longer flaky on OpenSuSE. This patch unblacklists it. Fixes: QTBUG-95939 Pick-to: 6.5 6.6 6.7 Change-Id: Ief388369f6ada575474f47b768eb6fb6ac209a27 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Correct license for test filesLucie Gérard2024-02-2753-53/+53
| | | | | | | | | | | | | | According to QUIP-18 [1], all test files should be LicenseRef-Qt-Commercial OR GPL-3.0-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I26d72e8de04d4c7c57b3b7838af5d033265de5ba Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* HoverHandler: setHovered(false) for any pointer event outside boundsShawn Rutledge2024-02-212-37/+54
| | | | | | | | | | | | | | | | | | | | | | | | | 8e822e981d91e688799c8670f11dfdf6aaf9e0d1 was expecting HoverHandler to receive a QTabletEvent when hover leaves. That worked before bbcc2657fa0dbf715e6db7d675662e4be94a1e04: a HoverHandler had a passive grab, so it would receive the next QTabletEvent that moved outside the item. Now that we stopped doing passive grabs, the event that indicates that the cursor is leaving the item is always a QMouseEvent sent from QQuickDeliveryAgentPrivate::deliverHoverEvent(). If the mouse event says the cursor is outside the item, it doesn't matter what device it came from: this handler is no longer hovered. But as before, if the position is still inside, and a particular HoverHandler is hovered because a tablet stylus was previously detected, do not un-hover merely because of a synth-mouse event at the same position. Amends 79893e1773be9d04208243cb88c1daf793d830a4 Fixes: QTBUG-116505 Task-number: QTBUG-101932 Pick-to: 6.5 6.6 6.7 Change-Id: Id0b622fad524ae4be8b37b9cb55e68384056964a Reviewed-by: Doris Verria <doris.verria@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Blacklist tst_qquickhoverhandler::window on OpenSuseShawn Rutledge2024-02-191-0/+3
| | | | | | | Task-number: QTBUG-122405 Pick-to: 6.6 6.7 Change-Id: If5b9a3bb38b1fe44dc3e8891b04c34659be23eff Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Ensure that HoverHandler reacts if a touchpoint moves out of boundsShawn Rutledge2023-12-282-0/+60
| | | | | | | | | | | | | | | We rely on QQuickDeliveryAgentPrivate::flushFrameSynchronousEvents() mostly, but it doesn't get invoked without a window update request. So there is a special case when a touchpoint moves _out_ of an item that has a HoverHandler but is not reacting to touch in other ways: we just need to send another artificial hover event for each touchpoint to each hovered item to inform handlers about the new hover position. Fixes: QTBUG-120346 Pick-to: 6.2 6.5 6.6 6.7 Change-Id: I479362a2663943eb495fe0be418009165c7134bd Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-23 20:30:12 +0000