AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ba3a26ea9f
qt5base-lts/tests
History
Gatis Paeglis ba3a26ea9f mouse handling: fix issue when mixing QTest::mouse* APIs 
... that become apparent after switching qtestlib to use enhanced mouse
event (a37785ec76). With the old code path,
where QGuiApplication was deducing event type it would deduce mouse release
event even when there wasn't one. The new code path doesn't do that, which
revealed an obscure problem when mixing QTest::mouse* APIs (where QWindow
overload goes through QWindowSystemInterface API and QWidget overload goes
through QApplication::notify() and sets mouse_buttons from there). What
happened in this specific test case "./tst_qtreeview selection statusTip" was:

// tst_QTreeView::selection sets mouse_buttons = Qt::LeftButton from QApplication::notify
QTest::mousePress(widget, Qt::LeftButton, ..)

// tst_QTreeView::statusTip
QTest::mouseMove(window, )

The old code path sees that position and state has changed, creates a fake
mouse event, which gets deduced as mouse release even if there wasn't one.
And by luck this happened to set mouse_buttons=Qt::NoButton. So when we use
mouse_buttons later to create QMouseEvent everything works as expected. With
the enhanced mouse we don't clear the pressed button from mouse_buttons (set
in tst_QTreeView::selection) as this is done only from press/release events,
then pass it to QMouseEvent and later because of that QApplicationPrivate::
pickMouseReceiver() returns nullptr.

The fix here is to use e->buttons when constructing QMouseEvent, instead of
relying on mouse_buttons which gets changed from various places and has other
issues that can not be solved without invalidating the current documentation
of QGuiApplication::mouseButtons() (e.g QTBUG-33161). Tests and any Qt code
in general should avoid using the fragile QGuiApplication::mouseButtons() API.
This patch does not affect the old code path (it continues working as before)
and fixes the issue described above for the enhanced mouse API. The enhanced
mouse API actually is better in a way that it does not get affected by button
state from test functions that run earlier, as opposed to the old code path
where every subsequent test function uses mouse_buttons in whatever state it
was left by the test functions that run earlier.

Not relying on mouse_buttons when creating QMouseEvent helped also to discover
other logic error. This caused an in incorrect button state for a mouse move
event that is generated for a release event that simultaneously changes a mouse
position.

Task-number: QTBUG-64043
Change-Id: I6ad8e49d8437ab0858180c2d0d45694f3b3c2d60
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
2017-11-05 17:36:08 +00:00
..
auto mouse handling: fix issue when mixing QTest::mouse* APIs 2017-11-05 17:36:08 +00:00
baselineserver Allow QImage with more than 2GByte of image data 2017-07-08 08:17:13 +00:00
benchmarks Merge remote-tracking branch 'origin/5.10' into dev 2017-10-17 10:34:24 +02:00
global tst_bic: Add linux-gcc-ia32 bic data for QtXml 2013-01-16 08:25:28 +01:00
manual QSysInfo: add a function that returns the boot ID 2017-11-05 18:34:09 +00:00
shared Fix largefile tests on ARM and QEMU targets 2017-03-28 06:55:32 +00:00
README Doc: Fix references to Qt Test 2013-01-30 01:35:06 +01:00
tests.pro Build examples and tests only if their requirements are met 2017-03-22 15:55:55 +00:00

README 

This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.

Linux X11:

   * The user must be logged in to an active desktop; you can't run the
     autotests without a valid DISPLAY that allows X11 connections.

   * The tests are run against a KDE3 or KDE4 desktop.

   * Window manager uses "click to focus", and not "focus follows mouse". Many
     tests move the mouse cursor around and expect this to not affect focus
     and activation.

   * Disable "click to activate", i.e., when a window is opened, the window
     manager should automatically activate it (give it input focus) and not
     wait for the user to click the window.