Commit Graph

880 Commits (fa13e35ce47bc0d47f0fbf9888dc653f350ec7ad)

Author SHA1 Message Date
Volker Hilsheimer 1822550529 QFormLayout: Fix assert when showing with hidden rows
Amends a74cdf778c, after which the
initialization of items in invisible rows is skipped. Since data members
in QFormLayoutItem were lazily initialized, this resulted in out-of-bounds
access of QList entries.

Use member initialization for all QFormLayoutItem fields, and check that
vLayoutIndex is valid before using it to access the list entry. Skip
labels and fields for which it is not initialized.

Add test case. As a drive-by, silence the test's provoked warning
messages via ignoreMessage.

Change-Id: I374b414a51df20b9af3087a2676061fc6b7f23e2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2022-03-15 12:45:46 +01:00
Sona Kurazyan 6585963583 Deprecate {QString, QByteArray}::count()
And remove their uses.

[ChangeLog][QtCore][Deprecation Notice] Deprecated QString::count()
and QByteArray::count() that take no parameters, to avoid confusion
with the algorithm overloads of the same name. They can be replaced
by size() or length() methods.

Change-Id: I6541e3235ab58cf750d89568d66d3b1d9bbd4a04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2022-03-12 01:05:45 +01:00
Andreas Buhr c57e2b5d51 Fix tst_qformlayout::wrapping on Android
The content of the window was intended to trigger wrapping.
On Android, the window is larger, so more content is
necessary. This patch adds more content.

Fixes: QTBUG-87401
Pick-to: 6.2 6.3
Change-Id: I33a2fe4560c358f2b0b83523ee4ab26bb5dd2513
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2022-02-24 23:41:14 +01:00
Volker Hilsheimer a74cdf778c Implement QFormLayout::set/isRowVisible
Hiding a row in a form layout is inconvenient to do as access to the
widgets in each row is cumbersome. In addition, a row might include a
layout for the label or the field column, and we can't hide layouts and
instead need to navigate to the widgets inside the layout. And even if
an application developer does all that, the spacing calculation doesn't
ignore hidden rows.

Add setRowVisible and isRowVisible APIs with the usual overloads.
Implement the logic to traverse a layout item to its contained widgets,
so that they are explicitly hidden when a row is hidden, and skip hidden
rows in the spacing calculation.

[ChangeLog][Widgets][QFormLayout] New APIs setRowVisible and isRowVisible
to hide and show rows in a form layout.

Fixes: QTBUG-6864
Change-Id: I6af98409802f331c4523e91d7dac8a97762c579d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2022-02-24 17:07:43 +01:00
Andreas Buhr b39d3cfe30 Activate all tst_qgridlayout tests on Android
Some tests were blacklisted, but the problems cannot be reproduced
any more. This patch activates them.

Fixes: QTBUG-87404
Pick-to: 6.2 6.3
Change-Id: I5944c750a5717daaf43a22d6d1fa51ae54fc3da2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2022-02-22 17:22:59 +01:00
Alexey Edelev 815bc61626 Cleanup tests that add test data to resources explicitly
Remove Integrity and Android specific code that explicitly adds
test data to the resource files. qt_internal_add_test functions
implicitly adds test data to resources for Android and Integrity
platforms by default.

Change-Id: Ia1d58755b47442e1953462e38606f70fec262368
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-02-11 21:54:44 +01:00
Alexey Edelev fdf5d11ff6 CMake: Add BUILTIN_TESTDATA option to qt_internal_add_test
Multiple tests use qt_internal_add_resource that copies the
functionality that is already implemented inside the
qt_internal_add_test function. Simplify these test by replacing
the qt_internal_add_resource call with the new BUILTIN_TESTDATA
option.

