MSVC complains about us comparing a bool to a quint32, which is the
underlying type for the bitfields in QQuickItemPrivate. Fix that by
replacing QCOMPARE(A, true/false) with the corresponding QVERIFY.
Pick-to: 6.5
Change-Id: I7f50e6276b592c9abe8ceaea95c9283a0c431c78
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Reviewed-by: Øystein Heskestad <oystein.heskestad@qt.io>
In MouseArea, containsMouse (mouse inside MouseArea) flag is enabled for
press event irrespective of whether its accepted or not. This creates
containsMouse to be enabled always for this corresponding item leaving
no option to reset.
To fix this issue, containsMouse flag is enabled only if the press
event is accepted for mouse handler.
Fixes: QTBUG-110594
Pick-to: 6.4 6.5
Change-Id: Ibb0e89529ccebc3063330c22b8b3501b2917d78f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Triggering quickmousearea test suite generates qml warnings and its due
to change in qt6 qml compiler. These warnings has been fixed in this
patchset.
Pick-to: 6.5
Change-Id: I38ba666c4ae77f1e82292ab748ca3f4bb6f34d63
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Renames the pressed() getter of the pressed property in QQuickMouseArea
to isPressed() to avoid overloading the pressed()-signal.
Signals should not be overloaded. Also, it makes code generation in
qmltc more complicated.
Task-number: QTBUG-110029
Change-Id: I2373f4fe97b1e955b815825003bc746f2eaf43be
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This fixes the issue where given two hoverable MouseAreas A & B where B
masks A, the `containsMouse` property of A will be incorrectly set to
true if the cursor is positioned above both A and B and the visibility
of A is toggled from true to false back to true.
This patch fixes the above issue by checking if the QQuickMouseArea is
marked as a hovered item in its windows QQuickDeliveryAgentPrivate(QDAP)
instance. If the QQuickMouseArea is masked by another QQuickMouseArea
then it will not be a in the QDAPs hovered items list and we skip
setting the hovered property on QQuickMouseArea, fixing the issue.
This patch also adds a test case to prevent future regressions.
Fixes: QTBUG-109567
Pick-to: 6.5 6.4
Change-Id: I5f024a097b56ef5e0836ca9f8ae547983a089b44
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Since 15337aa91b891b49ffe76c96dd6fa6cd9bead2c2 we have been blocking all
OS-synthesized mouse events. But synthesizing right click from long-
press is becoming more common, so Qt Quick should be able to react to
those.
[ChangeLog][QtQuick] In case your operating system synthesizes a
right-click from a touchscreen long-press, synthetic right-button mouse
events are now delivered normally, so that e.g. TapHandler can react.
You can opt out by setting QT_QUICK_ALLOW_SYNTHETIC_RIGHT_CLICK=0.
Fixes: QTBUG-77902
Task-number: QTBUG-84179
Change-Id: I609041daf0e3e8ce1d1f3b0c78ae3bd264fec8a3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When a data-driven test has
QTest::addColumn<const QPointingDevice *>("device");
QTestData::append() does a type check with QTEST_ASSERT if it's not an
exact match. That can result in a crash, apparently, although it's not
clear then how 59d967a8fb got through CI
the first time.
Amends 59d967a8fb
Task-number: QTBUG-107863
Task-number: QTBUG-107864
Change-Id: I383191b604eb504d49b0d51a23ecc45160f3383b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
In 8ace780b5a we fixed the case when
MouseArea hides itself on press. This time, the concern is when it
becomes _effectively_ disabled by disabling its parent on press.
(As explained in a comment on QTBUG-38364, the MouseArea.enabled state
is independent, but we can nevertheless also find out when the effective
enabled state changes.)
[ChangeLog][QtQuick][MouseArea] When a MouseArea becomes effectively
disabled due to a parent's enabled property being set false while the
mouse is pressed, the press will now be canceled.
Fixes: QTBUG-39806
Fixes: QTBUG-103788
Change-Id: I8d69b535b6e1b5d51ad1e030f52217de9ab541f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The test has been blacklisted on openSUSE Leap due to flakiness.
The flakiness results from system tray messages popping up, stealing
focus from test widgets and interfering with mouse emulation.
This patch adds functionality that tries to regain focus in case of an
interference. The test will time out, if that attempt fails.
Fixes: QTBUG-78153
Change-Id: Ifcab3990166bdf6b6fbc8a8cd4554b22130336c2
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8:
auto QtContainerClass = anyOf(
expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o),
expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o));
makeRule(cxxMemberCallExpr(on(QtContainerClass),
callee(cxxMethodDecl(hasAnyName({"count", "length"),
parameterCountIs(0))))),
changeTo(cat(access(o, cat("size"), "()"))),
cat("use 'size()' instead of 'count()/length()'"))
a.k.a qt-port-to-std-compatible-api with config Scope: 'Container',
with the extended set of container classes recognized.
Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The current implementation would not explicitly store if
hoverEnabled was set. Instead it would use acceptHoverEvents()
directly. The problem is that the latter will also need to be
set to false when a MouseArea is disabled, otherwise it will not
receive a HoverLeave event. But when doing so, we will no longer
know if hoverEnabled was set to true or false by setEnabled() or
by setHoverEnabled(). As such, when the MouseArea is enabled again,
we would no longer know if we should start to subscribe to hover
events or not.
This patch will therefore add en extra bool, hoverEnabled,
that lets us track the hoverEnabled state explicitly.
As a drive-by, also add some internal docs that explains
how a MouseArea differs wrt hover compared to e.g
HoverHandlers and other items.
Fixes: QTBUG-46460
Pick-to: 6.4
Change-Id: I34e078b3574030572bcf770750820959e98ecc4c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Many QTabletEvents are not handled, so being able to "press a button"
or other kinds of basic UI interaction depend on tablet->mouse synthesis
in QGuiApplicationPrivate::processTabletEvent(). If a basic
mouse-handling Item like a MouseArea or Button grabs on _mouse_ press,
it needs to receive the _mouse_ release too; so DeliveryAgent must not
take away its grab until that happens.
Amends a97759a336
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-98936
Fixes: QTBUG-102764
Fixes: QTBUG-103937
Change-Id: I6d75d988d617bc3ceb8465f939d0a69485278cdf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Doris Verria <doris.verria@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I72c89a98c42bbc9234d8495e9e503bec81d11037
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
- Touch first finger
- Touch and release second finger
- Release first finger
QQuickMouseArea::pressed() must be emitted only once;
QQuickMouseArea::released() must be emitted at the end.
Pick-to: 6.3 6.2
Task-number: QTBUG-103766
Change-Id: I849bbbad67c4739bea0a241b396bf4cbbebdd2e0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
In setPreventStealing() we call setKeepMouseGrab(); so it does not make
sense to override setKeepMouseGrab() in other places without even
checking the state of the preventStealing property.
Pick-to: 5.15 6.2 6.3
Fixes: QTBUG-103522
Change-Id: Ib4a2b01b814835715642aec83fac0a84debe2461
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
A lot of CMakeLists.txt files defined QT_QMLTEST_DATADIR twice,
leading to a warning. This patch fixes these.
Pick-to: 6.2 6.3
Change-Id: I8b835fcddd3334f0ecac45cb72bd5763b3a5704d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The bug scenario went like this:
1) QQuickMouseArea::mouseDoubleClickEvent() emits doubleClicked
2) onDoubleClicked in QML hid the MouseArea somehow
3) QQuickMouseArea::ungrabMouse() is called; it sets
d->pressed = Qt::NoButton and d->doubleClick = false (and others)
4) eventually we get back to the continuation of mouseDoubleClickEvent()
which sets d->doubleClick back to true
5) mouse release: this MouseArea is not involved (no grab anymore)
6) next mouse press: QQuickMouseArea::setPressed() has
if (!d->doubleClick)
emit pressed(&me);
pressed() is not emitted because of leftover state
So either we need to avoid setting d->doubleClick to true if d->pressed
has been set to Qt::NoButton in QQuickMouseArea::ungrabMouse(); or else
we should reorder the statements in mouseDoubleClickEvent() to set
d->doubleClick before emitting doubleClicked, so that it will not be
overridden after the QML handler is called. This patch takes the first
approach.
Fixes: QTBUG-35995
Fixes: QTBUG-102158
Pick-to: 6.2 6.3 5.15
Change-Id: Ibe5c9bfbc9c7a70772dd5ebfbc9ce401c6c226d3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is a partial revert of b0848d038b.
The test became flaky again in early February, 2022.
Grafana shows no failures for 6.2, so this only appears to be an
issue on dev and 6.3.
Task-number: QTBUG-82043
Pick-to: 6.3
Change-Id: Ic44e2e10d279a436323e8d9cda5f0096ec199450
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
grabWindow is now implemented for the offscreen plugin, so a large
number of tests relying on that functionality don't need to be skipped
any longer.
Change-Id: I85bfc9e4b327389055041b6187a54f88d9cf81d2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Previously each test would include and build sources from the shared
folder. Now we make those sources a library, build it once, then have
each test link to it instead.
We also take the opportunity to move some helpers that qtquickcontrols2
had added into the quicktestutils library where it makes sense, and
for the helpers that don't make sense to be there, move them into
quickcontrolstestutils.
We add the libraries to src/ so that they are internal modules built as
part of Qt, rather than tests. That way we can use them in a standalone
test outside of qtdeclarative.
Task-number: QTBUG-95621
Pick-to: 6.2
Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
QQuickItem returns whether it contains QGuiApplicationPrivate's
lastCursorPosition. Since that position stores the coordinate last seen
by Qt (the window border), it will always be within the window, and
within an item that covers that part of the window's border.
However, QQuickWindow stores the lastMousePosition as well, and resets
that value when it receives a QEvent::Leave. We can use that to test
whether the window that contains the item has seen a Leave event, in
which case the item is definitely not under the mouse.
Notes on the test: That we use QPointF() as the "reset" value leave the
small possibility that the cursor might be at position 0,0 of the window
(ie inside the window), and the QQuickItem there will not be under the
mouse. We can't confirm this (through an expected failure test), as
QTest::mouseMove interprets a QPoint(0, 0) as "center of the window".
And since we can't simulate mouse moves outside a window's boundary
using QTest::mouseMove, the test needs to explicitly synthesize a
QEvent::Leave for the window.
Fixes: QTBUG-87197
Pick-to: 6.1 6.0 5.15
Change-Id: I04870d6e914092275d9d790312fc702fb99f2935
Done-with: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Remove all qmake project files, except for examples which are used to
test that qmake continues to work.
Change-Id: Ic4abb72dc2dcd75df7a797c56056b6b3c5fe62ac
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
- 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>
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 a97759a336
Task-number: QTBUG-55325
Task-number: QTBUG-86729
Change-Id: I8150f901e00e7a71499fc98ab54f0ba75370f3ec
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
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 1c451b40ae.
Change-Id: I0c6f953514095a491120a0aac9944dc8b04ca17d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
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>
Modify special case locations to use the new API as well.
Task-number: QTBUG-86815
Change-Id: I3b964e3baf0cc7040830156dac30358ea1152801
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
It has blocked integrating anything in CI because of crashing, so
blacklisting is not enough. Does not crash locally for me on macOS 10.15
Task-number: QTBUG-86729
Change-Id: Iddae9edb09fd7b7fdadd122779832c80d0376b2d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
qtbase/2692237bb1b0c0f50b7cc5d920eb8ab065063d47 and the associated
Qt Quick change to do direct delivery of QPointerEvents seem to have
broken a number of tests as they are currently written. It looks bad;
however I spent a lot of time already on some older "basic" tests
like tst_qquickwindow, touchmouse, tst_qquickflickable etc. and found
a lot of things to fix while doing that; so at least those aren't broken
now. Troubleshooting each test takes time. Hopefully it will turn out
that many of these failures are related (there seems to be something in
common about handlers and items stealing touch grabs from each other).
Task-number: QTBUG-86729
Change-Id: I14acf57fc83fa961a25f91108dcd4aea42b54435
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
When creating a target item list for handling pointer events, put
children after the parent item if they have negative z-order value.
This fixes an issue where an item does not receive a pointer event if
there is a child item that accepts the event even when that child item
is shown under the parent item as per the stacking order.
Fixes: QTBUG-83114
Pick-to: 5.15
Change-Id: I711faa22516f5c2396b1138dc507bcaa4ba22241
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
When MouseArea is not anchored with the usual anchors.fill: parent,
such that its position is not 0,0, calculating mouseX/mouseY as
d->lastScenePos - mapToScene(position()) was wrong. It could be
d->lastScenePos - mapToScene(QPointF()), but instead we use
mapFromScene(d->lastScenePos) as in a few other places.
Amends 8068e7b98c.
Pick-to: 5.15
Fixes: QTBUG-85111
Task-number: QTBUG-75993
Change-Id: If1440d05ec3b75d9f9f4802fbc361756fadb559e
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
...and generally deal with changes immediately required after adding
QInputDevice and QPointingDevice.
Also fixed a few usages of deprecated accessors that weren't taken
care of in 212c2bffbb.
Task-number: QTBUG-46412
Task-number: QTBUG-69433
Task-number: QTBUG-72167
Change-Id: I93a2643162878afa216556f10808fd92e0b20071
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
In 78c1fcbc49 we stopped giving the
exclusive grab to hidden or disabled items with is good. But the change
did not take into consideration how mouse area handles its internal
state.
As a simple example: A mouse area that would set itself hiddin in the
press handler, would continue to have d->pressed == true, which means it
would not react to any future press events.
The fix is to let mouse area check in its change handler whether it has
become invisible.
The test also checks that enabled behaves the same way. There is no
action needed, since mouse area does completely custom handling of
enabled (maybe something to fix in Qt 6), disabling a mouse area doesn't
disable its children for example, it doesn't invoke
QQuickItem::setEnabled at all. Due to this circumventing the common
behavior, by chance disabling a mouse area in the on pressed handler
works.
Fixes: QTBUG-74987
Change-Id: Idb8499b3e5bcb744fbba203fdea5c46695bd5077
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Volker Hilsheimer
Santhosh Kumar
Sami Shalayel
Amir Masoud Abdol
Oliver Dawes
Shawn Rutledge
Axel Spoerl
Marc Mutz
Richard Moe Gustavsen
Lucie Gérard
Alexandru Croitor
Andreas Buhr
Mitch Curtis
Fabian Kosmale
YoungSun Park
Qt Forward Merge Bot
Frederik Gladhorn
Allan Sandfeld Jensen
Tor Arne Vestbø