The test requires Qt::TabFocusAllControls, so Qt::TabFocusTextControls
and/or Qt::TabFocusListControls, which is the default on macOS, is not
sufficient.
Change-Id: Iaf84c7ba67b978b942f396911048716417c38c03
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 283cfe0b80f83833a549d79e2787f5b936d90236)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
tst_QWidget::render_windowOpacity
- Fails constantly, therefore QEXPECT_FAIL better than blacklist
tst_QWidget::enterLeaveOnWindowShowHide(dialog)
- Known flaky, but doesn't need blacklist as it passes when
rerun is used, no need for actions.
Task-number: QTBUG-128371
Task-number: QTBUG-128372
Task-number: QTQAINFRA-6396
Change-Id: I806419996fedea22628eecf311e977c74066d748
Reviewed-by: Tero Heikkinen <tero.heikkinen@qt.io>
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
(cherry picked from commit 975b4c078036427d2bf7026f1ba50ad095d83172)
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
This depends on 9eb06a2848 .
Done-with: Inho Lee <inho.lee@qt.io>
Task-number: QTBUG-107157
Pick-to: 6.7
Change-Id: I9f4521c27ebc847596a94eed0c9116d71905def2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit bc7821764b4d50fbb4e0ca1b84f85980ce15eeb0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The test function renders a pixmap into a widget that is never shown.
It checks for a crash, without failing or passing.
tst_QWidget::render_graphicsEffect() tests the same code path.
Remove the unneeded test function.
Change-Id: I1b64e0466c5a133deec28d0f74ef5acd9858e1ea
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit dfdcb90ffdec0c3a4f7c1c5c59dfba5c04b8c521)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Initially the function was used as a helper function for QWidget,
implemented in da55a1b041. But with
e0bb9e81ab we started overriding it
e.g. QDialog. This "worked" because QDialog itself would call the
private helper, but left a footgun when called via a plain QWidget
pointer, as we did in 5ba0982b28.
That specific instance of the problem was solved by the change in
fc4c6fb5f6bd6bd63b13f1f8b5b7a7289a5fd230, but the trap still exists.
To ensure we can use the function in a polymorphic context in the
future we make it virtual.
Task-number: QTBUG-127806
Change-Id: Ic0810c5439b1e696cfbf199e701f41217acc5742
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 1a0f056f318417ba5e54c8110257b75cf5537acb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
6c036012b5f2304a05af29f29daa7582603f79ae added a case branch to a
switch before the break of the previous case.
Amend the commit and add the missing break.
Task-number: QTBUG-127641
Task-number: QTBUG-125149
Task-number: QTBUG-122747
Pick-to: 6.7 6.5
Change-Id: I3f2b3e07db463b72fa99af493f40cbc1a783f1ed
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 1d409c0854d664bafc2a35b33cb73129a51c947a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As a result of c956eb8edd we are now
reparenting QWindows managed by QWidgets when the widget itself or
any of its parent widgets are reparented. When reparenting a child
widget from being a child to a top level, or top level to child, we
need to know the new top level state to determine if the QWindow
should have a QWindow parent or not. As the window flags of the
widget are in flux during the reparenting, we were using the new
window flags of the reparented widget to determine this.
However, for QWidget children of the widget that's being reparented
we can't use the window flags of the reparented widget. We must use
the flags of the child itself. These flags are not in flux, so we
can use QWidget::windowFlags() directly.
Failing to propagate the child widget window flags was causing us to
lose the transient parent relationship to its parent QWindow for
popup windows.
Fixes: QTBUG-127641
Fixes: QTBUG-125149
Task-number: QTBUG-122747
Pick-to: 6.7 6.5
Change-Id: I6dbc5ff5ad019b0f9188516ff3d645e860a9627b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Volodymyr Zibarov <gogan419@gmail.com>
(cherry picked from commit 6c036012b5f2304a05af29f29daa7582603f79ae)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This reverts commit 99c8ffb9f2. It fixed
QTBUG-104201, which in essence pointed out a state mismatch between
widgets and platform windows on Linux (X11 and wayland). Mismatches
occurred in the margins between calls to QWidget and async screen
rendering: While the widget layer reported the expected size, the
platform layer did so only after the rendering thread had finished.
As mentioned in the comments of QTBUG-104201, the state mismatch is
predictable, temporary and consistent.
By bridging the time gab, an async operation was made to look
synchronous. That gave more comfort to application developers. By
oversight, it broke code that relied on the platform window state
reflecting physical rendering. This has caused QTBUG-126479 as a
regression.
Both purposes can't be served at the same time: The platform window
state either reflects rendering, or the expected state. It's therefore
justified to revert.
Reason for revert: <Causes QTBUG-126479>
Pick-to: 6.7 6.5
Fixes: QTBUG-126479
Task-number: QTBUG-104201
Change-Id: I22380a6a463822a1cb4be90a44d2775954c7ca82
Reviewed-by: Liang Qi <liang.qi@qt.io>
(cherry picked from commit 7d7be38d95eb82ef3e0be5250440072d8b5bc4b2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When QGuiApplicationPrivate::processTouchEvent() sees that the
touch event was not handled, and calls processMouseEvent(), the latter
uses the QEventPoint with pointId 0 regardless of the original
touchpoint ID. Now it updates the persistent QEventPoint from the
original touchpoint so that a double-click event will not be ruled out
because of the timestamp delta or position delta (movement since press)
being too large.
Fixes: QTBUG-125993
Pick-to: 6.7 6.5
Change-Id: I8e9b007818107ac2329454e0ccfb2ac9e506b617
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 2a0b907f11b9c0ad46322ba06482861423246d93)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Focus abstraction in 58d5d4b7c2 was
supposed to be behavior-neutral. QWidgetPrivate::reparentFocusChildren
used QObject::findChildren() to find children inside and outside the
current focus chain. If the re-parented widget had only direct children
and the focus chain was equal to creation-order, the result was
identical to previous behavior.
When the re-parented widget had grandchildren, the behavior differred.
While not being detected by existing tests, it caused a regression.
Re-implement the previous logic: Iterate through the focus chain,
instead of relying on QObject::findChildren() returning a complete and
well-ordered list.
Modify tst_QWidget::focusChainOnReparent() in order to cover the
regression.
This amends 58d5d4b7c2.
Fixes: QTBUG-125257
Change-Id: Iff4f1d0d9b6117c50c8980dfb6eebfc6f6d4a710
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
On some xcb platforms the xcb_configure_notify_event_t is sent after the
window is fully exposed which leads to a wrong position for
QWidget::mapToGlobal(). In this case this results in a wrong position
for QCursor::setPos() which lets the test fail.
Fix it by waiting for a move event with a position != 0,0 before calling
mapToParent/Global().
Pick-to: 6.7 6.5 6.2
Fixes: QTBUG-123998
Change-Id: Ic5e989c4497ccf3ed720a521f9d7e73632b4b1fc
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Add Qt::ContextMenuTrigger enum used with
QStyleHints::setContextMenuTrigger() to override default platform
behavior when to trigger context menu event.
The default is to show context menu on mouse press on
UNIX systems and on mouse release on Windows.
Give developer a possibility to override platform default behavior
to make cross platform application that behaves the same way on all
platforms
Task-number: QTBUG-93486
Change-Id: Ic832d3d8a7c355a8adb46868fff9cfd19988cf3c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Rendering a widget to a paintdevice via QWidget::render() did not pass
the LayoutDirection mode of the widget to the paintdevice which lead to
wrong rendering of text.
This is especially visible with the windows 11 style which does not draw
some widgets directly on the screen but through a QGraphicsEffect on a
QImage.
Pick-to: 6.7 6.5 6.2
Fixes: QTBUG-124931
Change-Id: If2cfa326d2ca45c42e203a4ae91fd857afa5c69c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
If QApplication::focusWidget() returns null, which was the
case on Wayland under some circumstances, then the code collecting
the error output would crash when dereferencing the null pointer.
This fixes that crash and gets proper test failure output instead.
Pick-to: 6.5 6.7
Fixes: QTBUG-124475
Change-Id: Ic34228be953cf42dfe2ebf75957cd48791e6de7d
Reviewed-by: Liang Qi <liang.qi@qt.io>
QWidgetPrivate::isFocusChainConsistent() iterates over
QApplication::allWidgets() to identify and log inconsistencies.
In applications with many widgets, this has a major performance
impact.
Disable the check and return true, unless the logging category
qt.widgets.focus is enabled.
Adapt tst_QWidget::focusAbstraction() to enable the logging category.
This amends 58d5d4b7c2.
Fixes: QTBUG-124666
Change-Id: Ia487b381ab45b052638b189bf56acaf4353b1a37
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: Iea870711410dee1347f1020a6f7afc037e520825
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I7fd9005ef66c11f640a50f0db468cdcb07eb621f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I432e7ced3e49b570cf9e4057fe98411271693750
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: Ic189b1c55b6bdf0397636b3ae9555cc38b60fc48
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I1cd2d45c54fbeb2b89accc257f2ec5b57f20c013
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I2a3f400e58f86cbc339c355977da784ef5c24800
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I7bd841574c07d73416f9f63d564fe31a8475fa9e
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls from testing deletion of the focusWidget, testing
reparenting of the focus widget, testing setEnabled(false) and testing
clearFocus sections.
Task-number: QTBUG-121488
Change-Id: I7e46ddb31bd7dbc0492d057d8d84846db8c873aa
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I5d6871b192b5c4dda00ef912a806e62a529b629e
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I2841522f533c7679cc9c254c5fe7c37f5632fd30
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I4a0d026fbe5da014723254bb9eb8d614cf50232f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I5b429dcaa47cd179785345f9f7a80648574670dd
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The focus chain in widgets is implemented as a double-linked list,
using QWidgetPrivate::focus_next and focus_prev as pointers to the
next/previous widget in the focus chain.
These pointers are manipulated directly at many places, which is error
prone and difficult to read.
Build an abstraction layer and remove direct usage of focus_next and
focus_prev. Provide functions to insert and remove widgets to/from the
focus chain.
Add a test function to tst_QWidget.
Task-number: QTBUG-121478
Change-Id: Ide6379c0197137e420352a2976912f2de8a8b338
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Wrap the call in QVERIFY.
tst_QTextStream::read0d0d0a was also faulty as it *never* opened
the file because of a broken path. Fix it with QFINDTESTDATA.
Change-Id: I61a8f83beddf098d37fda13cb3bfb4aaa4913fc5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: Ifd2c5dcd1cc3d13f689ffd6400ffec0fcc3a6b93
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Focus abstraction in QWidgetPrivate makes direct access to
QWidget::focus_next and focus_prev an antipattern.
Remove usage.
Add object names for better diagnostics when debugging focus issues.
Task-number: QTBUG-121478
Change-Id: Iecd3bdc824bf77c519951f8f7801eb50b29a6e00
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: Id3b9967ddaa7dbb87eef9faaf4681d7cb014ba8c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I88d39def0e85e147b3621d98d150ee65463be94f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: If805bc0e021625b94edc83d7abccc435c1880bea
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I7a4b21018216c2b7cced8d4aa5084c527b694f4a
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: Ieb516cc4fd02230c0ec6bb189da049c3741358dd
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I2faaf575a04652a395956c7d790ac18d9f3ec9e6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2f6fe3a268 has made calls to
QApplicationPrivate::setActiveWindow() redundant.
Remove redundant calls.
Task-number: QTBUG-121488
Change-Id: I0271f3baf718ca5ae03464bbd415cd0feaa9087d
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When a QWidget was reparented, we would take care to reparent its
backing QWidgetWindow as well, into the nearest QWindow of the
new QWidget parent.
However we would only do this for the reparented widget itself,
and not any of its child widgets. In the case where the widget
has native children with their own QWindows, the widget itself
may not (yet) be native, e.g. if it hasn't been shown yet, or
if the user has set Qt::WA_DontCreateNativeAncestors.
In these scenarios, we would be left with dangling QWindows,
still hanging off their original QWindow parents, which
would eventually lead to crashes.
We now reparent both the QWindow of the reparented widget (as
long as it's not about to be destroyed), and any QQWindow
children we can reach. For each child hierarchy we can stop
once we reach a QWindow, as the QWindow children of that
window will follow along once we reparent the QWindow.
QWindowContainer widgets don't usually have their own
windowHandle(), but still manage a QWindow inside their
parent widget hierarchy. These will not be reparented
during QWidgetPrivate::setParent_sys(), but instead
do their own reparenting later in QWidget::setParent
via QWindowContainer::parentWasChanged(). The only
exception to this is when the top level is about to
be destroyed, in which case we let the window container
know during QWidgetPrivate::setParent_sys().
Finally, although there should not be any leftover
QWindows in the reparented widget once we have done
the QWidgetWindow and QWindowContainer reparenting,
we still do a pass over any remaining QWindows and
reparent those too, since the original code included
this as a possibility.
We could make further improvements in this areas, such
as moving the QWindowContainer::parentWasChanged() call,
but the goal was to keep this change as minimal as possible
so we can back-port it.
Fixes: QTBUG-122747
Pick-to: 6.7.0 6.7 6.6 6.5
Change-Id: I4d1217fce4c3c48cf5f7bfbe9d561ab408ceebb2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Previously, querying Qt::ImEnabled only returned the value of
isEnabling(), which is incorrect for edit widgets with read-only
properties set, as Qt::ImEnabled indicates whether text can be *input*
through the input method, which results in the IM being able to insert
text into read-only edit widgets.
The fixed version uses both isEnabling() and isReadOnly() values to
determine whether input methods need to be enabled. For some platforms
(like iOS and Android) that rely on IM to select text, a check for
ImReadOnly has been added to their QPA plugins to enable handles on
read-only input boxes.
At the same time, the imEnabledNotImplemented function in the test file
tst_qwidget was modified, since ImEnabling should give a _false_ value
when a lineedit is read-only.
Task-number: QTBUG-105009
Task-number: QTBUG-110838
Task-number: QTBUG-119182
Pick-to: 6.7 6.6 6.5
Change-Id: Ia2abcdb3200826d567f90447d4f8b71d0ef1fbf0
Reviewed-by: Yansheng Zhu <670429759@qq.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The method removed from QWidgetList widgets in a ranged for loop.
That caused items being skipped.
Create a new list by adding positives, instead of removing negatives
from the original.
This amends b1802a164b.
Pick-to: 6.7 6.6
Change-Id: I3f329290187ddc76169ababe8ffa6059d953212d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In ccd3bf0871 we introduced code that would
ensure that our call to QWidgetPrivate::setVisible() from QWidgetWindow
would not result in WA_WState_Hidden being set. This code was later
modified in 51300566ff to apply to
widgets that were explicitly shown/hidden.
Unfortunately, the reset of the Hidden and ExplicitShowHide attributes
would in some cases result in the widget having only ExplicitShowHide
after being hidden, which is an invalid state.
It also resulted in the widget having both Visible, Hidden, and
ExplicitShowHide, if first being hidden via QWidget, and then
shown via QWindow, which in turn prevented the widget from being
hidden via QWidget::hide().
As we no longer rely on the adjustments to Hidden/ExplicitShowHide
to fix QTBUG-73021, we can remove the entire logic. Any setVisible
call to QWidgetWindow will either come from outside, in which case
we should respect that and set Visible/Hidden via QWidgetPrivate,
or the setVisible call is a result of QWidget itself (or its parent)
showing the QWidgetWindow, in which case the QWidget visible state
is already up to date and we skip the QWidgetPrivate::setVisible
call.
Task-number: QTBUG-121398
Task-number: QTBUG-73021
Fixes: QTBUG-120316
Pick-to: 6.7
Change-Id: I3174ad66b7e10c55aa99b7cb433267632169ca8f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When destroying a widget via QWidget::destroy(), we clear WA_WState_Created,
and then delete the QWidgetWindow, which in turn hides the widget. But
QWidgetPrivate::setVisible(false) skips hide_helper() if the widget has
not been created, which leaves out important events such as the hide
event, and even more important, fails to clear WA_WState_Visible. As
a result, the widget is left visible (and mapped), even if it has been
destroyed.
This is normally not a big issue for the main use of destroy(), namely
destructing the widget, but for cases where destroy() and create() is
used to recreate the widget this is important.
We now unconditionally call hide_helper() if the widget is not already
hidden. As a result, the widget will correctly be visible=false after a
destroy(). This in turn means we need to re-apply the visible state after
recreating the widget when we detect a mismatch in RHI configuration.
Due to our meddling of the Hidden and ExplicitShowHide attributes in
QWidgetWindow private, a QWidet::show() will not have any effect after
being destroy(). This is okey for now, as destroy() is internal to
a widget, and we make sure to either update WA_WState_Visible and
WA_WState_Hidden (in QWidgetPrivate::setParent_sys), or use the
QWidgetPrivate::setVisible() code path directly, which doesn't
have that issue. The root problem will be fixed in a follow up.
Pick-to: 6.7
Change-Id: I77cb88d75e57f0d9a31741161fb14d618a653291
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
It has been passing consistently in dev, 6.7, 6.6, and 6.5 for the past
6 months: http://testresults.qt.io/grafana/goto/S35hM52IR
As a drive-by, fix comment that claims the test is only run on macOS.
Pick-to: 6.7 6.6 6.5
Change-Id: I6502c40e0c39afb68a461bd530df1bacb5211dec
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
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>
Tor Arne Vestbø
Tero Heikkinen
Liang Qi
Axel Spoerl
Shawn Rutledge
Christian Ehrlicher
Volodymyr Zibarov
Eskil Abrahamsen Blomfeldt
Frédéric Lefebvre
Giuseppe D'Angelo
Yansheng Zhu
Chris Lerner
Lucie Gérard