Change-Id: I18475b817d6f87264f0de53817d6c26c5ccab4e2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-02-11 21:54:44 +01:00
Thiago Macieira 29fceed2ff QProcess/Unix: ensure we don't accidentally execute something from CWD
Unless "." (or the empty string) is in $PATH, we're not supposed to find
executables in the current directory. This is how the Unix shells behave
and we match their behavior. It's also the behavior Qt had prior to 5.9
(commit 28666d167a). On Windows, searching
the current directory is the norm, so we keep that behavior.

This commit does not add an explicit check for an empty return from
QStandardPaths::findExecutable(). Instead, we allow that empty string to
go all the way to execve(2), which will fail with ENOENT. We could catch
it early, before fork(2), but why add code for the error case?

See https://kde.org/info/security/advisory-20220131-1.txt

[ChangeLog][Important Behavior Changes] When passed a simple program
name with no slashes, QProcess on Unix systems will now only search the
current directory if "." is one of the entries in the PATH environment
variable. This bug fix restores the behavior QProcess had before Qt 5.9.
If launching an executable in the directory set by setWorkingDirectory()
or inherited from the parent is intended, pass a program name starting
with "./". For more information and best practices about finding an
executable, see QProcess' documentation.

Pick-to: 5.15 6.2 6.3
Change-Id: I54f205f6b7314351b078fffd16cf7013c97ee9fb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2022-02-09 11:26:32 -08:00
Pasi Petäjäjärvi 11fcfd75a0 QNX: Remove expected fail
Pick-to: 6.2 6.3
Change-Id: I66b05685dd1c5c5e083db1ecd9265e1e3c859d45
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Rafael Roquetto <rafael.roquetto@qt.io>
2022-02-09 14:17:53 +00:00
Shawn Rutledge 6b2c9b81af Deprecate QContextMenuEvent and QMouseEvent ctors without globalPos
As with QHoverEvent, it's better to require globalPos rather than
"initialized to QCursor::pos(), which may not be appropriate" as the
docs have pointed out for many years now. This removes the remaining
calls to QCursor::pos() in event constructors.

Task-number: QTBUG-52430
Task-number: QTBUG-69433
Task-number: QTBUG-100324
Change-Id: I076dae56f37abaad7085cc95dddee453a80a45f3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2022-02-05 17:18:35 +01:00
Volker Hilsheimer e8bf2c6eba Further improve QShortcut test
Get rid of the function-static main window, which would be destroyed
after QApplication if the test is run with a subset of test row (that
does not include the TestEnd state test).

Make the MainWindow a class member of the test class instead, and rename
it from "mainW" to "mainWindow" to avoid shadowing by "mainW" widgets in
other test functions.

Amends 55928821d1.

Task-number: QTBUG-99630
Pick-to: 6.2 6.3
Change-Id: I83efce5b54afc3a0027a7c0e63efee6a235af585
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-01-18 22:42:44 +01:00
Joerg Bornemann 238e3beb6f Remove unused .qrc files
Task-number: QTBUG-94446
Change-Id: I136d8b4ab070a832866aa50b5701fc6bd863df8a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-01-17 23:17:01 +01:00
Volker Hilsheimer 55928821d1 Improve QShortcut test
The test uses a static MainWindow so that we can execute a series of key
simulations on the same window. The window is then destroyed when we
reach the final test row.

If some of the tests fail, then the window is left in an unknown state,
resulting in cascading failures for the other tests. Fix this by always
trying to show and activate the window, and always destroying the static
window if we have reached the last test data row.

Fixes: QTBUG-99630
Pick-to: 6.2 6.3
Change-Id: I466669f387e8b199e9e719a7ebbe3ae670658b7e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-01-13 21:00:22 +00:00
Tor Arne Vestbø 996061a1c0 macOS: Implement QCALayerBackingStore::scroll for improved performance
The CALayer backingstore never had a scroll implementation because we
were relying on the QRasterBackingStore implementation, but as it turned
out that implementation was not applicable for the CALayer backingstore.

We now implement scroll() by determining which part of the back buffer
can be scrolled directly in-place, and then scrolling the rest by
copying from the front buffer. We have to handle both cases, as clients
may scroll multiple times before flushing, and the scrolled area may
overlap both valid back-buffer content and content that needs to be
pulled from the front-buffer.

