We always need to set the QMenu screen explicit also when
it is about to be shown on the primary screen.
The reason is QWidget::metric (called from style/sizeHint)
may use qApp->devicePixelRatioF() when it does not
know about the topLevelWindow. That may not be the same
value as DPR on primary screen. It can be argued that
it likely is a bug in QWidget::metric, but fixing that
looks to be a somewhat dangerous behavior change.
Task-number: QTBUG-59794
Change-Id: I6ed0e808aa31bee5b77c0e19ce61a77548fdbb38
Reviewed-by: Morten Kristensen <msk@nullpointer.dk>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
... just like -xcb does implicitly. Otherwise, failure to detect
system-xcb would silently fall back to -no-xcb despite obviously
contradicting the user's request (-qt-xcb always worked anyway,
as there is no test that can fail).
Change-Id: I6f3145fac0881e7847c4a70547fce206e797a9bb
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This is a follow-up commit to 97eec16e.
Blackberry tries sending touchpad events first, and if not consumed,
it sends synthetic mouse wheel events as a fallback. This makes touch
keyboard scrolling work in native Android ListViews and other views
that do not handle SOURCE_TOUCHPAD motion events. Qt apps, however,
blindly accepted all generic motion events, so synthesized mouse wheel
events were never sent. => Make QtSurface & QtNative accept only those
motions events that are actually handled.
Task-number: QTBUG-51165
Change-Id: Iefbbf1e3e1cc3da86afc4c87c19671cc6c5fa145
Reviewed-by: Kai Uwe Broulik <kde@privat.broulik.de>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Since removeAll() takes its argument by cref, if passing a reference
to an element of the container to removeAll(), the element may be
deleted (overwritten) by anyother value, leading to UB.
Add a test that actually happens to fail for me without the patch,
even though that might not be guaranteed (we may invoke UB).
Change-Id: If8c795113aeb515f4a9bdf1e072395b932295667
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
On iOS we want all delivery of events from the system to be handled
synchronously, as that's what the system expects.
We don't need to add a delivery template argument to each function
in QWindowSystemInterface that we want to delivery synchronously;
that's only needed for functions that a platform normally sends
asynch, but in some cases want to delivery synchronously.
For always delivering events synchronously we just need to change
the default delivery method.
The only events affected by this are the screen changes, and
window state change, which were not synchronous before, but
should be. All other events were already synchronous, though
either explicit delivery, of a flush.
Change-Id: Ib20ca342d1c076be0fbcf018c83735a416769cfe
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
We have had test.qt-project.org for close to 3 years now.
Change-Id: I71488efd29b645f7b228fffd14fadf4627288243
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
WSARecvMsg does not return the sender in WSAMSG::name if WSAMSG::Control
isn't set. This makes no sense, so I'm assuming it's an API quirk we
need to work around.
[ChangeLog][QtNetwork][QUdpSocket] Fixed a regression from Qt 5.9.3
caused by an apparent Win32 API quirk we triggered when using
readDatagram(), resulting in an invalid QHostAddress sender address.
receiveDatagram() was not affected.
Task-number: QTBUG-64718
Change-Id: I71488efd29b645f7b228fffd14f9d84cc205c4b3
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Allows categorized logging before QCoreApplication has been created,
which otherwise would silently fail to output anything because the
category would never be enabled, despite QT_LOGGING_RULES being set.
Change-Id: I1861e5366ea980dff2ffa753b137276c77278eee
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Unary ~ is not defined for enum classes, so we need a cast.
Change-Id: I79d495ebcc24ab960da8dae3be08eb307a9de448
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When processing host lookup error if-statement only checks the connection
type SPDY, which is not right - it could also be HTTP/2. As a bonus:
QT_NO_SSL conditional inclusion is not needed - HTTP2 can be 'clear text'
and SPDY enumerator is defined even in no-tls build (and is just a
noop here). Also, improve our somewhat cryptic message in 'Should not happen'
else branch - 'cannot dequeu' says nothing about HostNotFoundError.
Task-number: QTBUG-64721
Change-Id: Ib0346b8717c2dbddaffab690298f3cae01e338ea
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
... and unblacklist it on Windows.
From what I can tell there is no particular reason why this test fails
other than that it is a little too slow sometimes (these things happen).
So, to fix the test I bumped the timeout, but to avoid the test running
for longer on every test-run it now also ends when the socket enters
the "Unconnected" state.
Previously it failed 171/500 times, and after this patch it failed
0/1000 times.
Change-Id: I4266bff6b91aaaf502ee66265d01c3a177706402
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
Calling QCoreApplication::applicationDirPath() requires an app instance,
but on Windows the implementation just relies on qAppFileName(), which
does not require any instance. As resolving the standard paths could
be needed before QCoreApplication instantiation, e.g. for categorized
logging, we use qAppFileName() directly.
Change-Id: Id882cebd528bcb8e945e73a83f1dc3d599b74d1d
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
When an app is in split-view mode, the app can't use the full bounds of
the screen, but should limit its area to that of its UIWindow.
Task-number: QTBUG-48225
Change-Id: Ia66ad6bba24d9d73a8263ad3f65b9dee9b8a1b37
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
Fusion style did not honor direction option when drawing the child
indicator. This lead to a wrong rendering of QTreeView in right-to-left
mode.
Task-number: QTBUG-63396
Change-Id: I2d5de03d7c831e3caabcc9269617eecb9338f163
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
If -mavx2 is used, __AVX2__ is defined, which enables the F16C code
after commit 280e321e52, but that was
wrong since we aren't allowed to use the F16C intrinsics with either
Clang or GCC (we can only do that with GCC 4.9 and Clang 4.8, and only
with an __attribute__ decoration).
With ICC and MSVC, we are allowed to use the intrinsics, but the
#include was missing.
[ChangeLog][QtCore] Fixed a compilation issue with qfloat16 if AVX2
support is enabled in the compiler. Since all processors that support
AVX2 also support F16C, for GCC and Clang it is recommended to either
add -mf16c to your build or to use the corresponding -march= switch.
Task-number: QTBUG-64529
Change-Id: I84e363d735b443cb9beefffd14b8ac1fd4baa978
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Make sure we don't run into warnings for CMake 3.10
Task-number: QTBUG-63442
Change-Id: Ida004705646f0c32fb4bf6006036d80b1f279fd7
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Sebastian Holtermann <sebholt@xwmw.org>
Reviewed-by: Rolf Eike Beer <eb@emlix.com>
... and unblacklist it.
It was blacklisted some years ago because it was failing too often.
It was failing because the ssl socket had already received and decrypted
all the data it was going to get, meaning the waitForReadyRead call was
just going to block forever.
Change-Id: Ia540735177d4e1be8696f2d752f1d7813faecfe5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
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>
The private class already store a QNetworkConfigurationManager
and networkSessionRequired so it's not need to compute them again
nor to instantiate temporary classes.
Change-Id: I1bbd9439afa70c950ed6ec3e4fc63ddae4a5b259
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This test became a real pain recently. A close look at the test shows
several problems (strangely enough, the failure can never be
reproduced on real machines, only on VM - Ubuntu and RHEL 6.6).
There are several asserts that are firing from time to time here and
there. They show that the logic in test is broken/incorrect. QNAM can
open several connections to a host, our test then incorrectly resets
its 'client' data-member and bad things can later happen after
'bytesWrittenSlot' executed (and deleted a socket). For example,
I can reproduce this scenario in every second run:
1. incoming connection -> client = socket(descriptor), connect to
client's readyRead (s1)
2. incoming connection -> client = socket(descriptor), connect to
client's readyRead (s2)
QNAM sends a request on s1. We reply on s2 (which is already wrong)
and call client->deleteLater(), which resets client to nullptr.
If QNAM sends something else on s1, we hit assert(!client.isNull()).
To avoid this, whenever 'sender' in any slot is different from the
'client', we use the actual 'sender' to reply. Another problem is this
weird and rather cryptic waitForFinish which is not needed in this
particular test since we wait for reply error, not 'finished'.
As it happened before - it's not clear if these two problems
were the cause of guaranteed fails on CI - an integration failed
~10 times in a row in the same test (not happening anymore though).
Task-number: QTBUG-64569
Change-Id: Id9aa091290350c61fadf1c3c001e7c2e1b5ac8f4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It results in Xcode outputting a warning when debugging:
[app name] was compiled with optimization - stepping may behave oddly;
variables may not be available.
And the warning is correct, debugging is broken in this situation.
Likely caused by Clang treating -Og as -O1:
https://reviews.llvm.org/D24998
Change-Id: I25d6bf1e65c81cc5be92b9847f7d5dd6754a0177
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
655687d84d shuffled things around, moving the logic to connect
to the window's destroyed signal from backingFramebufferObjectFor into
makeCurrent. Unfortunately backingFramebufferObjectFor was the one taking
care of recursing into the root context (when shared contexts were in
play), so the end result was that the root context were keeping track
of the FBO, but the leaf context was trying to clean up the FBO.
Task-number: QTBUG-56653
Change-Id: I80ed71a3dedeb7611b2aa7548d94b9fbe0e20763
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Using QWindowSystemInterface::SynchronousDelivery reduces the chance
that we are flushing other events before delivering the application
state change. Those other events may conclude that the application
is still active, while in reality it is not, and do bad things.
Change-Id: I738c162fac22d2cd18de1e080bcd2cda78ec3f77
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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>
QTableView::paintEvent() drawed the grid lines behind the last section
when the region to repaint contained rects which were completely
behind the last section.
This also lead to unnecessary repaints for cells inside rect.top() to
rect.bottom()
Task-number: QTBUG-60219
Change-Id: I42bb42bea504dfd3c92352ac5c65a43c246a05af
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Any attempt to create a non-null QPixmap in a QCoreApplication-based
app would give a hard crash without a warning. This commit adds a
check and instead calls qFatal with an explanatory message.
This was originally fixed in Qt 4 (ref. QTBUG-17873) but that was lost
in the migration to Qt 5.
Note that this fix still allows null QPixmaps to be created under
QCoreApplication, since that has worked in all Qt 5 versions.
Task-number: QTBUG-53572
Task-number: QTBUG-64125
Change-Id: I60ae29b90f1bd3663aeed2ce88dc1690fe66552c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This test makes sure that we do not introduce a regression where the
threads exited the inner loop over the queue before the queue was
empty. This was triggered by calling tryTake at least maxThreadCount
times, which left the same number of null pointers in the queue
and caused the inner loop to exit too soon for all the threads.
Change-Id: I3a9d800149b88d09510ddc424667670b60f06a33
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
A "sealed" package is a *release build and signed* Qt for Android package
with no debugging capabilities.
By default sealed packages have no debugging capabilities, but the user
can force debugging capabilities also on a sealed package. This is useful
in corner cases when the user really needs to debug a sealed package.
Change-Id: I840526092556067f2659facf1525861bbabe0edd
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The verifySessionProtocol() method in the SecureTransport backend did not
properly handle TlsV1_0OrLater, TlsV1_1OrLater and TlsV1_2OrLater.
This commit teaches verifySessionProtocol() about them.
It also adds TlsV1_0OrLater, TlsV1_1OrLater and TlsV1_2OrLater to the
protocolServerSide() test in tst_qsslsocket.
Backport from 5.10 to 5.9 (LTS).
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 9c765522d1)
Change-Id: I58c53bdf43e0f19b4506f3696d793f657eb4dc6f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
httpReply->setHeaderField does not simply append (name|value) pairs,
it first erases all entries with the same name. This is quite
wrong when we have _several_ 'Set-Cookie' headers, for example.
Found while trying to login into a facebook account :)
Task-number: QTBUG-64359
Change-Id: I51416ca3ba3d92b9414e4649e493d9cd88f6d9a0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
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>
When looking for the primary index, it is possible that the
constraint_name in the all_ind_columns table does not match that of the
index_name. Whereas the index_name will match in this case, so the query
should set the where clause on the index_name in both tables.
Task-number: QTBUG-64427
Change-Id: I1bf1fb580e620b9f75f2fde1ecf408842e377365
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
Looking at the failures in grafana it appears this test is also failing
on Windows 64. The same fix applies then, and we use Q_OS_WIN now.
Change-Id: Iafcfd6d1e747f3c816878cad072fbfae3aee19ca
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The issue was introduced by eaee1209f0, so
it affected only 5.9.2.
[ChangeLog][QtCore][QSemaphore] Fixed a regression that would make
tryAcquire() not to wait forever if the timeout was a negative
value. Note: new code is advised to only use -1 to indicate "forever",
as some other functions taking timeout periods do not accept other
values.
Task-number: QTBUG-64413
Change-Id: I57a1bd6e0c194530b732fffd14f58fce60d5dfc9
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Setting style name to "Regular" and then setting bold to true, results
in platform depending behavior, and should be avoided.
Also removes comment about style name not working on Windows, it has
been working since 5.8.0.
Task-number: QTBUG-63792
Change-Id: Ie5be7215a673f5751dbeb6512df8ec7bfaef4d0a
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
To obtain "proper" directory behavior, we have to check against the
extracted "resources" directory instead of its qrc counterpart.
Change-Id: I4996ba74419945f78d356ad953a5b826ff663687
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
To obtain the file's handle, we need to obtain it from the extracted
test data instead of qrc.
Change-Id: I89c5c3f3a7da7e36205a439581a6d83efffdc07c
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
