According to QUIP-18 [1], all tests file 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: I9657df5d660820e56c96d511ea49d321c54682e8
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I13ea8c0994eaeb764462af23ef66ea1a37659b77
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
As a result of using QWidget::setVisible to show the child widgets we
would end up also setting ExplicitShowHide. This is not in line with
the intent of ExplicitShowHide, which is to flag a widget as explicitly
shown/hidden by the developer, which in turn prevents Qt Widgets from
toggling WState_Hidden when the widget is reparented.
By using QWidgetPrivate::setVisible instead, we can show the child
without setting ExplicitShowHide.
As side effect of this is that we no longer reset WA_WState_Hidden
from QWidgetWindowPrivate::setVisible(). This is an issue when the
setVisible call comes as a result of destroying the QWidgetWindow,
as that is an implicit hide, and should not result in the widget
having WA_WState_Hidden. QWidget handles this case in hideChildren
by not calling QWidgetPrivate::setVisible -- instead doing its own
reset of WA_WState_Visible. We don't want to untangle this just yet,
so as a workaround we detect that the widget is already !isVisible(),
thanks to hideChildren having hidden it, and then skip the call
to QWidgetPrivate::setVisible that results from QWindow::destroy().
Task-number: QTBUG-121398
Pick-to: 6.7
Change-Id: Ib5b4d9c84f0569124c5f3ca2169cabff18934e2d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The nativeHiddenChild is not used for anything, and shouldn't be
needed to trigger the failure condition.
That said, I was not able to reproduce the test failure on macOS
14 with the test neither pre or post patch, nor with any of the
test cases mentioned in 51300566ff,
nor with 51300566ff itself, so this
has seemingly been fixed or worked around some other way in the
meantime.
Task-number: QTBUG-121398
Pick-to: 6.7
Change-Id: I299e7f4b71ebdb17870348a3d5b0c49a93228c8b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We were assuming that QWidget was in full control of QWidgetWindow
destruction, via deleteTLSysExtra(), and that we could limit any
cleanups to that function.
But in some situations QWidgetWindow is destructed from other code paths,
in which case we were left with dangling pointers to the QWidgetWindow
in both QTLWExtra, as well as the backingstore.
This can happen if there's a child widget hierarchy where there is not
a 1:1 mapping between QWidgets and QWindows, for example if the window
attribute WA_DontCreateNativeAncestors has been set. In this situation
our normal recursion into children in QWidget::destroy() stops at the
first widget without a window handle. When we then delete the top level
QWindow, the QWindow destructor will delete any child QWindows, which
includes our leaf QWidgetWindow.
We should probably fix up QWidget::destroy to continue looking for
children, even if we don't destroy the current child. But independently
of that we should make sure the QWidgetWindow cleans up when it's being
deleted, regardless of how it ended up there.
There's further room to clean up the deleteTLSysExtra() function and
friends, but that's been left for a later time.
Fixes: QTBUG-120509
Pick-to: 6.7 6.6 6.6.2 6.5
Change-Id: Ib691df164d7c9c83cb464c0a6bf3bc2116e8ca43
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The test renders QCalendarWidget, which ends up in the QStyle code
eventually. On macOS we use a CGContext to draw the native style,
into the test's image/paint device, but CGBitmapContextCreate does
not support QImage::Format_ARGB32. It needs either a premultiplied
alpha, or no alpha at all.
The unification of the palette for the calendar, as is done for
Windows, is also needed on macOS.
Pick-to: 6.7
Change-Id: I5b26e5434b84e4b14eb8784875b76810e0a14230
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Embedding a QWidget in a window container (via its windowHandle())
may cause crashes, e.g. during drag & drop and when the application
goes out of scope.
If a QWidget->windowHandle() is attempted to be embedded in a window
container, return the pointer to the widget instead of creating a
container.
Add an autotest.
Update documentation.
[ChangeLog][QtWidgets][QWindowContainer] If createWindowContainer()
is called with a QWidgetWindow argument, return pointer to the
widget instead of new container.
Pick-to: 6.7
Fixes: QTBUG-119113
Change-Id: Id052a03be13adce05bbd025d86270d265dfb662e
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
If a widget received a DragEnter event that it didn't accept, then the
UnderMouse widget attribute gets set. But the drag manager never got a
drag target, so the DragLeave event was never delivered, leaving the
UnderMouse attribute set incorrectly.
We always need to send DragLeave events to the receiver, even if the
DragEnter or DragMove was not accepted. Otherwise we are not in balance,
and the UnderMouse attribute will remain set.
This is a change of behavior and a very old bug, so only fixing this in
unreleased branches. Test case added to verify that explicitly generated
drag events result in the correct enter/leave events.
[ChangeLog][QtWidgets][QWidget] DragLeave events are now always sent to
the widget the mouse is leaving, even if it didn't accept the DragEnter
event.
Fixes: QTBUG-50403
Pick-to: 6.7
Change-Id: I5eae49da000fb4fea81f1767f0e73a06a6b78975
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
A call to QWidget::destroy() will end up in QWindow::destroy(), which
calls QWindow::setVisible(false).
A call to QWindow::setVisible(false) on a widget's window will under
normal circumstances end up in QWidgetPrivate::setVisible(), which in
turn recurses back into QWindowPrivate::setVisible(), via
QWidgetPrivate::hide_helper(), ensuring that the QWindow internal
state is updated, visibleChanged emitted, and show/hide events sent.
Durin QWidget::destroy() we end up in QWindow::destroy(), which calls
QWindow::setVisible(false), but in this case the widget no longer has
Qt::WA_WState_Created, so the hide_helper() call is skipped, and the
corresponding QWindow is not kept in the loop.
To work around this we could have checked for windowHandle() instead
of Qt::WA_WState_Created before calling hide_helper(), but that had
many other side effects, so we opt for a more targeted fix.
Pick-to: 6.7 6.6 6.5
Change-Id: I68f80e5f7df9ee811afcd274a7ee4de31a110da5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The tool tip content size uses an incorrect content margin, when it's
constructed. This content margin has been reset to correct value when
tool tip is positioned using placeTip(). But after that, the content
size not been recalculated.
This patch triggers updatesSize() to calculate content size with
updated content margin values.
Fixes: QTBUG-119752
Pick-to: 6.7 6.6 6.5
Change-Id: I454c8528505686f2724b897e4002f78f3049149a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We used to look through the event queue in QCoreApplication::postEvent,
and if we found an existing DeferredDelete event for the receiver we
would compress the two events into one.
This was changed in 99b89d30fa, as the
logic was causing O(n^2) for deleteLater, by using one of the bits
in QObjectData to track whether the object had already been deleted.
But it kept the logic for tracking this in QCoreApplication::postEvent,
and QCoreApplication::compressEvent would still do the work of deleting
the additional QDeferredDeleteEvents.
To avoid the unnecessary heap allocation of the QDeferredDeleteEvents
we can move the debouncing/compression to QObject::deleteLater().
We use the same mutex as in QCoreApplication::postEvent to guard
concurrent access to deleteLaterCalled.
A note has been added about the (preexisting) issue that the mutex
is not sufficient to prevent data races, as the deleteLaterCalled
flag is part of a bit-field, and we're not guarding any of our
other accesses to other bits.
As QDeferredDeleteEvents is private API, we can rely on no-one else
posting it than QObject::deleteLater(), which should be the case now
that tst_QApplication::sendPostedEvents() was fixed.
The documentation has been clarified as well. It's safe to call
deleteLater() more than once, but that's not _because_ other
pending events for the object are cleared. The latter behavior
is normal ~QObject() behavior. The documentation was probably
written at a point we didn't do any event compression at all
for QDeferredDeleteEvents.
Task-number: QTBUG-120124
Task-number: QTBUG-119918
Change-Id: I2a733095b7cb066ba494b1335aa40200c749cb0c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
grabWindow() currently returns a null QPixmap on Android due to even
raster windows being backed up by OpenGL/QRhi. The test case uses
grabWindow() internally to grab contents to a pixmap and comparing
whether the pixmap contents are as expected, leading now to failures
due to null QPixmap being returned.
Task-number: QTBUG-118849
Change-Id: I51cda2d43fe482252d5604f6b18281d810aa4d2f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Remove the following CIs from BLACKLIST files as they are no longer
used:
- msvc-2015
- msvc-2017
- windows-7sp1
- opensuse-42.3
- ubuntu 16.04/18.04/20.04
- rhel 6.6/7.4/7.6
- redhatenterpriselinuxworkstation-6.6
Change-Id: Ief9550e3455a1ed211d978933262c8d5557b0fec
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
It passes locally, let's give it a shot in the CI.
Fixes: QTBUG-24318
Change-Id: I7df735bdc7963c9c1a8ad8befdc0642f796c32a1
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
There's no point to the file if it has no content.
Change-Id: Ie0deb59a63d5f7a654fcab1218e0a814710072ff
Reviewed-by: Jason McDonald <macadder1@gmail.com>
It relies on moving the mouse, which is likely related to this
failing in CI.
Pick-to: 6.6 6.5 6.2
Change-Id: Ib4a3ba7a9e874c9c2ef2d6d16143adf072e47588
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
It was already blacklisted for macOS 13, and has also been blacklisted
on macOS many times in the past.
See also a9005a70d5.
Pick-to: 6.6 6.5 6.2
Change-Id: I9dc87ef409dd1fcc0f47d5e776927e8912ab40e0
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
If a QShortcut is registered with a QWindow as its parent, but QApplication
is used, we end up in QApplicationPrivate::createShortcutPrivate(), and
create a QtWidgetsShortcutPrivate that implements shortcut context matching
via qWidgetShortcutContextMatcher.
The problem is that qWidgetShortcutContextMatcher expects the windows
to be QWidgetWindows, which meant that plain QWindow based shortcuts
would always fail.
This can happen for example if a QApplication is used in Qt Quick
to provide dialog fallbacks, but QShortcuts are otherwise used
with plain QWindows, or QQuickWindows e.g.
We now defer the check of whether there's an active (widget) window,
and fall back to QtGui's simpleContextMatcher in case we don't find
a QWidget, QAction, or QGraphicsWidget shortcut owner to handle
the matching for.
Note: We don't support shortcut matching for QAction in QtGui,
but this is left for another day. There is also a discrepancy
between how QtGui and QtWidgets handles Qt::ApplicationShortcut.
The former will treat it as a match even if there is no active
QWindow, while the latter requires that there's an active widget
window.
Fixes: QTBUG-116221
Change-Id: I487995f2e660a40f6556828b84a521d81a58f1b6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
These are all trivial: all are over (already or newly-made) const
local variables.
As a drive-by, replace a QList legacy left-shift-based- with
initializer_list-construction.
Pick-to: 6.6 6.5
Task-number: QTBUG-115803
Change-Id: I453e24272c4c4b7dce5b91a0bd04481d833c50bb
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Test sendEventsOnProcessEvents has been noticed to fail when
qgtk3 (Glib) is loaded - Should be fixed in QTBUG-87137
Moving test from blacklist to use QEXPECT_FAIL as it's more
recommended until test is fixed in the relevant configurations.
QEXPECT_FAIL is selected to use as original investigator
reported also some cases when glib is working. Therefore
this approach is giving us more insight for further
investigation is it always failing with glib or not.
It was also reported linkage to zeroTimer test QTBUG-84291,
but not sure why removing that has affected to this one.
Update to QEXPECT_FAIL documentation to tell in first place
that XPASS is not only marking it as XPASS but also failing
the test. Same is mentioned in different location but it
needs more searching or testing how it works in real test.
Task-number: QTBUG-115155
Change-Id: I7fb4ef28dba8adb7009be528f88fc758a12e9006
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The single use of Q_FOREACH in this test is safe to port 1:1 to a
ranged for-loop, since we're in a constructor, and the loop body only
calls member functions of data members (incl. the base class), so we
cannot possibly modify the container passed in as a constructor
argument: any connections or event processing that could re-enter our
caller hasn't been set up, yet.
Task-number: QTBUG-115803
Change-Id: I7095aef1edddbda0d1b0c471192b18acd6fd1793
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
which is flaky.
Task-number: QTBUG-115598
Pick-to: 6.6 6.5
Change-Id: Ibb0a0c6b1e225144e2ce796691c40bb7510bfd56
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Those tests often fail on Android 13 on RHEL 8.6 and 8.8. This patch
skips them to unblock CI while the underlying reasons are investigated
and fixed.
Task-number: QTQAINFRA-5606
Change-Id: If088d69c2160470ef50b2e74cd9b9399451c526d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Add the boilerplate standalone test prelude to each test, so that they
can be opened with an IDE without the qt-cmake-standalone-test script,
but directly with qt-cmake or cmake.
Boilerplate was added using the following scripts:
https://git.qt.io/alcroito/cmake_refactor
Manual adjustments were made where the code was inserted in the wrong
location.
Task-number: QTBUG-93020
Change-Id: I3c0d1a63c474969e5eaee5fdbb1bb0229482fc5b
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
QDeferredDeleteEvent has the loopLevel field, which is a sum of
scope and loop levels found at posting. In sendPostedEvents however,
it is impossible to only use this information to find delete events
posted before the outermost loop (which should be handled by any loop)
based solely on this information, as the scope level essentialy removes
the information on loop level.
Break the loopLevel in two, storing both loop and scope levels in
QDeferredDeleteEvent, so that we can check whether an event was posted
before the outermost event loop (for which we need to compare only the
loop level).
QDeferredDeleteEvent was also made private as it should - it is an
implementation detail that wasn't hidden properly.
Change-Id: I0a607a0bd3a2deb5024acad67f740dbf4338574c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
b1802a164b added handling for a parent to
become focus proxy of a child. The respective 'else if' branch didn't
check whether setFocusProxy() was called with a nullptr argument.
This patch adds the missing nullptr check.
It also adds functionality to tst_QWidget::tabOrderComboBox() to test
the removal of a focus proxy, as well as the complete removal of an
element from the focus chain.
Change-Id: I4cb865b9ac4497fc5e2595910738fb77694f5837
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When a parent became a new child's focus proxy in an existing focus
chain, the child was appended at the end of the chain.
That leads to broken tab order, e.g. with a QComboBox which became
editable after a focus chain has been set.
This patch captures the case and insertes the new child after its
parent in the focus chain.
A corresponding test function is added in tst_QWidget.
Fixes: QTBUG-111978
Pick-to: 6.5
Change-Id: I3a426c0560fa830b7b7ffead54f26dd0adef499f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The "two widgets at a time" API to set the tab order is awkward and
easily misused (as the documentation explicitly explains). Add an inline
overload that takes an initializer_list, and call the existing function
for each consecutive pair of widgets in the list.
Add documentation with snippet, and a test.
Change-Id: I8e6f14a242866e3ee7cfb8ecade4697d6bdfb4d4
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
If a composite widget is put behind one of it's contained children via
QWidget::setTabOrder, then our logic might replace the composite widget
with the contained child. In that case, we'd end up with a broken tab
chain, possibly resulting in incomplete clean-ups and triggering asserts
when shutting down the UI.
Handle this by stopping the last-child searching logic at the respective
other widget, and by not allowing both widgets to be the same.
Augment test case, and apply some minor refactoring to the code.
Pick-to: 6.5 6.2
Change-Id: I7d97dfa85315b6c01daa283253025d94a1727048
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
<bit> exists in C++20 and is properly both constexpr and optimized. But
in C++17 mode, we don't have constexpr bitops and instead elect to have
performance at runtime instead. But somewhere along the line, either
when they were added, when C++20 <bit> support was, or in any of the
bugfixes for other compilers, the nesting of #ifdef got messed up and we
declared that we had constexpr builtins for MSVC in C++17 too.
The macro QT_HAS_CONSTEXPR_BUILTINS isn't supposed to be used by anyone
else... but we ended up not being able to use it ourselves either. So
I'm renaming it to a more precise label.
Pick-to: 6.5
Change-Id: I9671dee8ceb64aa9b9cafffd1741b9b4060c9753
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
A recent update moved handleScreenChange out of being a private slot.
Porting to the new syntax fixes the warning and moves to a compile-time
check.
Pick-to: 6.5
Change-Id: Ibd85c6caf7dca051d669250a94a82fbddbd3435d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Failing test functions fastMove, moveAccross, moveInOutOverlapped seem
to be stable in the meanwhile. This patch removes the blacklisting.
Task-number: QTBUG-109036
Pick-to: 6.5
Change-Id: I9a2b015572e4d8a4eac196d3985c052030fd84e2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When rows are hidden (implicitly or explicitly), then their layout data
does not get fully updated. If rows get hidden after the layout data has
been calculated once, then we must make sure that their indices are
reset. Otherwise we might access array indices that are out of bounds
when the layout data structure gets resized to fit only visible rows.
For good measure, skip entirely over hidden rows when accessing the
layout data when arranging the widget.
Fixes: QTBUG-109237
Pick-to: 6.5 6.4
Change-Id: I4d6943b6a110edb61f60ce78d31f0fc64b5cc03d
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This reverts commit 4096667d66.
Reason for revert: <Screen shot workaround is flaky.>
Change-Id: I6e01cc584c094d0d0b8c1544b9daf72d648dd002
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Due to an XCB library change, QXcbBackingStore::toImage() cannot be
safely assumed to return an image identical to QWidget::grab().
The test functions fastMove(), moveAccross() and moveInOutOverlapped()
relied on QXcbBackingStore::toImage() and failed.
They were backlisted on Linux/XCB.
This patch obtains a screen shot instead of an image from the backing
store on XCB platforms. It processes events until the screen shot
matches QWidget::grab(). It makes the test fail only if the comparison
times out.
The patch also removes the BLACKLIST file, containing only the test
functions mentioned above.
Fixes: QTBUG-109036
Pick-to: 6.5 6.4
Change-Id: I26dd5b89dc62b313db066a285f6ad7d4d92baaf2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Wayland omits optimizations tested in tst_QWidget::optimizedResizeMove()
and optimizedResize_topLevel() under certain circumstances, e.g. on
Ubuntu 22.04 / Gnome. This makes the test functions fail.
This patch skips the test functions on wayland platforms, if an
omission is detected.
This amends 2ec7a6322f.
Fixes: QTBUG-109746
Pick-to: 6.5 6.4
Change-Id: If0df6b1cf451a7f0dccfc1bb7411e895d7ae29a3
Reviewed-by: Liang Qi <liang.qi@qt.io>
The test shows an application modal QMessageBox, but assumes that doing
so will be non-blocking, which for macOS is not the case (yet). Instead
of making the dialog window-modal, which would potentially affect the
logic of the test, we disable native dialogs. This should be fine, as
the purpose of the test is to test the is_closing logic of
closeAllWindows, which lives on a layer above the native dialogs.
Pick-to: 6.5
Change-Id: I6d627984a6ca452b876f34404b669fce41a00851
Reviewed-by: Doris Verria <doris.verria@qt.io>
If a widget's geometry is restored to a screen, which is smaller than
the one it was saved from,
- the widget could appear (partly) off screen
- the widget's title bar and resize handles could be inaccessible
This patch refactors and documents checkRestoredGeometry.
In a first step, the restored geometry's size is checked against
a given screen size. It is corrected if necessary.
In a second step, the restored geometry is moved inside the screen,
if necessary.
It makes the function a static member of QWidgetPrivate in order to
expose it for auto testing and adds a respective test function to
tst_QWidget.
Fixes: QTBUG-77385
Fixes: QTBUG-4397
Task-number: QTBUG-69104
Pick-to: 6.5 6.4
Change-Id: I7172e27bfef86d82cd51de70b40de42e8895bae6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QWidgetWindow dispatched only tablet presses to the toplevel widget if
no child was found at the position; other events, such as hover events,
were discarded. The tabletTracking test case even documented that
shortcoming in a comment.
Fix that by falling back to the toplevel widget for any event. As
before, only press events initialize the tablet grabbing target widget.
Remove the now unneeded parent widget from the test case, and move the
test class into the only test function that uses it.
Amends ea615b421b and
8fd6cef372.
Pick-to: 6.4
Fixes: QTBUG-108747
Change-Id: I79050f1e063931e439945f64b50712dcc1ecb18c
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The test functions tst_QWidget::optimizedResizeMove and
tst_QWidget::optimizedResize_topLevel use a custom widget to record
paint events in a boolean.
Using QTRY_* or qWait() to wait for the boolean to become true stops
event processing upon consumption of the first paint event.
In case of multiple paint events, the next paint event will be recorded
in the next check and may lead to a wrong result.
This leads to flakiness on platforms generating multiple paint events,
openSuSE Leap 15.4 / XCB being one of them.
This patch replaces the boolean with a counter. It adds a
waitForPaintEvents method to the custom class, which processes events,
until the counter stops increasing. It returns true when paint events
have been recorded and false otherwise. It resets the counter after
each call.
It also removes the QSKIP on wayland, as the failure results from the
same reason.
Fixes: QTBUG-109093
Pick-to: 6.4
Change-Id: I59ee8bb4efeaf5417d5749d21e384bee89301ae0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It started being recorded as flakey after making macOS 13 a significant
config in the CI, but it's unclear why the test was not failing during
the nightly testing leading up to that.
http://testresults.qt.io/grafana/goto/-AzSwMKVz
It has also been blacklisted on macOS many times in the past.
Change-Id: I7be5fefb3669e9643a98d2ac82059bf0576c6d5c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When a widget's palette has different brushes in Active / Inactive
color groups, or it is pixmap based, multiple paint events are
triggered. This leads to unpredictable, double entries in
QWidgetRepaintManager::dirtyWidgetList().
This patch overrides event() of all test widgets and ignores
activation / deactivation events in order to make the entries of
QWidgetRepaintManager::dirtyWidgetList() predictable.
Pick-to: 6.4
Change-Id: I164d7ab4148551590ac3c50fcc3b9f98c5ac0535
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QXcbBackingStore::toImage() returns a QImage that differs from what
is displayed on the screen: After multiple moves of children within
their parent widget, the last move is not always properly reflected
on openSuSE 15.4.
This patch blacklists the test functions fastMove, moveAccross and
moveInOutOverlapped on openSuSE Leap.
Task-number: QTBUG-109036
Pick-to: 6.4
Change-Id: Ideb505570df090b25d30762492d9c60beb6641ff
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Tasuku Suzuki
Lucie Gérard
Frédéric Lefebvre
Tor Arne Vestbø
Axel Spoerl
Volker Hilsheimer
Santhosh Kumar
Tinja Paavoseppä
Christian Ehrlicher
Edward Welbourne
Assam Boudjelthia
Marc Mutz
Tero Heikkinen
Liang Qi
Alexandru Croitor
Mikolaj Boc
Thiago Macieira
Friedemann Kleint
David Edmundson