Pick-to: 6.3 6.2
Change-Id: Icc09c9488386925116779c9024669a4329b38247
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
2022-01-12 18:13:52 +01:00
Axel Spoerl 5cc5ba8aac Remove unused legacy testdata directory from QWidget kernel unit test
Pick-to: 6.3
Change-Id: Id857c12321b72a7f35e9e7a157dc39f7fb95ecde
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2022-01-12 14:27:59 +00:00
Volker Hilsheimer 13ca705b48 Fix compiler warnings by marking overrides in test
Pick-to: 6.3
Change-Id: Iab5f121ee49c71821a2b71b20ddb36846b1bbaf7
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
2022-01-07 21:49:57 +01:00
Giuseppe D'Angelo 9ea1f0f8b9 Fix qobject_cast on partially destroyed QWidget/QWindow
QWidget and QWindow use bits in QObjectPrivate to provide for a couple
of shortcuts -- one in qobject_cast, and another in the isWidgetType() /
isWindowType() functions in QObject. These can be optimized by simply
looking at the bits, without actually doing more expensive runtime
casts.

These bits were set on construction, but not unset on destruction.  The
result was for instance that destroying a QWidget would report that the
object was still a QWidget when ~QObject was reached.

Fix this

1) by setting the bits only when QWidget / QWindow constructors start;

2) by resetting the bits once ~QWidget / ~QWindow are completed.
Technically speaking this is not 100% correct in the presence of data
members, but luckily those classes don't have any.

Amend an existing test for QWidget (whose comment said exactly the
opposite of what the test actually did) and add a test for QWindow.

Some other code was wrongly relying on isWidgetType() returning true
for destroyed QWidgets; amend it as needed.

[ChangeLog][QtCore][QObject] Using qobject_cast on partially constructed
or destroyed QWidget/QWindow instances now yields correct results.
Similarly, using the convenience isWidgetType() / isWindowType()
functions now correctly return false on such instances. Before,
qobject_cast (and the convenience functions) would erroneously report
that a given object was a QWidget (resp. QWindow) even during that
object's construction (before QObject's constructor had completed) or
destruction (after QWidget's (resp. QWindow's) destructors had been
completed). This was semantically wrong and inconsistent with other ways
of gathering runtime type information regarding such an object (e.g.
dynamic_cast, obj->metaObject()->className() and so on).

Pick-to: 6.3
Change-Id: Ic45a887951755a9d1a3b838590f1e9f2c4ae6e92
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-01-05 02:47:47 +01:00
Volker Hilsheimer 9da1f6b608 Fix widget gesture grabbing
After 7369c31ca1f446e81eda1c93ba13767ffcd83efe, unaccepted touch points
were not grabbed anymore in calls to activateImplicitTouchGrab. However,
gesture recognition relies that widgets for which a gesture has been
partially recognized grab also unaccepted touch points.

Add a parameter to allow the implicit grabbing to take place also for
unaccepted event points.

Add test case that replays touch events similar to what Squish is doing,
and fails without this fix.

Pick-to: 6.2
Change-Id: Idb0b20301b1827be57a03013a59043d97c2ee7b6
Reviewed-by: Stefan Gehn <stefan.gehn@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-12-11 00:51:10 +01:00
Volker Hilsheimer b886a7ca65 Add unit test for moving of opaque widgets
Expose QWidgetRepaintManager's data structures so that we can write
unit tests, and verify that they are correct after moving opaque
widgets (which triggers the accelerated move code path).

Improve the compareWidget logic to not rely on screen grabbing
(which requires permissions), but instead use QPlatformBackingStore's
toImage function, which is faster and more reliable, and also doesn't
require us to show the UI we want to grab full screen in order to
avoid issues with overlapping windows etc.

