Fails on previous 42.3 and also 15.0. Just covering "opensuse" saves
us from new commits every time we upgrade our openSUSE. We have a bug
open of it after all.
Task-number: QTBUG-51399
Change-Id: I5c0869daea41b1886faba3d0caaa0804a3705d54
Reviewed-by: Liang Qi <liang.qi@qt.io>
Frameless obscured windows do not receive WM_PAINT/expose events on
Windows. Qt::WA_Mapped needs to be set on them to ensure updating works.
Task-number: QTBUG-39220
Task-number: QTBUG-52039
Task-number: QTBUG-58575
Task-number: QTBUG-63927
Change-Id: Ic6c11f2be96378b6a6b61296f1f3e13cd49b50a6
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
I've tried to reproduce the failures in the CI a couple of times now,
but it keeps passing. Let's leave some debug output in the test so
that if/when it does fail, we might know a bit more about why it does
so.
Task-number: QTBUG-69492
Change-Id: I5b39ac692e9026ce4b25cd13d342b11e061b777b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Nathan Collins <nathan.collins@kdab.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
QMessageBox window ignores QCloseEvent if it was created
with Ok button and the detailed text was set. But it can
be closed if it contains only one button.
Make it closable if there are two buttons and one of them
is the "Show Details..." button.
[ChangeLog][QtWidgets][QMessageBox] A message box with two
buttons, one of which is the "Show Details..." button,
can be closed by clicking the X button on the window's
title bar.
Task-number: QTBUG-69526
Change-Id: Iba09e38561eb3898dc2aecfd38d8519d512a71c1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The QTRY_VERIFY was needed because the window doesn't initially have a handle,
and QTest::qWaitForWindowActive(QWidget *) only checks the active state of the
widget if it does, returning false if not.
This broken logic should be fixed, but for now let's make it clear what's
actually going on by using an explicit wait for the window handle.
Change-Id: I6dd89e0894efed14f4b9a2562dfe8ca76b5ef89c
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This test was un-blacklisted in 4050ee6ac7
but apparently it is still not stable.
Task-number: QTBUG-69666
Change-Id: Iaf933ee27d54ebbfa52d0a8d7b1def0ca91808e7
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
It's useful to know how many times the signal was emitted, because it
gives us insight into why the test may have failed, especially when
it's difficult to reproduce.
Task-number: QTBUG-69492
Change-Id: I94796ed880512b060e0a724c87edde8c3b91bb7c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Tests could change this property, and since the majority of the tests
share testWidget instead of creating local instances, we should be
thorough when cleaning up.
Change-Id: I6039fb6857f4f788f809b1d1fd491b4ef34923ca
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The majority of the test reuses testWidget. While this may be faster
than creating a QDateTimeEdit instance on the stack for each test,
it introduces issues when certain properties aren't unset when cleaning
up. This happens easily when new tests are introduced which rely on
certain properties, for example.
Rather than making the newly introduced step-modifier-related tests
use testWidget, this patch goes with the simpler option of hiding
testWidget, just like other tests currently do.
Eventually we should probably switch to using local instances
everywhere.
Task-number: QTBUG-69492
Change-Id: I4d5625be0b7c72db793346f43fe3a7e7c1241f13
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
By making the test independent of fixed top level widget sizes, it can
also be run on platforms, that do not support this feature.
Task-number: QTBUG-68297
Change-Id: I6945d259801360a9819b9b631d0a7497d3d27a9a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Additionally to setting the cursor position we have to make sure that
enter and leave events are triggered. As WinRT at the moment only supports
maximized/fullscreen native top level widgets, an enter or leave event has
to be triggered, every time the cursor enters or leaves the core window.
Same as is done on Windows desktop an enter event is immediately followed
by a move event even for emulated mouse events.
Change-Id: I4b9a7b07f8e24b7887619f96979a064d933788aa
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
The min/max section size was not checked when setting the default
section size. This was an oversight when the check for min/max section
size was added to resizeSection().
[ChangeLog][QtWidgets][QHeaderView] setDefaultSectionSize() now
checks if the given value is inside min/max section size
Task-number: QTBUG-69431
Change-Id: I1b5704282927ce5a8520f52174ebf91d9840bc8a
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
Visual Studio complained about the usage of a potentially uninitialized
variable which made compilation fail.
Change-Id: I0bc9d1e47d3b00b047912164c3bc4197a2058f85
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
This autotest fails on the new Ubuntu 18.04 platform.
Task-number: QTBUG-68864
Change-Id: I799defcec3a41d86a604bfcd4c2e1081ae4e0e53
Reviewed-by: Simo Fält <simo.falt@qt.io>
Wrong test was blacklisted for this commit.
This reverts commit 85607bd70d.
Change-Id: Ica5272799afec88c05e2cd137835bcdcb587836e
Reviewed-by: Simo Fält <simo.falt@qt.io>
It might have been fixed in the three years since it was marked
insignificant, and we can't investigate the crash while it's not
tested.
Task-number: QTBUG-50747
Change-Id: I99cdeb55e207d10fe524cd5f4868f042c64eb7d3
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
CSS geometry constraints such as "min-height" or "min-width"
will set size constraints on the widget.
Removing the stylesheet should remove these constraints.
Task-Id: QTBUG-69418
Change-Id: I1008e4390281c90112303d72dd7d59a8acddfcd9
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Fixing some issues that could cause intermittent or environment-dependent
failures. One kind regards the use of multiple QTest::mouseMove()
calls in sequence internally using the QCursor API, causing timing
dependent failures. Switching to the override that does not require the
QCursor API, where possible. Other test could fail depending on the size
of the screen.
Change-Id: I4a368955ddbb48f729dcdf74c20eb163329936b2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This patch allows the developer to pick which keyboard modifier
increases the number of steps a QAbstractSpinBox takes when the user
interacts with it.
The modifier can be either Qt::ControlModifier (default),
Qt::ShiftModifier or Qt::NoModifier. Qt::NoModifier disables the step
modifier. Note that on macOS, Control corresponds to the Command key.
Holding the modifier increases the step rate when:
- scrolling;
- pressing the up/down keys;
- pressing the spin box up/down buttons.
[ChangeLog][QtWidgets][QStyle] QStyle::SH_SpinBox_StepModifier allows
the developer to pick which keyboard modifier increases the number of
steps a QAbstractSpinBox takes for the following interactions:
scrolling, up/down keyboard keys and the spin box buttons. The
Qt::ShiftModifier can now be used, or the feature can be disabled
using Qt::NoModifier. Previously, only Qt::ControlModifier could be
used as the modifier.
Change-Id: Ib5518127e86a8f67798a9a1d6e860c6e35896e6f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
... and various other cleanups.
This patch re-factors tests that relied on QCursor API (directly or indirectly via
QTest::mouseMove widget overload) to use the QTEST_QPA_MOUSE_HANDLING code path.
Misuse of QCursor API causes tests to be flaky.
Removed Qt::X11BypassWindowManagerHint as it is not really needed. Based on
the comment where this flag is used, it would be needed for all test functions
that use mouse events. That assumption is not valid. A window is expected to have
received its final position when QTest::qWaitForWindowActive() returns. There were
issues with this on Unity, but those have been fixed.
Un-QSKIP-ed QTBUG_6986_sendMouseEventToAlienWidget for Q_OS_WIN.
Un-QSKIP-ed hoverEnterLeaveEvent for all platforms.
Un-QSKIP-ed bypassGraphicsProxyWidget for Q_OS_MAC and Q_OS_WIN as the test
passes on those platforms. According to QTBUG-33067 it used to crash with 5.2.0.
Removed unnecessary mouseMove() and stray mouseRelease() in mouseDoubleClickEvent().
Removed unnecessary show()/setVisible() on items that are being added to the scene -
items are visible by default.
Among other randomly spotted issues, one worth mentioning is that when adding
items to the scene after the view is already shown, we need to ensure that the scene
is updated (e.g QSignalSpy + QGraphicsScene::changed) before interacting with it. As
an example, mousePressReleaseEvent() only passed because of random luck that the
invalid coordinates were still within the bounding rect of the button. This patch
does not attempt to cleanup all instances of this anti-pattern.
Task-number: QTBUG-52546
Task-number: QTBUG-26948
Task-number: QTBUG-33067
Change-Id: I2ccbc004c1cb4f5b31c70c8568ee591c458d8446
Reviewed-by: Kari Oikarinen <kari.oikarinen@qt.io>
Makes sure the tests are skipped on Wayland.
Task-number: QTBUG-62188
Change-Id: Ia50d6cc02fbbac0fb6b77a16eb6372c1adb422d8
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Input value which is over the highest acceptable value, but consisting
of a number of digits equal to or less than the max value should be
considered intermediate.
[ChangeLog][QtGui][QIntValidator] Input value with over the highest
acceptable value, but with equal or less amount of digits than the maximum
value is now considered intermediate.
Task-number: QTBUG-59650
Change-Id: I71a77c9c266f0f3b62c71ac6cb995019385c1cf5
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
The test and its helper were removed some time ago.
Change-Id: Id82a2a1bf829f272e9c1447e697935934c923092
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Not putting executables into debug/release subdirectories leads to the
WinRT AppxManifest being overwritten by the wrong configuration. When Qt
is configured with -release for example, it was possible that the debug
manifest (Manifest files are always created next to the target) is
written last and thus contains debug VCLibs as a dependency.
Additionally the test was changed in that way, that the resulting file
system structure (having helper and test application in a "top level"
debug and release folder) is the same structure as in tst_qobject.
Change-Id: I017b501506c54c4b89773d2b949c097598bc7049
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
QTableView::doItemsLayout() updated the scroll offset for the vertical
header after layouting was done. Since the scroll offset affects the
viewport of the editors, the adjustment was done too late.
Therefore we update the scroll offset right after the scrollbars are
set inside QTableView::updateGeometries()
[ChangeLog][QtWidgets][QTableView] Fixed calculating geometries
for editors
Task-number: QTBUG-48244
Task-number: QTBUG-49548
Change-Id: I3b057764cf99d42d861928a1c73277d34b440f9a
Reviewed-by: David Faure <david.faure@kdab.com>
QFileDialog::selectedMimeTypeFilter() returns either an empty
filter in the case when a platform file dialog doesn't implement
mime type filters, or initiallySelectedMimeTypeFilter() in the
case of Qt's file dialog. In both cases the result is incorrect.
Make it return a mime type filter corresponding to a selected
name filter. As a result, tst_QFiledialog::setMimeTypeFilters()
has to be fixed: QFileDialog::selectMimeTypeFilter() can't select
a name filter for an invalid mime type, and "application/json"
is not supported by RHEL 6.6, so replace it by "application/pdf".
Change-Id: I58d3be860a9b5e8a72cba86d74b520178115a812
Reviewed-by: David Faure <david.faure@kdab.com>
It causes most of the fails seen on Android.
Task-number: QTBUG-69064
Change-Id: I2f97fea41ee78e7962b8c34ed996bbe4bcb88732
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
The original code was added by b316c3ac5e
(in 2012). This patch changes two things:
1) We now rely on WM to position a window based on the set gravity. It
should not be necessary to calculate coordinates manually as was done
in windowToWmGeometry(). We don't even know the decoration size before
the window is mapped.
2) We now update gravity whenever needed instead of hardcoding based
on what Qt APIs (setGeometry vs setFramePosition) where used to set
the initial window position.
The patch from b316c3a says:
"Determine gravity from initial position. Do not change later as
it will cause the window to move uncontrollably"
Since it did not elaborate on the situation, we can only assume
that it was caused by another bug in Qt at the time or perhaps
a broken WM. From [1]:
"Applications are free to change their win_gravity setting at any
time. If an Application changes its win_gravity then the Window Manager
should adjust the reference point, so that the client window will
not move as the result."
Tested on Ubuntu/Unity, KDE/KWin, Gnome-shell/Mutter, Lubuntu/OpenBox.
Works as expected everywhere expect Unity. Unity seems to ignore
XCB_GRAVITY_STATIC and treats it as XCB_GRAVITY_NORTH_WEST, which means
that setGeometry/setFramePosition produce the same placement on this WM
(the behavior was the same also before this patch).
P.S. Also renamed xRect -> rect, which was a leftover from
ae5f2a6672
With this change we can un-blacklist QWidget save/restore geometry
auto tests.
[1] https://specifications.freedesktop.org/wm-spec/latest/ar01s09.html
Task-number: QTBUG-66708
Change-Id: I381eef5d34dddb04de16a897ce5540b9c430b216
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
According to local testing and Grafana statistics for the period of the
last 1 year, this test has not been failing on XCB.
Change-Id: I86640b22c9e7a258965805a661e1e8c3ead8d012
Reviewed-by: Kari Oikarinen <kari.oikarinen@qt.io>
According to local testing and Grafana statistics for the period of the
last 1 year, this test has not been failing on XCB.
Change-Id: Ia7fda4c42d4aeaecd4485d18383cf46bf6af63d1
Reviewed-by: Kari Oikarinen <kari.oikarinen@qt.io>
QWidget::restoreGeometry() is calling QWidget::move() with restoredFrameGeometry,
which internally calls setGeometry() and sets positionPolicy = QWindowPrivate::WindowFrameExclusive,
which is invalid: restoredFrameGeometry is WindowFrameInclusive geometry.
QPA plugins rely on correctly set policies when interpreting x,y. QWidget::move()
was not designed for this AFAICT, so making it to accept frame geometry is
no-op. It is widely used legacy code, changing it could cause regressions.
Save/restore API was introduced in Qt 4.2, at that time we did not have APIs
like QWindow::setFramePosition(), so its unclear why geometry() was not stored
instead. The documentation also is somewhat unclear:
"[..] save the geometry when the window closes [..]"
Frame or client geometry? It does not specify. And from the code we see
that frame geometry was passed as client geometry, not making the original
intention clearer. Besides that, restoreGeometry() is full of other undocumented
assumptions where to place windows and when to fail (fortunately its easy
to write your own save/restore logic). Added a Qt 6 note in the source code.
What this patch changes:
Now we store geometry() in saveGeometry() and use that value in restoreGeometry()
by setGeometry(). This does not cause any behavior difference in window
positioning (tst_QWidget::saveRestoreGeometry still works). Geometry restored
from data saved with earlier versions of saveGeometry() might be positioned at:
x + leftMargin, y + topMargin.
This patch makes tst_QWidget::saveRestoreGeometry to always fail instead
of being flaky. Blacklisting for XCB instead of selected distros.
Also enabled excluded code paths for XCB on tst_QDockWidget::restoreDockWidget().
It does not seem to be flaky, maybe it was in 2015, but lot of things have changed
since then.
Task-number: QTBUG-66708
Change-Id: Ic86a6fd091e2c71b7550b2f476386da704253cd4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
... as specified in the documentation. This was a regression from Qt4
and can cause mouse cursor flickering durig dragging on e.g. custom
widget where some areas of the widget do not accept drag-and-drop.
Task-number: QTBUG-67155
Change-Id: Iaa6f9407181931ed8e3d6a8fec13fd59d3c8625d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This was a regression from Qt4 and also is the documented behavior.
In addition this patch fixes various issues with cursor shape updating
that were discovered along the way and that are necessary for testing
the new changes.
The code in QGuiApplicationPrivate::processDrag() also needed a fixup,
particularly the resetting of QGuiApplicationPrivate::currentDragWindow.
Without this fix we would get DragMove (the one that immediately follows
the DragEnter) only for the first DragEnter event. For example when dnd
starts on mouse press then for mouse click we would get:
<click> DragEnter->DragMove->DragLeave <click> DragEnter->DragLeave
but the expected is:
<click> DragEnter->DragMove->DragLeave <click> DragEnter->DragMove->DragLeave
Task-number: QTBUG-34331
Change-Id: I3cc96c87d1fd5d1342c7f6c9438802ab30076e9e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
This only enables compilation, it doesn't fix any test.
Qt on Android supports process, but not TEST_HELPER_INSTALLS. See also
acdd57cb for winrt.
android-ndk-r10e is used to compile, see
http://doc-snapshots.qt.io/qt5-5.11/androidgs.html .
corelib/io/{qdir,qresourceengine} need to be fixed later.
Done-with: Frederik Gladhorn <frederik.gladhorn@qt.io>
Done-with: Mårten Nordheim <marten.nordheim@qt.io>
Change-Id: I34b924c8ae5d46d6835b8f0a6606450920f4423b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
When an internal DnD occoures in IconMode, the item is moved to it's new
place but the logic in filterStartDrag() has no clue about the fact that
an internal move happend. Therefore the item gets deleted. Fix it by
changing the event's drop action to Qt::CopyAction to avoid the deletion
as it is done within QListWidget DnD code.
[ChangeLog][QtWidgets][QListView] Do not delete item on internal move.
Task-number: QTBUG-67440
Change-Id: I873d3c9fa76e107e108d9af0dcf8cecd1e18a18f
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
