Introduce a special hash modeled on the one used for QFileSystemWatcher
on Windows.
Task-number: QTBUG-31103
Task-number: QTBUG-64147
Change-Id: I69ebabe841716e4957ae3fb04fa5c43d233a3552
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QHeaderViewPrivate::_q_layoutChanged() was not called when used in a
QTreeView because it was explicitly disconnected in setModel().
The disconnect was added sometime prio to Qt 4.3, but there the signal
was connected to the doItemsLayout() slot. This was correct since
QTreeView::doItemsLayout() is calling header->doItemsLayout().
In Qt 4.3.0 _q_layoutChanged() was introduced and the disconnect was
adjusted. But since _q_layoutChanged() is doing much more than
doItemsLayout() (e.g. restoring hidden sections), functionality was
lost. The problem was already observed for Qt 4.6 (QTBUG-18196) but
only partially fixed.
Task-number: QTBUG-41124
Task-number: QTBUG-54610
Change-Id: Id13a9930d0163812e12a0287016bab9c3aa02068
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
Autotest is taken from the previously reverted
8b1377fde1.
Task-number: QTBUG-60231
Change-Id: I44dd79cba22b6baefdd6d95c176790bef0b7eafe
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The test is flaky on Linux.
Task-number: QTBUG-64639
Change-Id: Iec56ebce4f656f52187b34c8f655b137e41c3d17
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
The tests start to show flakyness on Linux in 5.10 (rowCount() check
failing). This seems to point to a race condition between the files
showing up and the file system watchers of QFileSystemModel starting.
To fix this, close the file and wait until it shows up in the directory
before pointing the QFileSystemModel to it. The tests then no longer
rely on the file system watchers.
Change-Id: I39cffb4cacf6843e8e4180efb405345307c78dd8
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
A layoutChange indicates that anything can have moved to anywhere else,
including as a result purely of new items being added. It can also
indicate that items are removed.
The old code here incorrectly assumed that the section count remained
constant over this operation by setting the size of the oldSectionHidden
QBitArray - whose size is the size before the layoutChange operation -
and then calling setBit with model rows numbered after the layoutChange
operation. As the two are not necessarily the same dimensions, this can
result in asserts from the setBit call.
Simplify the handling of layoutChanged entirely by clearing section
information, and using the QPersistentIndexes which indicate hidden
state to restore that state after re-population.
Task-number: QTBUG-53221
Change-Id: I3cda13e86b51b3029b37b647a48748fb604db252
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
Since the first item in a treeview might be hidden, start from the
first visible item in the view when starting or wrapping round
during a keyboard search.
Task-number: QTBUG-63869
Change-Id: I202bea567c6d4484c3ffaf8a5f9af8ea2e13708d
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
When calling QTreeView::hideColumn() the row heights are not
recalculated. This can lead to rows which are unnecessarily high due to
hidden columns may contain large (e.g. multiline) content. The same
applies to showColumn() - there the row might be to small.
Hiding columns directly via QTreeView::header()->hideSection() is not
covered by this patch since QHeaderView has no way to inform about
newly shown/hidden sections.
Task-number: QTBUG-8376
Change-Id: I20b1198e56e403ab8cf649af76e5e2280821dd68
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Also blacklist tst_QNetworkReply::ioHttpRedirectErrors(too-many-redirects)
on RHEL 6.6 in CI.
Conflicts:
tests/auto/network/access/qnetworkreply/BLACKLIST
tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
Task-number: QTBUG-64569
Change-Id: I7514fc0660c18fd3a3e1d0d0af3f15d879e3c6f4
As it stood, we would set 'pressed' to false regardless of which button that
was released. This would end up wrong if pressing the left button, and
at the same time, did a click with the right button. This would clear the
flag prematurely, and cause a release signal not to be emitted when later
releasing the left button.
tst_QAbstractButton: adding autotest
Adding tests to simulate the bug report's cases:
1) left press button
2) click right/middle key
3) move mouse out of button's boundary
4) test if the released() signal triggered properly
Taks-number: QTBUG-53244
Change-Id: Ifc0d5f52a917ac9cd2df5e86c0475abcda47e425
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
on Ubuntu_16_04 and openSUSE_42_3.
Task-number: QTBUG-64446
Change-Id: If8fff2823f041428852822470a2f00157795558b
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
The vast majority is actually switched to QRandomGenerator::bounded(),
which gives a mostly uniform distribution over the [0, bound)
range. There are very few floating point cases left, as many of those
that did use floating point did not need to, after all. (I did leave
some that were too ugly for me to understand)
This commit also found a couple of calls to rand() instead of qrand().
This commit does not include changes to SSL code that continues to use
qrand() (job for someone else):
src/network/ssl/qsslkey_qt.cpp
src/network/ssl/qsslsocket_mac.cpp
tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
Change-Id: Icd0e0d4b27cb4e5eb892fffd14b5285d43f4afbf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Resizing a QTreeeView section with double click or
resizeColumnToContents() does not respect the maximumSectionSize when
the resize mode is Interactive or Fixed. Since the documentation of
maximumSectionSize states that it should honor this property for those
cases either the documentation or implementation is incorrect.
This patch fixes the latter.
Task-number: QTBUG-64036
Change-Id: Ic14c8e444d50b9c50a117efed19d0bca7ec1cf82
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The test showed flakyness on Linux. It has been observed that its
windows overlap. Position the windows beside each other.
Change-Id: I4ff1b9cafaf753a6844b3dfabb576a07f74b396a
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
... by moving them in QTestPrivate namespace (qtesthelpers_p.h). This
header file is a convenient staging area for helper APIs, eventually
some could be moved to public QTest API.
This header file utilizes the same pattern as other qtestlib header
files - wrapping functions with QT_${LIBNAME}_LIB to automatically
enable certain APIs based on what is in the projects dependencies,
e.g. QT += widgets.
Change-Id: Ic0266429939c1f3788912ad8b84fc6e0d5edd68b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This test is flaky on Unity due to regression introduced by QTBUG-39362.
Skip the test functions until QTBUG-39362 is resolved.
These test functions do not fail on Gnome and KDE, so the functionality
tested by check_cursorKeys* will be covered by other linux distributions
in CI.
Change-Id: Ifd1a7779a9728142424f4956dd6466c822ccde91
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
If a window is blocked by a WindowModal dialog, it should not be
possible to trigger window shortcuts on that window if it receives
a WindowActivate event.
This currently happens if the blocked window gets clicked, because the
window becomes the active_window and then QApplication sends it a
WindowActivate event (this doesn't happen with application modal dialogs).
The correctWidgetContext() function calls QApplicationPrivate::tryModalHelper()
only if the shortcut context is ApplicationShortcut. This patch makes it
call even if the shortcut context is WindowShortcut.
Change-Id: Iff87d85bcae603a6a24128e0cedfa9d33b6485fd
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Make the function brace policy consistent.
Change-Id: Iaf1f05a63958f19927e9b1953da06f99a4eba644
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Add some helpers to convert the coordinates and change the code to use the
QWindow-based mouse test API. Remove mouse presses on the second and third menu
from task256322_highlight() since moving the mouse is sufficient to switch
menus.
Remove blacklisting/skipping of macOS and offscreen.
Task-number: QTBUG-63988
Change-Id: If3e94170d11df369aec199d13d54d39382a78723
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
tst_noqteventloop.cpp 'event' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtreeview.cpp 'canFetchMore' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtreeview.cpp 'fetchMore' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtreeview.cpp 'hasChildren' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtreeview.cpp 'rowCount' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtreeview.cpp 'columnCount' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtreeview.cpp 'index' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtreeview.cpp 'parent' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtreeview.cpp 'data' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtextedit.cpp 'begin' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtextedit.cpp 'end' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtextedit.cpp 'updateState' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtextedit.cpp 'drawPixmap' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
tst_qtextedit.cpp 'type' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
Change-Id: I2a0c5da15994619383c1f90fee311927e58d7af0
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
... the same way other tests do in this file.
Change-Id: Ifcaee084bd20c55d6b9f7ddcf35daebce2a02e07
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Currently on Windows, the Next button's shortcut doesn't work, because
QWizard overrides it with an empty key sequence.
The key sequence should be changed only if isVistaThemeEnabled() returns
true.
Task-number: QTBUG-46894
Change-Id: I54f26388b167973cc8065a867d9e771c1e6a2a72
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
QAction::setData() always emits changed() even without actual data change.
Original code lacks a guard to check if the data changes.
According to http://doc.qt.io/qt-4.8/signalsandslots.html,
adding guard also benefits to prevent infinite looping in case
of cyclic connections.
Task-number: QTBUG-62006
Change-Id: I776369b668082f9f02e4502a36b1ae234ee7e079
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Tests should not use QCursor to emulate mouse move, see QCursor::setPos() docs.
The flakiness of the test on XCB is not surprising when the test queries geometry
even before the window has been shown. With the re-factored version I could not
reproduce flakiness anymore.
Removed Q_OS_MAC and closed QTBUG-26274 as test passes on macOS from which I
assume that the underlying issue has been fixed.
Removed Q_OS_QNX ifdef as test does not rely on QCursor anymore.
This patch also fixes the issues on minimal / offscreen platform plugins.
QCursor::setPos() is evil for auto test purposes.
Note:
We intentionally use QTest::mouseMove(QWindow *window, ..), not the QWidget overload.
The QWindow version gets routed through QWSI, which ensures that all necessary events
are generated as expect. In QWidget code path this is currently disabled by
QTEST_QPA_MOUSE_HANDLING.
Change-Id: I285c26cff09e3f2750f8c2abbb1f46c8f7be984a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 1af927976a)
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
On macOS, absence of a QPA menu means that we should be using our
own internal logic since there's no entity on the QCocoaMenuDelegate
to take care of the shortcuts.
Change-Id: I35ed8f0b55445f61d0528709d4debb636a502002
Task-number: QTBUG-61039
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Unique begins with a "y" sound, hence a unique is correct.
Change-Id: I9eb6b4d4c9ddab45af931e97c041c24edf163eca
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
The autotest has been blacklisted for RHEL 7.1 and RHEL 7.2 earlier already
and it is still failing in 7.4.
Task-number: QTBUG-46116
Change-Id: I0f33be849513a2debaf8c093dcd413fa09b5c681
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
The qWaitFor functions themselves can not trigger a test failure, as that
will not result in the test function exiting early, so every single call
to qWaitFor needs to be wrapped in a QVERIFY.
Change-Id: Id15a1549f31d06cdbf788e1d84ea431c28636ec8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We can't qWaitForWindowExposed on native menu bars. Other test
functions in this file are already disabling the native manu bar.
Task-number: QTBUG-24326
Change-Id: Iecf907ca84589159417d0d942c911485a41af164
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
A "compound widget" is a widget that has a focus proxy set to an inner
child. This is normal for complex black-box components where focus handling
is delegated to the children. Since the compound can have several
children, a local tab order might exist between them.
The current implementation of setTabOrder had no idea about
compound widgets. As such, when connecting two compounds in the
tab chain, it would just break up their inner tab order and
cause tabbing to ignore children other than the proxy.
The new implementation recognizes compound widgets, and add some
extra code to figure out the correct tab targets. This way, the
local tab order between the children will be preserved.
This implementation was inspired by the patches of Marek Wieckowski posted
in the linked bug report, and later modified by Nikita Krupenko.
[ChangeLog][Widgets] QWidget::setTabOrder() will now preserve the local
tab order inside a widget if it has a focus proxy set to an inner child.
Task-number: QTBUG-10907
Change-Id: I0673d39d70ec8c6bf64af30bf978d67c651b2f3c
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
QWindowContainer assumed that a widget could never change from
native to non-native. This is not a fact when the window container
is reparented to toplevel and back. In this case, usesNativeWidgets
would be stuck at true, and parentWasChanged() would go down the
native widget path, triggering an assert.
The solution is to always recalculate the usesNativeWidgets bool.
Task-number: QTBUG-63168
Change-Id: I88178259878ace9eb5de2ee45ff5e69b170da71c
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Błażej Szczygieł <spaz16@wp.pl>
By the time we call setKeyboardMode(true), the menu may
already have taken focus. This change sets keyboardFocusWidget
before opening the popup, and makes sure that keyboardFocusWidget
is not set to the popup. (We cannot remove the assignment from
setKeyboardMode(), since it's called from several places.)
[ChangeLog][QtWidgets] Fixed widget losing focus after showing
menu second time.
Task-number: QTBUG-56860
Change-Id: Ic01726bf694e6f365dd7b601ad555156e0fdf6c5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When tabbing/searching for the next focus widget, the current
code would check if the next widget in the focus chain
had a focus proxy, and if so, ignore it. The exact reason
for this behavior is not clearly understood, but some widgets
(e.g QSpinBox) has children (a QLineEdit) that sets the parent
as focus proxy. If we didn't ignore children with focus proxy, tabbing
from a QSpinBox would lead us to find the inner QLineEdit, which
(because of its proxy), would lead us back to the QSpinBox. And
therefore not be able to tab out.
But ignoring the focus proxy has other problems. Normally a focus
proxy is the next sibling to the widget it acts as a proxy for, and
tabbing to the widget will therefore appear correct. But if the
focus proxy is not the next sibling, the logic will fail, since
the tab would anyway give focus to the next sibling. This becomes very
apparent if the focus proxy is a child of the widget, since then
its likely that the focus proxy is not the _first_ child among all
the children. So tabbing to the parent would not give focus to
the proxy.
This patch will change this logic so that you are allowed to tab to a
widget with a focus proxy. But we check that if you do so, you actually
end up moving focus in the right direction. If not, we ignore it like
before. This will ensure that we tab correctly when dealing with focus
proxies, and especially when focus proxies are used to construct
compound widgets.
[ChangeLog][Widgets] When tabbing to a widget with focus proxy, focus
will now be given to the proxy rather than just being ignored.
Task-number: QTBUG-10907
Change-Id: I66d1da5c941fdd984bb2783cc355ca65b553b5dd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Due to the complex event forwarding logic between QCompleter,
QComboBox, QLineEdit and QWidgetLineControl, in some cases the
same single user return key press could result in duplicated
activated() signals being emitted by QComboBox. The first one
would be emitted because QLineEdit emitted editingFinished()
as a result of QCompleter::eventFilter() having forwarded the
return key press event to QComboBox. The second one, would
happen right after, as QCompleter::eventFilter() would process
the same event on behalf of its popup.
(We recall that QCompleter is installed as its own popup event
filter. That's also the case for the completer's widget, although
the purpose there is limited to focus-out events).
The current fix consists on skipping the emit as a result of
QLineEdit::editingFinished() if the completer's popup is still
active. For this to be accurate, it helps to test whether the
completer's popup is visible, so we will not be hiding it in
QWidgetLineControl::processKeyEvent() anymore. Indeed, we know
that if the popup is visible, that means that processKeyEvent()
was called after being forwarded by the completer's popup event
filter. Furthermore, the popup will be hidden by its event filter
shortly after it returns from said event forwarding call.
Based on a patch by Alexey Chernov <4ernov@gmail.com>.
Task-number: QTBUG-51858
Task-number: QTBUG-51889
Change-Id: I013f6c3000ae37b5b0ec20eaf5cf7746c9c903e3
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This autotest is blacklisted as it is deemed flaky.
Task-number: QTBUG-63262
Change-Id: I216985e81d1c1cb3528fd8a005be48cad2a31ab7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
