Finding a platform theme for the list of theme names happened in two
separate loops. The first loop checked for a platform theme plugin, the
second for a platform integration plugin. In case a theme name was
passed from the environment (with the -platformtheme command line
argument or by setting QT_QPA_PLATFORMTHEME), it was ignored if it was
a platform integration plugin and a platform theme plugin was found
in the first loop.
Combine both loops, in the assumption that the list of theme names
is always correctly prioritized.
Pick-to: 6.8 6.5
Fixes: QTBUG-134702
Change-Id: I2703236dc0f406aeb48529f8e53de76c394b7172
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 8ede178fd3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Retain elements when storing them in the cache, so that they only get
destroyed when they are neither stored as rows/columns, and removed
from the cache. If storing an element in the cache replaces a different
element with the same ID, release that before retaining the new one.
Give the insertElement() function a bool return value so that callers
know whether the element has been retained, so that they can correctly
release their own reference.
Release elements when they are removed from the cache so that it's
easier to see that the calls are balanced. For that to work, forward
declare QMacAccessibilityElement as an NSObject type.
A special case are place-holder cell elements. Those are not inserted
into the cache until the interface is requested, so when those get
inserted into the cache, we don't have a local reference to release -
it's the reference held by the rows/columns array.
However, we don't want stale elements in the cache, so when we release
the rows and columns arrays, also remove all cell entries from the
cache. Otherwise we end up with stale elements reporting outdated
values.
As this might invalidate references that our test object holds,
refresh the test object when triggering a model update.
Amends 1f7e926411.
Pick-to: 6.8
Fixes: QTBUG-134784
Change-Id: Ib3cce35058e4c80e3edc97ae578584610ee93487
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit b1ed5f656f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The feature doesn't require library nor dlopen support, even for
input context plugins (which work fine in static builds).
Task-number: QTBUG-135146
Pick-to: 6.8
Change-Id: Id171fccffa78f2d8233d800a6ea3469e9f440f79
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 5901f0ba09)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QSplitter::replaceWidget() is decumented to un-parent and return the
original widget (the one that the newWidget) replaces, so the caller
of the function is responsible for deleting it, which the test
function neglected.
Fix by storing the returned object in a unique_ptr for delayed
deletion at the exit of the function. This is the minimally-invasive
change.
Amends fb56a0f2ce.
Pick-to: 6.8 6.5
Change-Id: Ia63ebfde59b1c5ef8ddb6c3f3ab10b28d5bf6cff
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit f9d9630e9e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In the underline drawing code in QPainter there were
some issues causing
First of all, if an underline was very thick, then we would
still just offset the drawing by 0.5 (as if it were 1 pixel
wide) causing part of the underline to appear on top of the
text. The shift here is intended to move the top edge of the
underline to the top edge of the pixel where we want to
draw it, so we need to offset it by half of the actual line
thickness.
In addition, fractional line widths look bad when drawn with
aliased painting, which is the default. Depending on where
the text would be, the thickness of a line might vary. Even
if it's very close to an integer, e.g. 1.04 as in one case,
then it will still sometimes fill two pixels if it happens to
be placed directly between them. To ensure that we always fill
the same number of pixels, we round the line thickness to
nearest integer when antialiasing is not enabled.
Pick-to: 6.8
Fixes: QTBUG-134626
Change-Id: I95bae3ac16010fc133995e5f9b6c2e5d022e3743
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
(cherry picked from commit 2b5533af92)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
source_to_proxy (called by mapFromSource) was unconditionally
creating a mapping for the parent of the given source index,
even if that parent is in fact filtered out in the proxy.
That mapping would then just say "-1" for the (also filtered out)
child row.
Afterwards, inserting a visible child (which makes the parent visible,
in a recursive QSFPM) would see that the mapping for the parent
already exists and fail to update it properly.
Various symptoms could ensue, such as an out-of-bounds access in
gm->proxy_rows.at(source_parent.row()) in a subsequent call to
can_create_mapping (as I had on KMail startup for years, randomly) or
a visible child that fails to appear (as in the unittest).
Fixed by using create_mapping_recursive() which returns 'end' if
the row is filtered out, going up the tree if necessary to
create mapping for parents on demand (so that the call to
filterAcceptsRow is cached).
Fixes: QTBUG-76976
Pick-to: 6.8
Change-Id: I25a3bf6b147092c1231ab6441e636264fd0c4222
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
(cherry picked from commit 90a82ad8e5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The function can be called from ~QDialog(), in which case a cast of
q_ptr to QErrorMessage is UB.
Says UBSan:
errormessage.cpp:33:5: runtime error: downcast of address 0x7fff5089a6e0 which does not point to an object of type 'QErrorMessage'
0x7fff5089a6e0: note: object is of type 'QDialog'
00 00 00 00 30 74 4e 6a 12 7f 00 00 80 aa 00 00 90 61 00 00 08 76 4e 6a 12 7f 00 00 00 00 e0 1a
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QDialog'
#0 0x7f1267ce7d12 in QErrorMessagePrivate::q_func() qerrormessage.cpp:33
#1 0x7f1267ce7d12 in QErrorMessagePrivate::setVisible(bool) qerrormessage.cpp:410
#2 0x7f1267caaa25 in QDialog::setVisible(bool) qdialog.cpp:757
#3 0x7f12654efb28 in QWidget::hide() qwidget.cpp:8179
#4 0x7f1267caa239 in QDialog::~QDialog() qdialog.cpp:398
#5 0x7f1267ce72f8 in QErrorMessage::~QErrorMessage() qerrormessage.cpp:287
Fix by casting at most to QDialog* (QWidget* would actually have
sufficed).
Add a code comment.
Amends e0bb9e81ab (I think; it might
have been present in a different form before that).
Pick-to: 6.8 6.5
Change-Id: I61a8692f073c2d2f379ea02fa580f7fe46691c1c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 0e322aa419)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Same problem as in 49a87936ef, same fix:
hold the result of createTouchDevice() in an owning pointer.
Amends d15d9d49ac.
Pick-to: 6.8 6.5
Change-Id: I348336d82c167d95545c9e3d46e7479606605df9
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 4981333ff3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Similar to 5be58ac927 for tst_QWidget,
this test leaked the result of QStyleFactory::create() and the fix is
the same: cache across the test function calls. This time, it's for
performance; there's like 50 different data tags for this function...
Amends a8723871ee.
Pick-to: 6.8 6.5 5.15
Change-Id: I95cc1dc4459489904f3a5e0347570eb07ccdfde8
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 44a2d8cc20)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The old code created the top-level widget on the heap, without a
parent, so the test function leaked it.
Fix by creating on the stack instead.
This means we need to move the definition to before that of the child
button box (itself created on the stack), to avoid the double-delete
that would happen if the automatic parent would delete its QObject
child and then the compiler deletes the child again because it, too,
is an automatic variable. If, OTOH, the parent is declared before the
child, the child will have unregistered itself from its parent when it
was deleted.
Amends bbb71e7e80.
Pick-to: 6.8 6.5
Change-Id: I9489daace3bbbeecfaedcb5780a6b29a82c8d4ff
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 8352112e58)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A QButtonGroup does not own the buttons it contains, so this test
function leaked the button, despite a thing called "ButtonDeleter".
That thing doesn't _actually_ delete the button, it merely removes it
from the group.
To prevent the code from instilling same confusion in the next reader
as it did in this one, inline the whole thing and condense it down to
a single connect() statement, using a lambda.
Sometimes, another level of indirection (or two) does _not_ solve
problems...
Amends the start of the public history.
Pick-to: 6.8 6.5 5.15
Change-Id: I0002f0dd86d505d1aa089d696776051fddbf4c1e
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit bfefcec650)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
While a QButtonGroup is-a QObject, unless it has a QObject-parent, it
won't be deleted by, say, the parent of the buttons it contains, so
this test function leaked the QButtonGroup.
Fix by giving it the dialog as parent. This is just a QObject
parent-child relationship; it does not change the behavior of the
button group, nor the dialog, except that the latter now deletes the
former as its QObject child when it itself it deleted.
Amends e7cff5bca7.
Pick-to: 6.8 6.5 5.15
Change-Id: Ic633179252c72e7ee47a57be73944a6aa589637b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit ccd0ea0b4e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QCoreApplication::sendEvent() does not take ownership of the event,
postEvent() does, so this test function leaked the QKeyEvent it
created on the heap.
Fix by creating it on the stack instead. Add a scope to limit the
lifetime of the event object to just the sendEvent() call.
Amends the start of the public history.
This doesn't completely make the test asan-clean, it still suffers
from the QScroller::grabGesture() leak (QTBUG-135055).
Pick-to: 6.8 6.5 5.15
Change-Id: I8c93e03b2ea919ab80a1d508f008853779eb89af
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 0e314d3434)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Nothing was setting its proposedAction() and dropAction(), but they
were read in QGraphicsScenePrivate::cloneDragDropEvent(), leading
UBSan to complain about reading an invalid value for that
enum. Interestingly, Valgrind didn't find this issue, probably because
of the strong security options we're now activating by default for a
Qt build (stack protector, trivial-auto-var init, ...).
Says UBSan (excerpt):
qgraphicssceneevent.cpp:1591:15: runtime error: load of value 3200171710, which is not a valid value for type 'DropAction'
To fix, explicitly set the two properties on the locally-created
QGraphicsSceneDragDropEvent. I didn't go the way of "fixing" this by
initializing the members in QGraphicsScenePrivate, because the rest of
the test doesn't trigger any other error, so Qt itself is
well-behaved, and proactively initializing stuff prevent tools from
noticing inconsistencies.
Amends the start of the public history.
Pick-to: 6.8 6.5 5.15
Change-Id: Ibc9663e8afcd1f7ff9d0e3c646f70e0ceded67a9
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit c0dbfe6c87)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The old code cast the event to QTouchEvent* ahead of checking that it
actually is of a type() that suggests is-a QTouchEvent.
I'm not sure this was UB, because we weren't dereferencing the result
until after we checked type(). Then again, who am I to argue with
compiler writers (= same people that write ubsan)?
Says UBSan:
qstandardgestures.cpp:402:29: runtime error: downcast of address 0x7fffedb894f0 which does not point to an object of type 'QTouchEvent'
0x7fffedb894f0: note: object is of type 'QEvent'
ff 7f 00 00 c0 db 01 cf 99 7f 00 00 15 00 00 00 01 00 00 00 01 00 00 00 99 7f 00 00 b6 c4 14 f5
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QEvent'
Fix my delaying the cast until after we know that event is-a
QTouchEvent. All other recognize() overload already behaved correctly.
As a drive-by, use auto (RHS contains the type) and mark the result
const.
Amends the start of the public history.
Pick-to: 6.8 6.5 5.15
Change-Id: Ifa9e940232b93b2ecf666c35536519a8385c9800
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 03daf6685e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The TreeModel class was lacking the destructor, so the m_root TreeItem
was never deleted (it was held in a non-owning pointer and had no
parent).
Instead of adding ~TreeModel(), port to holding m_root in unique_ptr
instead. This creates a bit more churn, but communicates intent
better, and makes sure the item is never without an owner.
Amends e74af68654.
As a drive-by, fix the indent of the else clause of a ternary.
Pick-to: 6.8 6.5 5.15
Change-Id: I2f5c8852b8bee89c63933c118a4599d6a17de8e2
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 7cf8b2d030)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When, like in tst_QApplication::qtbug_103611(), a QApplication object
is destroyed without calling exec(), then QDesktopUnixServices leaked
its QDBusPendingCallWatcher, because the connection to the slot that
would deleteLater() the watcher was disconnected, and the watcher had
no QObject parent that would otherwise reap it.
Fix by actually deleting the watcher in ~QDesktopUnixServices(), if
it still exists (which implies disconnecting, of course).
This makes tst_QApplication asan-clean on Linux/X11 (was: "75466 bytes
leaked in 965 allocations").
Amends de609d84b9.
Pick-to: 6.8 6.5
Change-Id: I28a08abdb1be65a8746702ad304282de4e1100d7
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit 567da5e3e0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The commit that introduced the qt_saturate call did use that old
function in order to stay compatible with Qt 6.5, which never received
q26::saturate_cast. This patch ports to the new function in branches
that have it.
Pick-to: 6.8
Change-Id: Iadd9d2c92ea1e37095b71b1647db61dec2b8333a
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit b5a87a665c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When the test functions runs off the end (or returns from a failed
QCOMPARE/QVERIFY), `activeMenu` is destroyed while it's the
QMenuBarPrivate::activeMenu, and the following focusInEvent() on the
QMenuBar causes QMenuBarPrivate::setCurrentAction() to access
`activeMenu` when it has already ceased to be a QMenu.
Says UBSan:
qpointer.h:75:14: runtime error: downcast of address 0x7fff87934860 which does not point to an object of type 'QMenu'
0x7fff87934860: note: object is of type 'QWidget'
00 00 00 00 08 f1 0e be 17 7f 00 00 80 c8 00 00 90 61 00 00 b8 f2 0e be 17 7f 00 00 00 00 62 c6
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QWidget'
#0 0x7f17baf57be5 in QPointer<QMenu>::data() const qpointer.h:75
#1 0x7f17baf57be5 in QPointer<QMenu>::operator QMenu*() const qpointer.h:83
#2 0x7f17baf57be5 in QMenuBarPrivate::setCurrentAction(QAction*, bool, bool) qmenubar.cpp:351
#3 0x7f17baf5a200 in QMenuBarPrivate::focusFirstAction() qmenubar.cpp:245
#4 0x7f17baf5b727 in QMenuBarPrivate::focusFirstAction() qmenubar.cpp:1260
#5 0x7f17baf5b727 in QMenuBar::focusInEvent(QFocusEvent*) qmenubar.cpp:1259
[...]
#34 0x7f17b93373d6 in QWidget::~QWidget() qwidget.cpp:1508
#35 0x7f17badb4658 in QMenu::~QMenu() qmenu.cpp:1789
Since I couldn't fix the problem on short notice, I created
QTBUG-135151 to track it.
For now, simply close the QMenuBar on all exists from the test
function to avoid this code path.
Task-number: QTBUG-135151
Pick-to: 6.8 6.5
Change-Id: Id8c9ee090d8bbc5ec22ce3f2ff7485766640ab43
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 83af06b0e5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
So future-me and others don't have to look through the source code to
figure it out.
Pick-to: 6.8 6.5
Change-Id: I1f6e46cec256112226cad4d24ed52e4818635ae8
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit d2d74673f3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A QLayout that was removeItem()ed from its parent layout no longer is
deleted by it and has to be deleted manually, which the test function
failed to do.
To maintain the rest of the test function as faithfully as possible,
don't delete the layout right after the removeItem(), but delay until
the exit from the test function, using unique_ptr.
Amends 867c0b8d8a.
Pick-to: 6.8 6.5 5.15
Change-Id: Ia915d29bda348849033a6b9eb282dcb26a68c383
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 20d5a3cda9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QStandardItems that were taken out of their QStandardItemModel need to
be deleted by the caller, which this test function forgot to do.
Store the item in a unique_ptr, so it isn't deleted until after the
next populateModel() call. Deleting immediately may change what the
test function checks for.
Amends 6012285e7d.
Pick-to: 6.8 6.5
Change-Id: I45a0a2f598febc75fd9ef683525c973476dcd7e0
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit a8c55cb547)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
According to the XDND spec¹, the window-ID of an XcbFinished message
is in xclient.l[0]. That's Xlib terms, though. In xcb terms, it's in
xcb_client_message_event_t's data.data32[0]. This is how all QXcbDrag
functions handle it (e.g. move()), except handleFinished(), which
casts the uint32_t array to a (misaligned) ulong one.
¹ https://www.freedesktop.org/wiki/Specifications/XDND/#index29h3
(the fragment doesn't look like it's stable, it's the section
titled "XdndFinished (new in version 2)")
Says UBSan:
qxcbdrag.cpp:1051:12: runtime error: load of misaligned address 0x60400078ba9c for type 'const long unsigned int', which requires 8 byte alignment
0x60400078ba9c: note: pointer points here
c0 01 00 00 28 02 e0 08 01 00 00 00 c8 01 00 00 00 00 00 00 00 00 00 00 93 23 00 00 00 00 00 00
^
#0 0x7fa3ea3a957c in QXcbDrag::handleFinished(xcb_client_message_event_t const*) qxcbdrag.cpp:1051
#1 0x7fa3e9e20dec in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) qxcbconnection.cpp:607
[...]
I have a hard time seeing how it could have worked in big-endian
systems. In LE ones, it only works because the high bits of l[0],
which come from data32[1], are stripped again when the value is
narrowed for passing to findTransactionByWindow(). But the 'if' before
_could_ mis-detect a zero xcb_window_t for a non-zero one if data32[1]
wasn't empty...
To summarize: this is a mess (that's a technical term).
Fix by removing the pointless cast, and just read data32[0], like
elsewhere in the file.
Amends c3f9de62966d32d8e33d62eb374fe2657a4cfebe(!).
Pick-to: 6.8 6.5 5.15
Fixes: QTBUG-127517
Change-Id: Ie7c3718bada52ff82c16f814eee8ec57248fbfbf
Reviewed-by: Liang Qi <liang.qi@qt.io>
(cherry picked from commit 6ac40faa80)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The text interface, like textAtOffset, parses data coming
in from the user. Therefor tagging as security critical.
Task-number: QTBUG-134483
Pick-to: 6.8
Change-Id: I3c97813d4fba719e7972693510a0b9a78cb1348f
Reviewed-by: Lorn Potter <lorn.potter@qt.io>
(cherry picked from commit 26d950bb77)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
tst_QApplication::closeAllWindows() is blacklisted but does not seem
to fail anymore.
Unblacklisting the function.
Fixes: QTQAINFRA-6894
Pick-to: 6.8
Change-Id: Ia6157cc767a191121c4026f1c17edcad3b526d5c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit f386f83266)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If we build the specific module against installed Qt syncqt cannot
detect the installed module headers, since it only checks the build
paths. This adds the installIncludeDir argument for syncqt so it
now attempts looking for the included header file in Qt install path.
This will raise early warnings in Qt per-module builds too, but not
only when building top-level Qt or for non-prefixed builds.
Pick-to: 6.8 6.5
Change-Id: I5a28ec35a776b5b39f4a8923c9bf91e857f45e4a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 5a93c457e5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QIconLoaderEngine::paint() was still using QIconLoader::pixmap() to
retrieve the pixmap for painting instead QIconLoader::scaledPixmap()
which takes the devicePixelRatio as additional parameter. In the case
of icon themes this could pick up the wrong pixmap (from the wrong
folder).
Pick-to: 6.8
Fixes: QTBUG-135159
Change-Id: I69ceada35f36c64675c4147cf284a180a4c69915
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
(cherry picked from commit c5c6df40be)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This will be used in a new manual test in qt5.git, to show progress of
long-running commands.
Store the diff in a new patches subdir, to make it easier to re-apply
when we update the file from upstream.
As a drive-by, store patches from the previous modifications that were
done before this change.
Pick-to: 6.8
Change-Id: Ib73908e20fac7fe0bd620400d483625238fa37d1
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Le <cristian.le@qt.io>
(cherry picked from commit d8caf6d89f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Otherwise including only the private header leads to QT_CONFIG being
undefined.
Amends 38bb72720a.
Change-Id: I0960d38c98d64348ebf1cec481417bdb21eed9a6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 7293f05380)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It's easy to do and makes an unremarkable user error harmless.
In the process, add a comment to make QTBUG-112006 visible in the code.
Pick-to: 6.8 6.5
Fixes: QTBUG-135109
Change-Id: I6b9cb431bf5b005fc0f9cdbb5cf30c90fa1154c4
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
(cherry picked from commit f682406162)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The first-group minimum size limit is only relevant when there's
*only* one separator: a smaller group is allowed when there is a later
separator. QLocaleData::numberToCLocale() was, however, rejecting a
short first group without regard to what came later. Expanded two
grouping tests, that previously checked we *generate* correct strings,
to round-trip the strings and verify we get the right answer back.
Some of those duly failed. Fixed the parsing to check the right
condition on seeing a group separator.
That let valid groups get accepted. In the process, added some
test-cases that we do correctly reject invalid forms. Made sure the
fix also gets those right.
Pick-to: 6.8 6.5
Task-number: QTBUG-134913
Change-Id: Ifa5351adba4eec232917a343d4a73fb4656d1d32
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 754666dbe8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Although the number-parsing code to which the C-locale form is later
passed was already rejecting such malformed texts, it's better to
catch it earlier and to make the check overt in that parsing. Added
some tests cases that would fail if this wasn't checked; but they do
pass already in the parent.
Pick-to: 6.8 6.5
Change-Id: I5ef9e483317ce4dc519ddc7c4c016dcad5cb22c4
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
(cherry picked from commit f1d48552e4)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Thanks to Mate Barany for pointing out that the *_idx variables are
now all reduced to serving (via comparison with -1) as
booleans. Replace them with a "where in the parse are we ?" enum
variable and a "do we need some digits ?" bool.
Restructure to make that work. This needed to recognize (the letters
that make up) Inf and NaN so as to know when not to object to a lack
of digits. Since NumericTokenizer already has a matcher for those,
export its access to that as a public method and use that to simplify
its own uses of the matcher. Added some test-cases suggested by this,
that actually pass in the parent, as qt_asciiToDouble() could see the
result was malformed in any case, even when they weren't caught by bad
digit-group sizes (as "inf,000", "1,inf", "NaN,000" and "1,NaN" were).
Pick-to: 6.8 6.5
Task-number: QTBUG-134913
Change-Id: Ie1730530a4e34a76ba1836a25212e4ec27dad15f
Reviewed-by: Mate Barany <mate.barany@qt.io>
(cherry picked from commit d1879c3a39)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
It was a bit convoluted, making it hard to reason about parts. The end
of the whole number part can happen at the very end, after the loop,
or when we hit the exponent or fractional part. That means the check
of grouping rules at the end of the whole number part had to happen
after the loop as well as within it. To avoid duplication within the
loop, the handlingof exponent and fractional part was done within the
handling of grouping, reprising the exponent and fractional part after
they're handled earlier in the loop.
Package the decision-making for that handling in a lambda (and
document some relevant details there) so that the duplication is
harmless and move into the handling of the exponent and fractional
part separators, where it belongs. This lets the bulk of the loop body
simplify into a straightforward if/else-if cascade, making it easier
to reason about (in preparation for some imminent fixing of quirks and
corner cases).
Since reviewers needed to understand what the GroupSizes members mean,
in order to make sense of this, I've also added some comments to the
struct's declaration to at least let future readers know what's what.
This refactoring should be harmless and change nothing; it is also
needed by an imminent fix, that I shall pick back into LTS branches.
Pick-to: 6.8 6.5
Task-number: QTBUG-134913
Change-Id: Ib352aa9ab8341914e40d9c087b497db15a180ebb
Reviewed-by: Mate Barany <mate.barany@qt.io>
(cherry picked from commit cdcaaaeee3)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The test checks that the destroyed() signal is emitted, even in
exceptional cases. It has three degrees of freedom:
- blockSignals() or not
- QObject* or QWidget* as the connect() sender
- slot in a child of the deleted object or in an unrelated object
(one of the latter caused a leak of the DestroyTester)
The code was very repetitive and one scenario may have been checked
twice (QObject*, no child, blocked signals), which probably means we
forgot another (didn't check).
Make the test data-driven, and DRY further using templates for the
QObject/QWidget cases.
The leak fix is to use unique_ptr to hold the QWidget, and a scope
guard to delete the DestroyTester. I didn't want to use QPointer (or
qdialog_p's QAutoPointer), because we're checking a mechanism that
strikes very close to QPointer, and we should not depend on knowledge
of the exact QPointer implementation to convince ourselves that we're
not testing the same thing twice here. Besides, by making the delete t
conditional, we can use ASAN to detect if we got the need to delete
wrong.
Amends e72e5aa83a.
Pick-to: 6.8 6.5 5.15
Change-Id: I3bac9f81c33a24e1096041dfc3323e079fd46f8a
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 780c67ad80)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The result of QStyleFactory::create() must be deleted by the caller.
Some test functions stored it in a QScopedPointer, while others
didn't, each causing a leak of a QWindowsStyle object.
DRY the test functions (except the one that checks that 'delete
widget.style();' works) by introducing an owning pointer at the test
class level, to be reused by test functions. This is not so much for
caching the object across test functions (though this is a nice
benefit, too), but in order to keep the owning pointer out of the test
functions, and allow most functions to just do
setStyle(deterministicStyle()).
Found by ASAN.
On my machine, this test is now ASAN-clean, except a) the usual
cp-demangle.c leak and b) destroyedSignal(), which still leaks.
As a drive-by, pass a QStringLiteral instead of QL1SV to
QStyleFactory::create() and port one QVERIFY( != ) to QCOMPARE_NE().
No amends, it'd be too many. Not picking back far, because others
don't care, and I expect lots of conflicts when backporting, due to
many different amended commits.
Change-Id: Ie9e7faf21bc177e08af56c659dc58870ad3cf6ff
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 5be58ac927)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QAIM::createIndex() takes a const void* pointer, so we don't need to
const_cast the const away.
Amends the start of the public history.
Picking all the way back, because I'm hunting a memleak here, and
can't say, yet, whether these lines need to be modified or
not. Besides, this change is 100% safe: either it compiles and works
as before or it doesn't compile. There is no silent breakage possible.
Pick-to: 6.8 6.5 5.15
Change-Id: I2f9284540beed9d1ab027ac1e24f1c527537e122
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 9f2db4acd7)
Reviewed-by: Daniel Smith <daniel.smith@qt.io>
In QtWindow class, the Touch Event coordinates were increased by Layout
position. That allows to move to global coordinates.
In the same time, in 15674f4ce9 commit, we
started mapping coordinates of Touch Event to Global position. That
cause the issue with incorrectly handled touches for example with
QDialogs.
To avoid this issue, we will stop modify Touch Event position in JAVA
code. We will send only localPosition to not make transformation twice.
With this change, all events received from JAVA have local position of
their window.
Pick-to: 6.8
Fixes: QTBUG-130576
Fixes: QTBUG-127925
Change-Id: I6b58e0369959840f869e31a3d96425c64507b39d
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
(cherry picked from commit 23fd2cfb01)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
In the touchAdd method, the mapped touch point is divided by the
platform integration screen size.
In order not to mix different coordinate systems, we should use
platformWindow to correctly calculate global position of touch event.
Pick-to: 6.8
Task-number: QTBUG-130576
Task-number: QTBUG-127925
Change-Id: Ic7653a60fb3def181f29a3e28b963878dc54a99e
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
(cherry picked from commit 01d25533b4)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Amends ceb859bf03
We'd accept negative values and keep counting downwards, reaching 0
again only after a full underflow[*]. Effectively, this meant that a
negative value was the same as zero, so this makes the behavior
explicit. The commit introducing checked_var_value() said in its
changelog:
For compatibility reasons with previous
versions, if the variable is set to any non-empty and non-numeric value
different from 0, Qt will understand as "stop on first warning".
Negative values are not "non-empty and non-numeric", so this commit
chooses to make the current behavior explicit.
[*] atomic under- and overflows are defined behavior, but only if the
atomic operation is the one producing it. The current code is doing the
subtraction by itself in the call to testAndSetRelaxed(), so underflows
are still UB. If/when this is replaced by atomicMutate, that might
change (and note to self when implementing that!).
Pick-to: 6.8
Change-Id: I594ed31f1cc7fc04ea98c6e86bdcaa3a4aa59114
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit c8ecd0eb22)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Amends commit b933a5668c ("Make sure we
don't count down past 0 QT_FATAL_CRITICALS"), which introduced the CAS.
Apparently it was a design decision then that only one thread would call
qAbort(), while the others would happily continue. For example, for the
common case of QT_FATAL_WARNINGS=1:
// T1 T2
v = n.loadRelaxed() // v = 1
v != 0 // true
n.testAndSet(v, v - 1, v) // n = 0
v = n.loadRelaxed() // v = 0
v != 0 // false
return v == 1; // false
This commit changes that design, for two reasons. First, a semantic one:
if one thread has detected a fatal condition, it must be equally fatal
for all threads. Second, we must accept a meaningful time between the
detected condition and the call to qAbort() and thus the time until its
effects take. In the worst case scenario, T1 could get suspended
indefinitely, at which point T2 having concluded that warnings weren't
fatal will happily execute forever. [This could happen *because* of
having called abort(), and though that's a SW bug elsewhere, we should
not let our other warnings and criticals continue.]
The fix is simple: we never decrement from 1. That way, if multiple
threads start their verification at the same time, they will all see the
value 1 and will all abort. The abort() standard library function is
thread-safe, as our replacements for it.
Pick-to: 6.5 6.8
Change-Id: I03fbcbac26bd1f34d631fffd43bb9c27d51783d0
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 6e37cd4176)
Reviewed-by: Daniel Smith <daniel.smith@qt.io>
The view that's being created in init() is not a
protected_QHeaderView, but only a "normal" QHeaderView, so casting it
to protected_QHeaderView is not valid.
Says UBSan:
tst_qheaderview.cpp:3338:37: runtime error: downcast of address 0x604000087050 which does not point to an object of type 'protected_QHeaderView'
0x604000087050: note: object is of type 'QHeaderView'
00 00 00 00 d8 d2 e6 0b b2 7f 00 00 80 88 00 00 c0 61 00 00 08 d6 e6 0b b2 7f 00 00 00 00 be be
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QHeaderView'
Fix using the usual trick: forward-declare tst_QHeaderView and make
QHeaderView itself befriend it directly.
Amends bff78163f6.
tst_QHeaderView is now asan/ubsan-clean, except for some signed
overflows in calculateAndCheck(), filed QTBUG-135201 to track it.
Pick-to: 6.8 6.5 5.15
Change-Id: I718695bef26e72f442bd677c6bad05bab561163f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
(cherry picked from commit 8beaab9483)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
I have no idea why setOffset() would accept all int values, but
tst_QHeaderView::getSetCheck() checks the function with both INT_MIN
and INT_MAX (albeit without having show()n the object it so tortures),
so try to make it work(-ish).
0 - INT_MIN overflows, of course, so use saturation math to calculate
the result. This might not scroll to pixel precision, but it couldn't
have done so before, either (no int value can possibly represent the
mathematical value, otherwise it wouldn't have overflown). But at
least we now don't run into UB anymore.
Said UBSan:
qheaderview.cpp:418:9: runtime error: signed integer overflow: 0 - -2147483648 cannot be represented in type 'int'
#0 0x7f183ffa4a5f in QHeaderView::setOffset(int) qheaderview.cpp:418
#1 0x55f5ca56a5fe in tst_QHeaderView::getSetCheck() tst_qheaderview.cpp:437
While q26::saturate_cast was only picked to 6.8, its predecessor,
qt_saturate(), was picked to 6.2, so use that, for now, and port to
q26::saturate_cast in a follow-up.
As a drive-by, mark ndelta const.
Amends the start of the public history.
Pick-to: 6.8 6.5
Change-Id: I118c917ccd588c0b6d407090609f4d17075bbab6
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 03d1e81516)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Says UBSan:
qabstractitemview.cpp:4442:18: runtime error: downcast of address 0x604000026790 which does not point to an object of type 'QAbstractItemView'
0x604000026790: note: object is of type 'QWidget'
00 00 00 00 08 b1 cf 9f 33 7f 00 00 80 24 00 00 60 61 00 00 b8 b2 cf 9f 33 7f 00 00 00 00 be be
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QWidget'
I did not reserch what the problem was that the code comment referred
to, but we now have QWidgetPrivate::get() (incl. in 5.15), so use
that.
Amends the start of the public history.
Pick-to: 6.8 6.5 5.15
Change-Id: If658d21694f6806eafdf678b8d5ff7ed62e93513
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
(cherry picked from commit 3b3b5968d0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>