Change-Id: Iff2ea419f03a390ab6baca26814fef6ff45f7470
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-12-08 23:06:42 +00:00
Volker Hilsheimer ec267a4c7c Add unit test for QWidgetPrivate::overlappedRegion
Added to QWidgetRepaintManager test case, which is the only place where
the function is used.

Includes a helper that creates a complex scene with opaque children,
which will be used in additional unit tests.

Change-Id: I0e0188dd560923a552a8967d8e992dc17cc849d6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-12-08 00:40:21 +01:00
Alexander Volkov 185c8d5adf Skip disabled proxy widgets when (back)tabbing
Fixes: QTBUG-98137
Pick-to: 6.2 5.15
Change-Id: If52053dce361b130ef7dcfaf747710d8ceb9bbcd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-11-19 23:55:44 +03:00
Volker Hilsheimer 22634e0079 Make sure we paint overlapped children and siblings when moving far
In paintAndFlush, QWidgetRepaintManager subtracts opaque children if
the target isn't overlapped and isMoved is set to true. So in moveRect,
set isMoved to true after the blitting of movable areas, and reset it to
false if we have overlapped sibling or child regions. Otherwise, moving
so far that sourceRect is invalid (none of the original pixels are
visible after the move) we end up in a code path that sets isMoved to
true even with overlapping children or siblings, which then breaks
paintAndFlush's assumptions.

Reuse the test case written by Sergiy Korobov <tiamatenko@gmail.com> in
earlier attempts to fix this bug.

Fixes: QTBUG-26269
Pick-to: 6.2
Change-Id: If7443863f5eee79a80220cd587522122f42a21e4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
2021-11-15 18:25:50 +01:00
Antti Määttä ea3ede9c45 Calculate effect bounds when drawing widget graphics effect
Calculate effect bounds for the updated region when drawing the effect
so that the whole affected area gets updated. The effect bounds have
already been added to the region so it doesn't need to be handled in
the drawing function.

Pick-to: 6.2 5.15
Fixes: QTBUG-96240
Change-Id: I0c317311622e6299fb1a3015541408d1d83c93de
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-10-27 14:32:35 +03:00
Volker Hilsheimer 01f96b1764 Don't fire shortcut if the action only lives in an unreachable submenu
Menus can be represented by a menu action, and if that menu action has
been hidden or disabled, then the submenu is not accessible from the
parent menu or menu bar to which it was added. Don't walk the menu
action chain further when checking whether the shortcut should trigger.

Note that this is unrelated to the menu being visible or not; we
obviously want to trigger shortcuts for actions that only live in a menu
that has not been shown, otherwise the shortcut would be rather
pointless.

Pick-to: 6.2
Fixes: QTBUG-25743
Change-Id: I48735e17352989bbc84a72263e4828f519b78095
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2021-10-25 17:17:40 +00:00
Tor Arne Vestbø 132ed5eb51 Centralize maybeLastWindowClosed checking in QWindow
Instead of plumbing QWidgetWindow close events via handleCloseEvent,
we just implement closeEvent directly. This allows QWindow do save
the state of the window/widget before the close event, so that we
know whether we should trigger lastWindowClosed handling, even if
the window was deleted as a result of the close event.

This also relieves QGuiApplication and QApplication from dealing
with the close logic in their notify functions, so that these
functions can focus on the propagation of events -- not how the
event is handled.

Change-Id: I8b586b53a53b1df1d8630c1acb635c60f191bb4b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-10-20 21:17:08 +02:00
Volker Hilsheimer 74e634d82c macOS: Correctly record normalGeometry in Cocoa plugin
Cocoa sends QWidget the state-change notification after the window has
been resized already, at which point we cannot store the normal geometry
anymore.

Handle zoom and full screen callbacks prior to the state changing
to store the geometry in QCocoaWindow. We do not need to handle
minimized state, as the window will still reflect the original
geometry.

Return the stored value from an override of
QPlatformWindow::normalGeometry so that QWidget gets the correct values
even though the new state is already active.

