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>
This fails on Android 8, and we want to get Android 8 bump into the CI.
Pick-to: 6.7
Task-number: QTBUG-124291
Change-Id: I179880c38d155df82bcb772f546104d956326647
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
It will return the minimumSize of the underlying QWindow.
The container can then be put inside QLayouts without risking to be
shrunk to a smaller size than the QWindow::minimumSize.
Whenever the QWindow::minimumWidth or QWindow::minimumHeight changes, we call QWindowContainer::updateGeometry(), which will make the layout re-query QWindowContainer::minimumSizeHint() again.
Task-number: QTBUG-121798
Change-Id: Ib7ece7d9d75f2e4964ca9042d8d8b95ce3b17739
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
QLayout::widgetEvent() returned early, when the layout was disabled.
That suppressed ChildRemoved events and lead to a crash, when the
layout was enabled again.
Don't return early on ChildRemoved events.
Add an autotest in tst_layout::removeWidget().
Fixes: QTBUG-124151
Pick-to: 6.7 6.5 6.2
Change-Id: Ib0a0bb73978d9fc2c9777d300cf38a8c4496b702
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Chris René Lerner <chris.lerner@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>
As part of eacd58d4e7, a mechanism was
added to prevent posting redundant UpdateRequest events to the top
level widget, managed by QWidgetRepaintManager. The mechanism relied
on a boolean that was set when posting an update request event, and
reset when processing the event for the top level widget, as part
of QWidgetRepaintManager::sync().
However, for paint-on-screen widgets, we don't post an update request
to the top level, we post it to the paint-on-screen widget directly.
And when processing that event, we don't paint the widget though the
normal QWidgetRepaintManager machinery, but instead call the paint
event via QWidgetPrivate::paintOnScreen().
As a result, an update() on a paint-on-screen widget would result
in never receiving updates for non-paint-on-screen widgets, as
we assumed there was no reason to send further update requests.
We could fix this by clearing the updateRequestSent flag as part
of the paintOnScreen() code path, but that's incorrect as the flag
represents whether the top level QWidgetRepaintManager needs an
update request event or not, and would lead to missed updates
to normal widgets until the paint-on-screen widget finishes its
update.
Instead, we only set updateRequestSent if we're posting update
requests for non-paint-on-screen widgets, which in practice
means the top level widget.
The paint on screen logic in QWidgetRepaintManager::markDirty
still takes care of rate-limiting the update requests to the
paint-on-screen widget, by comparing the dirty area of the
widget.
There is definite room for improvement here, especially in the
direction of handling update requests via QWindow::requestUpdate
instead of manually posted events, but for now this will have to
do.
Fixes: QTBUG-80167
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: Ib5685de7ca2fd7cd7883a25bb7bc0255ea242d30
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>
The test started to "crash" since 576c9160b1.
Task-number: QTBUG-123172
Change-Id: I16c78f517f718510aa22a2e24ed3d502edae52e5
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
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>
This reverts commit c41733b06b.
Based on the Grafana data, last flaky was August 14, 2023, and
the test works fine on local vm with stressed cpu.
Fixes: QTBUG-115598
Pick-to: 6.7 6.6 6.5
Change-Id: I634598d20a581d4d1443a3fd81e1e9481bfa2545
Reviewed-by: Inho Lee <inho.lee@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>
Since the Android emulator on CI is running without hardware accelerated
graphics, showing the widget can take almost the same time as the timeout
for exiting the app with the "wrong" exit code 1. If running on Android,
increase the timeout to 1000 ms to avoid flaky failures. Un-blacklist
tst_QApplication::abortQuitOnShow() since the random failures are
taken care of by this patch.
Task-number: QTBUG-122693
Pick-to: 6.7
Change-Id: Id52ae15b3ab2dbdaf4924b675276dfe3a4168585
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@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>
The test has been very flaky recently. A zero timer might be processed
before the window became visible, so only start closing once the window
has been shown.
Pick-to: 6.7 6.6
Change-Id: If7983723bb8abd2f3495fb21114c517289ebe8d9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This was a feature in Qt 4, but the only platform that carried it over
to Qt 5 was Windows, in ab76593f18, and
that's still the situation.
As a first step in possibly implementing this on more platforms, lets
replace the hard-coded check in QWidgetRepaintManager::hasStaticContents
with a proper QPlatformIntegration capability check in the only call site.
Pick-to: 6.7
Change-Id: I2067109f45116cd8c62facf7224cd748f19e845b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
QWidgetPrivate::setGeometry_sys wrongly triggers full update, which is
why the test was QEXPECT_FAIL, even on Windows, which does implement
static contents.
We can test the behavior without involving the broken QWidget behavior
by resizing the QWindow instead, which triggers a resize of the platform
window and will be fed back through QWSI, similar to when the user
resizes the window via the window frame.
The QEXPECT_FAIL message for the QWidget resize has been updated to
reflect why it's expected to fail.
tst_QWidget::optimizedResize_topLevel() has similar issues to this
test, and solves it by using Window specific platform code. For now
this test has been left alone, as there are a lot more going on in
that test in terms of workarounds and blacklistings, so it needs
further investigations.
Pick-to: 6.7
Change-Id: I28a55c0723b3e7f16b362d1ebc369e038d5a7ac4
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The scroll bars may show up in one of the grabs and not the other,
(as seen on macOS), which is interesting, and possibly a bug, but
is not what the test is checking for, so let's disable the scrollbars
to stabilize the test.
Pick-to: 6.7
Change-Id: Iad97ca5b22783bb1bee51b560957c5461b7d9923
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
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>
Frédéric Lefebvre
Assam Boudjelthia
Jan Arve Sæther
Axel Spoerl
Tor Arne Vestbø
Giuseppe D'Angelo
Liang Qi
Yansheng Zhu
Tinja Paavoseppä
Chris Lerner
Volker Hilsheimer
Tasuku Suzuki
Lucie Gérard
Santhosh Kumar