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>
Resource files are extracted to m_dataDir in tst_QFile::initTestCase.
Instead of trying to access the file from the resource on systems that
use qrc for bundling the test data, we have to use the files that were
extracted at the beginning of the test.
Change-Id: I35453fbdeb27e317d1342ff1cb7bbea9cebea14d
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
On some platforms (like UWP) files that are copied during
qfile auto tests are not writable by default. The cleanup will fail for
these files if the permissions are not set accordingly.
Change-Id: Id925dcadfc6b505c87f1f55d5ea05e286b60a5a5
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Ceiling width/height fails to take into account rects that do no have
their top left position on an exact point boundary.
Example: QRect(0,0 20x20) and QRect(1,1 20x20) with scale 2.0 would give
the same result of QRect(0,0 10x10). The correct rects are QRect(0,0 10x10)
and QRect(0,0 11x11), so that we are sure to repaint all pixels within the
exposed region.
Before 5138fada0b, rects were also rounded incorrectly. The old method
would give the result of QRect(0,0 11x11) in both cases, causing the
exposed region to be larger than a window.
Amends 5138fada0b
Task-number: QTBUG-63943
Change-Id: I9f3dddf649bdc506c23bce1b6704860d61481459
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
So far we just write ... '.'. , which looks weird.
Change-Id: Iac6fc781c80976994ea0a182b55958baa39a7e52
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
This patch works around Windows X86 on QEMU antics.
It appears on this platform the test behaves in some unpredictable manner:
- WSAConnect with 255.255.255.255 does not always immediately fail with
some error, so socket engine waits for a connection timeout (30 s.),
but the test itself
- only waits for 5 seconds and then tests that a request has finished with
error, which is not true (we are still connecting).
To make it work - whenever we have bearermanager feature enabled, set
a connection timeout to something reasonable, not 30 s.
Since we try to connect to each address twice, make timeout 1.5 s
(so it's 3 s. in total and still is < 5 s.).
Task-number: QTBUG-64264
Change-Id: I1d40c140667fca8402ec9344e66d313b6df54256
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
- Blacklist ioHttpRedirectPostPut for Windows
- Amend 84396a3f93:
Keys need to be on subsequent lines
Task-number: QTBUG-62583
Change-Id: I6360ec7bd87de65a3294a0d22148f13579fcd292
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Clang compiler defines fallthrough, but wrongly detects QT_HAS_CPP_ATTRIBUTE(fallthrough).
This makes compiler breaks compilation due clang be expecting
clang::fallthrough.
Change the order makes the exceptions. clang/gnu, been tested before
the generic, setting then proper defines at end.
LLVM-bug: https://bugs.llvm.org/show_bug.cgi?id=33518
Change-Id: Ic287e9028936af3bdade5c1ee319ca8914b36ea7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Contrarily to what the comment stated, we actually rely on automatic
menu validation, even for submenu items. This is visible in the menu
delegate's validateMenuItem: and itemFired: methods.
This solves the last visible issue in BigMenuCreator where, under
ASP/ASP, ASP/SAP, SAP/ASP and SAP/SAP, all A*S submenus would be
disabled. The cause was an incorrect target/action setup.
Menurama still behaves as expected.
Change-Id: I2599d6fb0d51f56f5d36f03b69647e35ff6c550a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
In QMainWindow::setMenuBar(), we hide and schedule the current
menubar, if any, to be deleted later. However, it remains installed
as its whole ancestry's event filter, which could conflict with the
newly assigned menubar until the old menubar is destroyed. In our
case, we have noticed issues with the Cocoa QPA plugin.
We force uninstalling the old menubar as event filter by setting its
parent to null, pending its deletion shortly after.
This fixes BigMenuCreator's empty menubar when calling it with only
the "--new-menubar" option. It also fixes QTBUG-34160 example which
was not behaving as well as it should.
Task-number: QTBUG-34160
Change-Id: Ifefb72affad01e7b7371005442074afd6a39a5b8
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
When one of the menubar actions changed, we would omit to
update several properties on the platform menu, most notably
its title.
Manual tested with BigMenuCreator, where the sequence
menu->addAction(action); // A-operation
action->setMenu(submenu); // S-operation
would result in an "Untitled" menubar item on macOS, and this
regardless of when the submenu is populated.
Change-Id: I43989f36f6bf3f0b7056310ac986c06f8e02f128
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This saves 32 bytes per instance on 64-bit macOS, from 888
down to 856 bytes.
Change-Id: I2592631aa3566d2eab72bad338aacfe76bee8ef3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Xcode 9 introduced the main thread checker, which detects invalid
use of AppKit, UIKit, and other APIs from background threads.
https://developer.apple.com/documentation/code_diagnostics/main_thread_checker
In our case these are accesses to e.g. [UIView layer] and
[UIScreen scaleFactor] from the render thread of QtQuick,
things we should look at, but that might not be easily solvable.
In any case, these are not warnings the user can do anything about,
so in lack of a per-library disable of the checker, we have to
globally disable it for the whole Xcode project.
Task-number: QTBUG-63822
Change-Id: Ibfcdf23891cf6bfbbc9b9b3349e4c256c273c7de
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The glyph cache resize is clearly doing something that is not actually
legal with OpenGL ES. Until this gets investigated properly, add the
Vivante GC2000 (found in the commonly used i.MX6 quad) to the list since
reports show that the issue occurs there as well.
Task-number: QTBUG-49490
Change-Id: Ia890346d8dbb1691bc113e2ef522713ba6709393
Reviewed-by: Louis Kröger <louis.kroeger@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
All code should be using the license header in header.BSD or header.FDL
now. If modules still use outdated headers, they should be fixed or
as a stop-gap measure add header.BSD-OLD, header.FDL-OLD files locally.
Change-Id: If462f1646ab413c18d2d3c61197773dca2a036ec
Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
I updated signals and slots and for each loops to the new syntax and
replaced most free functions with std::function.
Task-number: QTBUG-60641
Change-Id: I7693f81f71c7f53fcbe83189a0de2fb76ddf99a8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Similar to the problem found in QTcpSocket auto-test recently.
While the failure on CI looks differently (apparently, server process
starts but does not print anything), fixing the dependency does not
hurt and at least fixes the 'make check' scenario.
Change-Id: I8f29f3e492d22410533407a527f5fc8f664e7f5c
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This fixes an upstream bug in the existing version 1.6.32 which would
cause certain valid png files to be rejected.
The remaining diff to clean 1.6.34 is archived in the qtpatches.diff file.
[ChangeLog][Third-Party Code] libpng was updated to version 1.6.34
Task-number: QTBUG-63950
Change-Id: Ie6f2a09c78a93b6e5623848776b75650bb5bca66
Reviewed-by: André Klitzing <aklitzing@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
This test was failing recently on Windows 7, mingw, x86. It's not
failing now and attempts to reproduce the failure on CI's VM were
unsuccessful. Anyway, just reading the code is enough to spot
race-conditions: two threads are accessing two shared boolean
variables without any protection.
It's unclear if these races were the reason why the test was failing,
but we fix them for good anyway. Also, a failure to start a thread
or to start listening on a TCP socket is not treated as XML-related
failure anymore and QSKIPped instead.
Change-Id: I5115ce6c33cafc91485f8cf6e7e268d954976556
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