Fix the tst_QWidget::normalGeometry test to make it pass on all
platforms by waiting for the window to actually have transitioned to
the new state before comparing geometries. Both macOS and Windows fully
pass; on Xcb, deminimizing a window using setWindowState does not work,
which is why the test was partially skipped (confirmed by visual
testing). Move those problematic, complex test cases to the end so
that most cases are covered on Xcb as well.

Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Pick-to: 6.2
Change-Id: I518a5db9169b80e8fa25fe4fa2b50bd1ea0e6db3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-10-14 17:19:38 +00:00
Tor Arne Vestbø e95e9c28f0 QWidget: Don't rely on topextra to determine if window is top level
Doing so results in bailing out early for a widget that hasn't been
shown yet, or otherwise resulted in creating extra and topextra,
which means the normalGeometry will not reflect the widget's geometry.

Pick-to: 6.2
Change-Id: Ieb85e9a6109ae34fe20d79e3c12f4517f827a590
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-10-14 19:19:38 +02:00
Doris Verria ec09900997 Call QWidget close handling in QWidget::close for non-toplevel native widgets
Since commit 7ba75d0 we close the QWindow in QWidget::close for native
widgets and trigger the closeEvent in QWidgetWindow. However, if the
widget's window handle is not a top level window, QWindow::close()
will not close the window, failing in this way to deliver the
closeEvent and call the close handling in QWidgetPrivate::handleClose.
To fix, call handleClose() from QWidget::close for such widgets.

Task-number: QTBUG-74606
Pick-to: 6.2
Change-Id: Ied342eced3340aaf19b5443762935b1a5fc5c27b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-10-14 10:19:29 +02:00
Tor Arne Vestbø 947188b969 Fix references to QGuiApplication::lastWindowClosed
The signal is emitted from QGuiApplication these days.

Pick-to: 6.2
Change-Id: I7423cd4808e8df86960f225fd6e4a12a1a4f11f3
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-10-13 22:30:08 +02:00
Volker Hilsheimer 971bf3a9bb Activate tst_QWidget_window::tst_showWithoutActivating on cocoa
The test passes, the functionality is implemented in QCocoaWindow.

Task-number: QTBUG-8857
Pick-to: 6.2
Change-Id: I2f4b3a39cec1aaaf4351753b590f35e280503461
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
2021-10-12 14:08:08 +02:00
Doris Verria 911c97f2b5 QCocoaWindow: Make window key if the app's modal window is hidden
On macOS, when showing a window, we decide if it should be made
key and therefore active, if the app has no active modal session
or if the window's worksWhenModal returns true.

However, the window needs to be made key also when a modal window
is present, but not visible. Add this condition when checking if
the window needs to be made key.

This makes the behavior consistent with what happens when a modal
is minimized on macOS. The input focus is passed to the next window,
and the window appears active, even if it can not be interacted with.

Fixes: QTBUG-85574
Pick-to: 5.15 6.2
Change-Id: I204d4f912128f4a46840789fc2ee08e1b2716bfc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-10-07 14:30:53 +00:00
Volker Hilsheimer 51300566ff Fix closing and showing a window with a native child
Closing a window with a native child results in the native child's
QWidgetWindow being closed. That explicitly calls setVisible(false)
on the child, which will still have the ExplicitShowHide attribute
set from the initial (explicit) show. Even though we then reset
the ExplicitShowHide, the WState_Hidden attribute will still be
set, so Qt considers the window to have been hidden, and not show
it again when the parent becomes visible.

Add a test case.

Fixes: QTBUG-96286
Fixes: QTBUG-79012
Fixes: QTBUG-71519
Change-Id: I482e6d5236c959d82ce66798176b259a3176972c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
2021-10-07 12:54:10 +02:00
Volker Hilsheimer 1453f048f5 Clean up tst_qwidget
Remove dead code
Make logic to position test widgets more consistent across test functions
Consistent cursor positioning logic
Get rid of unnecessary event processing
Reduce calls to qWait with hard coded values
Use qWaitFor to establish asynchronous preconditions
Ignore expected warning messages
Expect-fail (instead of blacklist or skip) some tests that always fail
Ignore unpredictable events in childEvents test
Split large "render" test in multiple test functions

