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>
When a slot is connected to the modelReset signal before the model is
set on the view, then such a slot might try to resize the columns or
rows to fit the contents before the view had a chance to perform layout
work.
In that case, the while-loop that calculated the size hint of a rows
(or column) by checking the size hint of each cell might not exit, as
cached information about visual indexes would be invalid.
To prevent this, don't loop over the cells if the actual last row/column
of the model (after the reset) is less than the first (cached) visible
row/column. Also, make sure we increase the counter for number of
rows/columns processed with each iteration.
Add a test (that loops infinitely without the fix, resulting in the
test being killed by the framework), and make the 'actual' variables
constant for clarity.
Fixes: QTBUG-124301
Pick-to: 6.7
Change-Id: I0adb2f1e8a1e78760ef7c19e9686c9572eca8be6
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>
If QToolButton::mouseReleaseEvent triggers its deletion then it
will crash when dereferencing its d pointer.
qabstractbutton.cpp already uses QPointer guards in many places but
qtoolbutton.cpp was missing this one.
While deleteLater() is still our recommendation, we shouldn't crash.
It's not always obvious what led to the button's destruction,
as the chain of indirections can be long.
Change-Id: I4a33447fa4e90953370277eb57a161398ded9a9c
Pick-to: 6.7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
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>
Amends feff219aad which didn't really
do the revert for some reason.
This reverts commit bba26d7220.
Reason for revert: Latest emulator update fixed the issue.
Change-Id: I0bc4263eae36c3ff81f235dcfe3bad9b30afd5d8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ville Voutilainen <ville.voutilainen@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>
Wait 2x double click interval, to make sure a double click is safely
avoided.
Use QTRY_COMPARE at the end of the function, to cover cases where a
synchronously delivered mouse click causes posted events.
Wrap the test implementation in #ifndef QT_NO_STYLE_FUSION, as is the
declaration.
Skip the test on QNX.
Fixes: QTBUG-123798
Pick-to: 6.7 6.6 6.5
Change-Id: I73f4acb241a8c77a542152288c65f3d07582e075
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
File was opened on the previous line.
Change-Id: I418d616a2f82d9241c37224e4c1a0fb12894eb40
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: 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>
Simplifies maintenance of code paths that rely on Metal.
Change-Id: I1d1f705fffc14dbafde346eeb555b43be6d5be54
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
If the dialog is closed by pressing a button, the button will be
reflected via clickedButton(), and the result() will reflect either
the QMessageBox::StandardButton value, or an opaque value for custom
buttons.
Depending on the role if the buttons, the accepted or rejected
signals are emitted.
If the user called accept() or rejecct() on a dialog that had
already been closed by a button, we would as a result of
1f70c073d4 emit a signal based
on the original button that was clicked, instead of respecting
the newly triggered function.
It's a questionable use-case, as the clickedButton() is still
the original button e.g., but we should still avoid regressing
this, so we now emit the signals based on the newly stored
result code instead of using the clicked button as the source
of truth.
To allow this we had to change the opaque result() value for
custom buttons to stay out of the QDialog::DialogCode enum,
but this should be fine as the documentation explicitly says
that this is an opaque value.
Fixes: QTBUG-118226
Pick-to: 6.7 6.6 6.5
Change-Id: Ia2966cecc6694efce66493c401854402658332b4
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
A QDialogButtonBox with the first accept button becoming default, didn't
explicitly set focus on such a button in a QDialog.
d44413d526 implemented this missing
functionality. It set focus to the automatic default button, unless the
QDialog had a focusWidget() set.
That has caused a regression, in cases where
- the QDialog has a QWidget child with a Qt::StrongFocus policy, and
- the QDialog is not yet visible, so focusWidget() returns nullptr.
Amend d44413d526ec12ed83acd7343c2005782178c7ad:
Implement a helper in QWidgetPrivate, that returns true, if a child
with a given focus policy is found.
Do not set focus to a QDialogButtonBox's automatic default button, when
- not located inside a QDialog, or
- a focusWidget() exists, or
- the dialog has QWidget child with Qt::StrongFocus, that is not a
child of the QDialogButtonBox.
Add an autotest function.
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-121514
Fixes: QTBUG-120049
Change-Id: I3c65ae36b56657f9af4a3a4b42f9b66e8bc5c534
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
The method traversed QDockAreaLayoutInfo::item_list, to identify
dock widgets tabbed with the QDockWidget argument in a tab bar
It relied on bool QDockAreLayoutInfo::tabbed, which is set to true, when
a QMainWindowTabBar is to be added to a QDockAreaLayoutInfo. This flag
isn't cleared, when the second last dock widget is removed from the
tab bar. It can't be replaced by QMainWindowLayout::isDockWidgetTabbed,
because the flag also represents intermediate states, where e.g. a dock
widget is hovered over, prepares to become a floating tab and then rolls
back, because hovering doesn't result in a drop. In that case, tabbed
must become true, which the dock widget isn't actually tabbed.
Furthermore, the way to traverse item_list didn't find dock widgets
in a floating tab. In that case, tabifiedDockWidgets() wrongly returned
an empty list.
To fix both issues, refactor QMainWindow::tabifiedDockWidgets() to read
the list of dock widgets directly from the QMainWindowTabBar.
Add tests in tst_QDockWidget::floatingTabs() and
updateTabBarOnVisibilityChanged()
Fixes: QTBUG-122001
Pick-to: 6.7 6.6 6.5
Change-Id: Ia9eb3711be642101261f34ee447521cc6accc20c
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>
When hiding a widget that has focus we try to focus the next widget in
the focus chain by running focusNextPrevChild. The abstract item view
overrides this to step the items but does not account for this hide case
which makes focusing not only not work, but also by hiding the widget
the selection in the item view gets changed.
Pick-to: 6.7 6.6 6.5
Change-Id: I29d40a1fb86ced60ec742b2753a87383846a89b3
Reviewed-by: Viktor Arvidsson <viktor.arvidss@gmail.com>
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
We were handling QEvent::WindowChangeInternal, but based on what the
code is doing, what the comments say, and what QQuickWidget does,
the right event should be WindowAboutToChangeInternal.
This fixes a crash when reparenting a QRhiWidget into another widget,
where we could call removeCleanupCallback() on an RHI that was already
gone.
The fact that we have a stale RHI pointer at WindowChangeInternal time
is still problematic, and caused by our call to addCleanupCallback not
happening as it should for the first call to ensureRhi(), but this will
be fixed in a follow up.
Pick-to: 6.7
Change-Id: I054120e97a24a1f74af44b2d251470792f03f7f3
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
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>
QAIV::rowsAboutToBeRemoved() closed all child editors when the child was
a direct ancestor of the removed index but forgot to check if the index
is an indirect ancestor. Some of those editors were removed later in
updateEditorGeometries() but not all as the testcase in the bug report
showed.
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-103476
Change-Id: I90b3d3bff3857aa79f96eecf23d980928693b7bc
Reviewed-by: David Faure <david.faure@kdab.com>
When using a style sheet, Q(Plain)TextEdit::isReadOnly() might get
called during the initialization before d->control is properly
initialized which lead to a crash.
This amends 43ce457cbd.
Fixes: QTBUG-121697
Fixes: QTBUG-121790
Task-number: QTBUG-1857
Pick-to: 6.7 6.6.2 6.6 6.5 6.2
Change-Id: I15c357c9eef7f6559bcc2ad89033a3d8e7fcbfef
Reviewed-by: David Faure <david.faure@kdab.com>
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>
Frédéric Lefebvre
Volker Hilsheimer
Assam Boudjelthia
Jan Arve Sæther
Sergio Martins
Axel Spoerl
Tor Arne Vestbø
Giuseppe D'Angelo
Liang Qi
Wladimir Leuschner
Yansheng Zhu
Viktor Arvidsson
Tinja Paavoseppä
Jonas Karlsson
Chris Lerner
Christian Ehrlicher
Tasuku Suzuki
Lucie Gérard