User code in an event handler can do arbitrary things, including
operations that lead to destroying the QWidgetWindow. An example is
what the autotest does: reparenting the top-level widget to under
another top-level upon the drop. Internally this leads to destroying
the drop target's QWidgetWindow as the widget is now a child, not a
top-level.
In fact some of the existing drag and drop handling code seems to be
prepared to handle the case of having the drag target widget destroyed
in the user's event handler during a drag-move. But none of it is
prepared for having the QWidgetWindow destroyed upon returning from
forwardEvent().
The associated bug report has the same root cause, it is just popping up
now via the new 6.4 behavior: adding a QOpenGLWidget to a widget
hierarchy upon a drop leads to getting a new QWidgetWindow (if the
window only had regular raster widgets before).
To solve this, avoid touching members on 'this' after the
forwardEvent(). It looks like the handlers for mouse events follow
this pattern already, no member data is touched after forwarding events
(not sure if that is intentional or just incidental but it is the safe
solution, even if this is not feasible everywhere, but ideally input
events should take this into account).
Fixes: QTBUG-104596
Pick-to: 6.4 6.3 6.2
Change-Id: I96c704cadcd799fc5619b776e939dfdf313a27dd
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Since objectName() isn't always set, the className() makes it slightly
easier to find and fix the issue.
Also unify some wording "produce a warning", which is generic enough to
fit:
print warning in terminal
print warning in logviewer (if you're unlucky and have to use Windows?)
print warning in system journal (if you're unlucky have to use binary
systemd journal logs)
Pick-to: 6.4
Change-Id: I7522d65666cb5829c33c45039b8646dd535e21ea
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
A new property Qt::ImEnabled was added in Qt 5.3.
Since the already existing widgets with IM support
(3rd party included) didn't implement this property,
QWidget got the fall back logic that if a widget
was queried for Qt::ImEnabled, and the returned QVariant
was invalid (the widget didn't implement it), we
would, for backwards compatibility with Qt 4, return "true"
(meaning that the widget supports IM).
But a side effect from this fallback logic, is that now
any widget that doesn't implement ImEnabled (or input
methods at all) report that they support IM. This will
confuse platforms like iOS, which uses ImEnabled to decide
if the input panel should show, and if text selection tools
should be enabled. The result is therefore that if you click
on a QPushButton, the input panel will open.
This patch will implement a more careful strategy to check if
a widget implements IM, if ImEnabled is missing. Rather than
saying that all widgets that don't implement ImEnabled supports
IM, we now require that the widget also returns a valid QVariant
for Qt::ImSurroundingText. We assume then, that a widget that
doesn't do so will anyway not be in need of input method support
from the platform.
Fixes: QTBUG-104527
Pick-to: 6.4 6.3 6.2
Change-Id: Ib391fd1daae92c4325e9ccb59730fbdd7c9328fc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
At the very least, it would be important to have a single combination
key sequence. This is commonly seen in keyboard shortcut editors where
QKeySequenceEdit is very much applicable.
[ChangeLog][QtWidgets][QKeySequenceEdit] Added a maximumSquenceLength
property.
Done-with: Marc Mutz <marc.mutz@qt.io>
Change-Id: Id7fa5a8593eb150fa67d7e89308492c0a200ac36
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
- Since 4edcea762d the dropsite example
shows markdown if available; and now it shows that when we do DnD
of a selection from the richtext example, text/markdown is available.
- If we artificially make html unavailable, copying and pasting between
widget-based rich text editors uses markdown.
In case markdown writer output contains unnecessary backticks due to
monospace fonts getting used, the workaround from
1ad456c908 is applied.
Pick-to: 6.4
Task-number: QTBUG-76105
Task-number: QTBUG-103484
Change-Id: Ie6ca4dbb450dbc36b3d09fd0df1ae5909aaebca7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
QGraphicsItems may override itemChange to prevent certain attribute
changes. Overriding ItemSelectedChange this way is explicitly documented
to be allowed.
However QGraphicsScene::clearSelection did not test whether items were
in fact deselected after the call to setSelection, and always cleared
the stored set of selected items.
Fix this by checking the actual selected state of the item as we iterate
over them, and store those items that are still selected in a set that
becomes the new selectedItems set (which will be empty if no item
overrides, which is the default).
Add a test that also checks that clearing the selection emits the
selectionChanged signal correctly (and does not if all selected items
block being deselected).
Fixes: QTBUG-85474
Pick-to: 6.4 6.3 6.2
Change-Id: I665afc132876e02e6e1061b7be37f4f6e4be418f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When QWidget::resize() is called on a maximized or minimized QWidget,
the window state of the widget and the corresponding QWindow is not
updated (i.e. remains maximized or minimized).
This patch updates the window state to Qt:WindowNoState when
setGeometry() is called in QWindowsWindow or QXcbWindow.
A test is added in tst_QWidget.
Fixes: QTBUG-104201
Pick-to: 6.4
Change-Id: I07491fb9293d13509573fc403750da0a50f6a785
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Restoring the toolbar state of a QMainWindow could not update
QWidgetPrivate::widgetItem for the QToolBar, because at that point it
was still holding the pointer to the widgetItem of the previous state.
Later on, when the new state was successfully applied, the previous
state was deleted, and the corresponding widgetItem was reset to
nullptr.
This patch explicitly resets the QToolBar's widgetItem while updating
the state, so that it is later correctly updated while creating a
new QWidgetItemV2.
Fixes: QTBUG-102395
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I17613d62423edcc0faf85ecb0a714865a50d87e8
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QComboBox uses QPersistentModelIndex to store the current index of the
underlying model. When the model is cleared, that index is automatically
invalidated, so calling QComboBoxPrivate::setCurrentIndex(QModelIndex())
does not result in signals being emitted, because we do not detect the
index change.
This patch uses indexBeforeChange to detect such situation and emit all
necessary signals.
Fixes: QTBUG-103007
Pick-to: 6.4 6.3 6.2
Change-Id: I29326830a30a17900839e8d1737a08bd940081ea
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Found by codespell
Pick-to: 6.4
Change-Id: Ie3e301a23830c773a2e9aff487c702a223d246eb
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The code incorrectly tried to ensure that the firstVisible tab was a
valid index, even though there might not be any visible tab left after
removing the last visible tab.
The same logic didn't exist of the lastVisible tab, so we tripped the
assert in qBound, as max (being -1) ended up smaller than min (0).
Fix this by removing the wrong correcting of firstVisible to be always
valid. Make sure we emit currentChanged with -1 when no visible tab is
left after removing the current tab.
Add a test.
Fixes: QTBUG-104003
Pick-to: 6.3 6.2
Change-Id: I27e6438a02d0a0f1ac4d0e0160cee4f33b3f3766
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The documentation says we can change window parent to avoid the widget
deleting the window. That didn't work as the widget didn't get the
child-removed event as it wasn't the parent.
This patch instead uses an event filter on the set parent.
Pick-to: 6.3 6.2
Change-Id: I1f61d1832fcf3257722f305beeefd8f1abf1f656
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
When replacing a widget in a hidden splitter, then we only need to keep
the new widget hidden if the previous widget was hidden.
If the new widget is not explicitly hidden, and the splitter is already
visible, then we need to explicitly show the new widget.
Augment test case; the existing test cases already cover swapping out a
collapsed or hidden widget.
Fixes: QTBUG-102134
Pick-to: 6.3 6.2
Change-Id: I9b60711a5c1cab79777ce4183783114a16ac3394
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This reverts commit 1e938c348b
and bb2f4d08d9.
bb2f4d08d9 causes the crash, but 1e938c348b amends it, so
this reverts both. When the cause of the crash has been determined
and mitigated, the patches can be recreated.
Fixes: QTBUG-103719
Change-Id: Ifc36b3771a96f6c85387a5306a0402d4c508d006
Reviewed-by: David Faure <david.faure@kdab.com>
When XCB_INPUT_TOUCH_BEGIN closes a popup, we then receive
XCB_INPUT_TOUCH_END, and cannot find a target window (because it's
destroyed). If we don't deliver it, we need to at least clear the
stored point from QPointingDevicePrivate::activePoints. Then when
we deliver the next touch press, m_fakeMouseSourcePointId also
needs to be reset.
It's now even more paramount that autotests (and real-world
touchscreens) must never omit any active touchpoint from a touch event.
If a point doesn't move, it must be included in the QTouchEvent, with
Stationary state. If not, QGuiApp::processTouchEvent() could generate
multiple TouchBegin events in a row, which gets other bits of logic
confused, here and there.
Fixes: QTBUG-94557
Fixes: QTBUG-98519
Fixes: QTBUG-102751
Fixes: QTBUG-103706
Pick-to: 6.2 6.3 5.15
Change-Id: Ia95e410a2bb8bc7784aa5d296fac2b89e53a9f55
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Invalid inserts of items are tested. However, on an invalid insert
of QTreeWidgetItem into QTreeWidget, the QTreeWidget does not take
ownership of the to-be-inserted items. These items were leaked in
the past.
This patch introduces a scope-guard, so the items are not leaked.
Change-Id: Ib53ac02605c3a3c0bd1ae69bbd0876f860d08093
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Several classes in QWidget use QDataStream internally in order
to save and restore state. These QDataStream usages were not
versioned, meaning that if Qt changes the serialization for some
datatype, then the data saved between different Qt versions becomes
incompatible. Note that the save/restore API in question just produce
opaque blobs as QByteArrays -- the user has no control over the
QDataStream objects and thus versions.
Fix by version the usages.
In QHeaderView this has caused a regression because QBitArray *did*
change version between Qt 5 and 6. In general, using QDataStream without
explicit versioning is a mistake, so deploy the same fix elsewhere as
well.
Fixes: QTBUG-99487
Pick-to: 5.15 6.2 6.3
Change-Id: I82bb5c266f4e5dedc0887cbef855dccab1015e29
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: <doctor.whom@gmail.com>
In a QGraphicsTextItem without a width yet, there's no need to do any
layouting. The use case is obviously items with an app-defined size,
not the default where text items adapt to their contents.
Results:
0.065 msecs to create a QGraphicsTextItem with some text (layouted)
0.036 msecs to set everything up in a QGraphicsTextItem with 0 width
QTextEdit was abusing the width 0 to mean "no wrap, width comes from
contents", but since the value -1 means that already in QTextDocument,
QTextEdit now uses a width of -1 for that meaning.
Change-Id: I67ad59c305e5dd34830886e4e6c56dde03c93668
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
A class that reimplements a virtual function isn't using the override
keyword, which generates a warning during compilation.
Pick-to: 6.3
Change-Id: Ic39ea24993e031f95ac9e61c3285d3be05fe6c34
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
We don't support it any more. I don't think it has ever properly
compiled Qt 6 (and it's no longer working for me against GCC 12's
libstdc++ headers). If you report a bug against it, Intel support's
first question is if you can try instead the new Clang/LLVM-based oneAPI
C++ compiler.
So we support only that one, which identifies itself as Q_CC_CLANG.
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb57a092c8439e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Remove a processEvents() call followed by a QCOMPARE and turn it
into a QTRY_COMPARE. Otherwise it seems to be randomly failing on Ubuntu
22.04.
Change-Id: I3c1b9d55c857c79ffd36aeb98971db60267adace
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Problem: if you create a hybrid Widgets and Quick Controls
application, you would need to use QApplication rather than
QGuiApplication. But in that case, the QQuickWindows would
never receive window activation events from QApplication.
And this causes problems for controls, since, for example,
the palettes in use there will never update upon activation
changes, and instead sometimes get stuck as e.g QPalette::Inactive
after application startup.
This patch will make sure that we send out activation events
also for QWindows that are not QWidgetWindows.
Pick-to: 6.3 6.2
Change-Id: I649f5c653081c0c5249f4faf28a7de2c92f17421
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Check DockWidgetArea permissions of QDockWidgetGroupWindows with single
dock widget. Obtain a dock widget's tab position from a dock widget
group window if it can't be established otherwise. Remove hardcoded
assumption that a dock widget is in the left dock. Both cases have lead
to inconsistent entries and dangling pointers in
QDockAreaLayoutInfo::item_list.
Remove warning: QMainWindowLayout::tabPosition called with out-of-bounds
value '0', which becomes obsolete by the fix.
Create a QDockWidgetGroup window prepered to become a floating tab,
whenever a dock widget is being hovered over. Store it in item_list so
it can be found and deleted when required.
No longer call e->ignore() after propagating close events to the first
dock widget and thus preventing others from receiving the event.
Add logging category qt.widgets.dockwidgets
Update dock widget autotest with tests to check the fixes mentioned:
plugging, unplugging, hiding, showing, closing and deleting.
Blackist closeAndDelete, floatingTabs test on macos, QEMU, arm, android
due to flaky isFloating() response after a dock widget has been closed
or plugged.
QSKIP dockPermissions and floatingTabs test on Windows due to mouse
simulation malfunction.
QSKIP hideAndShow test on Linux in case of xcb error (QTBUG-82059)
Fixes: QTBUG-99136
Pick-to: 6.3 6.2
Change-Id: Ibd353e0acc9831a0d67c9f682429ab46b94bdbb0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
tst_qmessagebox was disabled because it crashed.
It does not any more. Now it hangs, which
is a new problem.
Fixes: QTBUG-87671
Task-number: QTBUG-101217
Pick-to: 6.2 6.3
Change-Id: Iec15cf82a4112ee79182ec091622e40147bd3e7f
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This reverts commit b39d3cfe30.
Reason for revert: the test fails in dev again
Task-number: QTBUG-87404
Change-Id: Icc51e36e037e9c7e8154266def129dd8ad412775
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
To allow other cases to run while finding the reason. Most of these
cases fail only on CI and not locally.
Pick-to: 6.3 6.2
Task-number: QTBUG-102043
Change-Id: Ib552ab00b4232f6aabdf85acf050633251d9e71d
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Skip the crashing case temporarily to allow other tests to run
while finding a fix.
Pick-to: 6.2 6.3
Task-number: QTBUG-100470
Task-number: QTBUG-102043
Change-Id: I8b16f95e5c66b95cc9959494b5317d39d58194e6
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Commit a35a7fcb5a introduced the usage
of insets to correctly take into account the default Android status bars
and other reserved regions.
However in practice that does not work as expected - the bottom inset
is always reported to be non-zero, even when fullscreen mode is enabled.
To fix the issue, FLAG_FULLSCREEN is explicitly checked before applying
the insets.
Fixes: QTBUG-99624
Pick-to: 6.3 6.2
Change-Id: I8b25f0b06447cd452c42ef072493e3137e25f38b
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Fix some obvious issues, QSKIP or blacklist other problems.
This does not fix all the test failures, but allows to enable most of
the test cases, so that we could catch future regressions.
Task-number: QTBUG-87668
Pick-to: 6.3 6.2
Change-Id: I1ed0b476d4ac55c658c572cfa1379fcdc6137ee8
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Now when 71b3d18ea7 is merged,
we can re-enable the previously skipped tests, as they do
not crash anymore.
Task-number: QTBUG-101423
Task-number: QTBUG-101321
Task-number: QTBUG-87417
Pick-to: 6.3 6.2
Change-Id: I6b4b3619b0af5e48b5e92b514bc0ab6586a76d51
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
If the active QWidget gets destroyed, then QWidgetWindow::focusObject
will return nullptr. If then no other object takes focus, then we'd
never emit change signals, and QGuiApplication's _q_updateFocusObject
(which then informs the input context and emits signals) didn't get
called. This left the input context with a dangling focus object
pointer, which resulted in crashes.
If the QWidget clears its focus, but the corresponding window doesn't
know that it had focus, then fall back to the widget's focus widget
to see if we have a change in focus, so that signals get emitted.
Add a test case that shows that we didn't call _q_updateFocusObject
by counting emissions of the QGuiApplication::focusObjectChanged
signal, which we emit in this function. The signal is emitted more
than once both when showing a widget, and now also when destroying
a widget that has a focus child. The former is a previous issue,
the latter is an improvement to not emitting the signal at all.
Pick-to: 6.3 6.2
Fixes: QTBUG-101423
Fixes: QTBUG-101321
Change-Id: Ib96a397211d442f52ce795a3eebd055a0ef51b0d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Don't mix unsigned and signed types in comparisons.
Pick-to: 6.3
Change-Id: Ia4ba9c114177425a21cadc8cafe8179928315a5d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
After cbf1b4bc60bca3994b8f8685ee922e53a6b4eed2 the selected item got
deselected on Ctrl+Press, which made Ctrl+dragging a selected item
impossible.
Only deselect on Ctrl+Release. Add scenario to existing test case,
and update the documentation to clarify the properties involved, and
to point out that the event parameter might be nullptr.
Fixes: QTBUG-101647
Pick-to: 6.3 6.2
Change-Id: I749b1cb1a0a311f5c1d4c333984716f05f2c90b5
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Volker Enderlein <volker.enderlein@ifm-chemnitz.de>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Skip some of the obviously failing QCompleter-related tests instead of
blacklisting them.
Skip a test that causes a crash.
This allows to re-enable this test in CMakeLists.txt for Android.
Task-number: QTBUG-87417
Pick-to: 6.3 6.2
Change-Id: Ie7ee708df8ceddf117689e8ac749850ba86e8816
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The test is very flaky on Windows 11. Make sure that we have a secondary
window to close before proceeding, and wait for fade effects to finish,
otherwise we might never get the leave event from the windowing system.
Also replace a QVERIFY(qWaitFor) construct with a simple QTRY_VERIFY.
With these changes, a local run of 20 repeats of this test on a stressed
VM improves from 75% to 100%.
Pick-to: 6.3 6.2
Fixes: QTBUG-98477
Change-Id: Iedcc175b336e3cab23817b954aba1736d02f1b9d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Adapt to changes in QWidget::addAction API from 08e4d2db08.
Pick-to: 6.3
Change-Id: If6e05b47de88cf55070238f08b96586b855cc5c1
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This was lost when QtCore, QtGui and QtWidgets were split up. Restored
now via a virtual function on QObjectPrivate.
Chose to return std::string instead of QString or QByteArray because
its SSO is usually sufficient to hold these flag strings.
[ChangeLog][QtCore][QObject] Restored printing of Qt3-style
information from dumpObjectTree().
[ChangeLog][QtWidgets][QWidget] Restored printing of Qt3-style
information from QWidget::dumpObjectTree().
Fixes: QTBUG-101732
Change-Id: I39ff5728ea5f5abbdbf81b5d7e13b8d16b6ee8b7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Selection change handlers of the items might call a method that
implicitly recreates the selectedItems QSet, which then invalidates
the iterators of the ranged for loop, resulting in crashes.
Iterate over a copy of the set instead.
Add a test case that crashen without the fix.
Fixes: QTBUG-101651
Pick-to: 6.3 6.2
Change-Id: I6da6f4043fe1906b0186931a37283f635cb5a404
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
ClipboardManager didn't have any APIs to clear clipboard data before
API level 28.
As a workaround an empty Intent with MIMETYPE_UNKNOWN is created and
inserted into the clipboard for lower API levels.
This makes the QApplication::clipboard()->clear() method work more or
less as expected.
This allows to unblacklist tst_QPlainTextEdit::copyAvailable().
Task-number: QTBUG-87423
Task-number: QTBUG-89402
Pick-to: 6.3 6.2
Change-Id: I454376199cf3b8eed0fa2ecf2f85b87f40892280
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