Task-number: QTBUG-52974
Task-number: QTBUG-26424
Change-Id: I206e114c2c1d9801e08600d3341c2738dc881f17
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2021-10-07 12:54:10 +02:00
Volker Hilsheimer 6ad88e7898 Add testcase for QWidgetRepaintManager
At the current state, Qt::WA_StaticContents is not respected on any
platform, and optimizations for opaque widgets is not implemented on
Cocoa.

Task-number: QTBUG-73117
Change-Id: I48b7b0c4436da5a609fdbe51bb1c9789a2a059bd
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-09-30 21:10:48 +02:00
Volker Hilsheimer 223066d431 Don't clear focus if setParent doesn't change the parent
QWidget::setParent might be called to change the window flags, without
changing the parent. For those cases, we don't have to clear the focus.

Decouple the newParent state from the wasCreated flag. In most places
where newParent was tested, wasCreated was either tested previously and
can't be false anyway, or the code executed is irrelevant for widgets
that are not yet created (there can't be a paint manager). In the
remaining case, test wasCreated explicitly to maintain existing logic.

Add test for the cases where the previous code broke the focus, both
for QWidget and QDialog.

Fixes: QTBUG-93005
Pick-to: 6.2
Change-Id: I39dc179c2d348054de3927aa8b69eecef4935511
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
2021-09-28 17:42:57 +02:00
Volker Hilsheimer a03a67fbfa macOS: Remove special cases in enter/leave event handling
The Cocoa QPA plugin no longer tracks popups, but dispatches enter/leave
events when popups show and hide. So the special handling in tests and
QWidgetWindow can go away now.

Change-Id: Ib6ef00689de231996e5e57ecdd8fd0d4c861d68b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-09-24 21:37:06 +02:00
Volker Hilsheimer a5e5943d8a macOS: send enter/leave when a window opens/closes
Since macOS doesn't give us any event when a modal window opens,
we need to do so ourselves explicitly so that the current mouse
window gets a leave event when e.g. a popup opens, and an enter
event when the popup closes again. The case for modal dialogs is
partially handled by QGuiApplication already.

Note: We cannot rely on the transientParent of the opening/closing
window, as it's nullptr for QMenu windows even if the QMenu has
a widget parent.

Add a test for enter/leave events when a secondary window opens,
covering both the dialog and the popup case. For the dialog case,
we sometimes get two Enter events when the dailog closes, which
we have to tolerate for now.
To make the test pass on b2qt platforms, fix the offscreen plugin
to explicitly send enter/leave events in the same way as Cocoa
now does.

Fixes: QTBUG-78970
Pick-to: 6.2
Change-Id: If45e43e625e8362c3502c740154f6a6a8962b9e9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-09-24 19:19:42 +02:00
Volker Hilsheimer 3714e51436 QWidgetWindow: Stabilize test on Xcb
Showing, hiding, and showing a window can result in the Xcb QPA plugin
warning about

qt.qpa.xcb: internal error:  void QXcbWindow::setNetWmStateOnUnmappedWindow()
called on mapped window

The point of the test is to verify that we get a paint event on a window
that is shown again after having been hidden, not to verify that async
windowing systems can handle a show/hide/show sequence. So wait for the
window being exposed before we hide it.

Pick-to: 6.2 5.15
Change-Id: If91a9926613645e78e332dacff34bd57e4034b6f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-09-20 19:00:05 +02:00
Dimitrios Apostolou a5d501000e Blacklist flaky test
Task-number: QTBUG-96270
Pick-to: 6.2 5.15
Change-Id: I3feb604c0c2f394b2915b3d98d3b02f469331a18
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-09-20 15:05:36 +02:00
Volker Hilsheimer c763957503 Activate test of enter event delivery on macOS
The test passes consistently in local test runs on macOS 10.15.

Change-Id: I6f05b27d3cbf930475a435c41db267a00b1726b0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-09-17 18:23:02 +02:00
Edward Welbourne 7a4b586f4b Remove conditioning on Android embedded
It is no longer handled separately from Android.
This effectively reverts commit 6d50f746fe

Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2021-09-17 17:30:14 +02:00
Tor Arne Vestbø bedc588698 Always reset close-status of QWidget when trying to close
Move the status setting and resetting back into handleClose so that we
don't end up with it being set if handleClose is never called in response
to a close attempt. This can happen when QWindow's platform window has
already been destroyed.

Since QWindow::close handles that case gracefully and returns true,
we can safely call it multiple times.

Add test coverage to verify that we get exactly those close event
calls that we want.

Change-Id: Ica77bf17c26d923c3b79b1e5a688addbc88a6277
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-09-15 18:53:57 +02:00
Tor Arne Vestbø 2b8a6d026d Unskip QToolTip::keyEvent test on macOS
The test was failing because it didn't account for the platform behavior.

Task-number: QTBUG-30040
Pick-to: 6.2
Change-Id: I7c523c06f0bfa459c1532cee721718bebc1858c4
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
2021-09-09 19:22:55 +00:00
Volker Hilsheimer 7c85ad307b Add test-case for QWidget closing exits event loop
Also when closed by destruction, which as of today doesn't call
QWidget::close and therefore also not QWindow::close.

Pick-to: 6.2
Change-Id: I426255e2274eae9262243c769df2264fbaa915b0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-09-06 19:44:27 +02:00
Volker Hilsheimer 7ba75d088c QWidget: close the QWindow in QWidget::close
We want to close the window, end full screen mode on macOS, and free
platform resources. This is all done by QWindow::close. QWindow::close
closes the platform window, triggering a closeEvent to QWidgetWindow,
which then calls QWidgetPrivate::close_helper.

This way, closing a window via QWidget::close, QWindow::close, or
interactively by the user are all equivalent.

The QCloseEvent generated by the widget needs to be spontaneous for
window-system generated events (i.e. the user clicked the close button),
and non-spontaneous if the window closes because of a call to
QWindow::close. To keep track of whether the event originated in an
explicit call to QWindow::close, add a boolean to the QWindowPrivate.

Add a test case that verifies that the window resources is destroyed,
and that events are delivered as they should.

Done-with: Morten Johan Sørvig <morten.sorvig@qt.io>
Fixes: QTBUG-46701
Pick-to: 6.2
Change-Id: Iacb6a2c8d5e880b16b0c8f0c9257ed94bed36f5b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-09-02 20:34:48 +02:00
Marc Mutz a7da8e0dab QWidget: cope with QObject::connect()'s incomplete SFINAE-friendliness
The plan for QObject::connect() (perfect) forwarders, such as
QWidget::addAction(), was to just use a variant of the Detection Idiom
to see whether QObject::connect() with the arguments as given would
compile and SFINAE out the forwarder otherwise.

It turns out that the "functor" overload of QObject::connect(), in
particular, is severly underconstrained and accepts e.g. QKeySequence
as a function object, only erroring out via a static_assert() in the
body of the function, and thus at instantiation time and not, as
needed, at overload resolution time.

At the same time, we don't really want QObject::connect() to SFINAE
out on argument mismatches between signal and slot, because the
resulting error messages would be ... unkind to users of the API. We
would like to keep the static_assert()s for easier error reporting.

Reconciling these two contradicting requirements has so far eluded
this author, so for now, to unblock progress, we explicitly black-
and, in one case, white-list possible arguments. Because QKeySequence,
in particular, is implicitly constructible from int(!), and therefore
any enum type(!), incl. Qt::ConnectionType, we need to do way too much
coding in the addAction() constraints. Hopefully, we'll be able to fix
the issue at the root cause, in QObject, before Qt 6.3 is out, but
until then, this is an ok-ish stop-gap measure.

Add thorough overload set checks (positive ones only, for now) to
tst_qwidget and tst_qmenu.

Change-Id: Ia05233df818bc82ecc924fc44c1b349af41cbbf1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-07-24 00:33:09 +02:00
Marc Mutz a6bd2da2ab QWidgetAction: add test for defaultWidget() being deleted before action
... even though the documentation states that the action takes
ownership of the widget.

Change-Id: Ie5520fbda295a5a2774ff8b82165070e9d49e310
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2021-06-22 11:38:32 +02:00
Laszlo Agocs e6a969954a Do not alter a widget's backing window's format once created
Changing anything on a QWindow's QSurfaceFormat has zero and null
effects once the underlying native window has been created. Letting
QWidget update the format is wrong in this case, because we always
expect that the value returned from QWindow::format() reflects
reality.

(reality being the settings with which the underlying native resource
was created, which is typically frozen after QWindow::create(), not
the state of some QWidget attribute. There are certain exceptions to
this, such as when preparing to recreate the underlying native window,
in which case one will want to update all relevant fields of the
format based on the current values of the widget attributes, which is
exactly what QWidgetPrivate::create() implements, and that's good.)

Such a mismatch can have fatal consequences when OpenGL and friends
are involved, but this always depends heavily on the platform and
windowing system. For example, claiming that the alpha buffer size is
0 when the native window was created with 8, or vice versa, can break
OpenGL-related code (both in Qt itself and in applications), that
tries to create a QOpengGLContext configured based on what
QWindow::format() returns. If that format describes settings that are
incompatible with the actual underlying native window, we end up with
the classic Invalid pixel format, EGL_BAD_MATCH, and alike errors.

This is exactly what is happening when a QOpenGLWidget (or
QQuickWidget) is placed in a QDockWidget where one of the ancestors is
forced to native (winId() was called or WA_NativeWindow was set). When
undocking, various code paths in QWidget will try to update the opaque
flag of the widget, which in turn calls updateIsTranslucent. Now, if
this function unconditionally changes the alphaBufferSize in the
QWindow's QSurfaceFormat (even though this is completely futile to do,
it has no visible effect in practice), we get the problem described
above: rendering breaking down due to OpenGL contexts created with a
pixel format incompatible with the native window.

Prevent all this by not touching the format once the QWindow has a
QPlatformWindow. This is the right thing to do, regardless of the bug
in question: a window's (or context's or any other native resource
wrapping class's) format must describe the underlying native resource
and must never deviate, unless we are preparing to create a new native
resource underneath.

When it comes to the autotest, this changes the test added in
555661b625c40f21a6a3e4c73e928a6e8a46db20: the autotest logic is
inverted because what we should test for is that the QSurfaceFormat
stays untouched once the application makes a - futile - attribute
change on the widget.

Fixes: QTBUG-85714
Pick-to: 6.2 6.1
Change-Id: I7bf90711867e8a0fd474895625bf9530a7821fd5
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
2021-06-18 15:14:02 +02:00
Allan Sandfeld Jensen 86bf3a4ddb Blacklist tst_QWidget::multipleToplevelFocusCheck() on SLES 15
Pick-to: 6.1 5.15
Task-number: QTBUG-64446
Change-Id: Ic1f7a1e7b89a9802e4d3103a6755d7df85b1fd81
Reviewed-by: Tarja Sundqvist <tarja.sundqvist@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2021-05-18 11:56:06 +02:00
Piotr Srebrny 867c0b8d8a Do not remove non-widget items when removeWidget() called with nullptr
child->widget() returns null if the layout item is not a widget.
Thus, calling removeWidget(nullptr) will remove all non-widget items
such as layouts or strechers.

Change-Id: I772c1158d0f7e8e2850b6e571b0405a2896f09b8
Pick-to: 6.0 6.1 5.15
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
2021-05-11 16:57:17 +00:00