This test was blacklisted in 5.10 on opensuse, but it fails a lot on
ubuntu as well. While we are discussing a real fix for this, temporarily get this out of
the way.
Task-number: QTBUG-63152
Change-Id: I4f1d3b261013052636ee13eda30f94b647a43a38
Reviewed-by: Sami Nurmenniemi <sami.nurmenniemi@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The peer Tests for QDBusAbstractAdaptor are so flaky that it's
very difficult to get any commits through to qtbase.
Task-number: QTBUG-66216
Change-Id: I8da80f71aa832e683f72129cb2d4785425d39c00
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Sami Nurmenniemi <sami.nurmenniemi@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Timeouts with subsequent failures to delete the temporary
directories have been observed in COIN.
Previously, QProcess:terminate() was used to end the processes,
which does not have any effect on console processes on Windows.
Add a helper function which resorts to kill() on failure
to terminate().
Change-Id: I05539d1703280d34b392f2e8ff8565b9a04d703c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QFontEngine::cloneWithSize() is used by QRawFont internally when switching
a raw-font from one size to another using setPixelSize. For CoreText, we
use a subclass of QCoreTextFontEngine to keep track of the QByteArray data
of a raw-font, but failed to overload cloneWithSize, so we would lose the
data whenever setPixelSize was called, resulting in missing text rendering
in QtWebKit. We now retain the data as we should.
Task-number: QTBUG-65923
Change-Id: I7d4186a3c32a61d48d1e9388e43f2792e8e46081
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Actually check that there's a T where ISO 8601 wants it (instead of
just skipping over whatever's there), with something after it; move
some declarations later; add some comments; and use the QStringRef API
more cleanly (so that it's easier to see what's going on). Simplify a
loop condition to avoid the need for a post-loop fix-up.
This incidentally prevents an assertion failure (which brought the
mess to my attention) parsing a short string as an ISO date-time; if
there's a T with nothing after it, we won't try to read at index -1 in
the following text. (The actual fail seen had a Z where the T should
have been, with nothing after it.)
Add tests for invalid ISOdate cases that triggered the assertion.
Task-number: QTBUG-66076
Change-Id: Ided9adf62a56d98f144bdf91b40f918e22bd82cd
Reviewed-by: Israel Lins Albuquerque <israelins85@yahoo.com.br>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit a9c111ed8c)
QHeaderView is doing a complete rebuild of the sections when the layout
changed because everything could have happened. But since layoutChanged
is also called during e.g. sorting, the old data must be restored when
possible.
Task-number: QTBUG-65478
Change-Id: I088d4d843cad362b97df6dc5e0dcb9819b13547f
Reviewed-by: Thorbjørn Lund Martsum <tmartsum@gmail.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Passing -1 to waitForReadyRead() may cause it to wait for some time
but the data retrieved may be enough for processing. So if 0 is passed
from read, indicating that there is potentially more to come, then
it will do a waitForReadyRead() then for more data to come.
Change-Id: I75f270d1f124ecc12b18512cc20fb11f7a88f02e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The Embedded Android build (Boot to Qt Android injection) is defined by
having both Q_OS_ANDROID and Q_OS_ANDROID_EMBEDDED flags defined,
as well as having Qt config android-embedded.
This commit enables the possibility to build embedded Android builds.
(i.e. Qt build for Android baselayer only, without JNI)
Change-Id: I8406e959fdf1c8d9efebbbe53f1a391fa25f336a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
For Q_OS_WIN, a path is only truly absolute if it includes a drive
letter; merely starting with a slash is not enough. (We can't support
UNC paths, so don't even try: qmake runs various commands in the
source directory using CMD.exe, which doesn't support UNC as PWD.)
This requires, when resolving a path relative to a root, transcribing
the root's drive to such not-quite-absolute paths.
Changed QMakeGlobals, $$absolute_path() and $$relative_path() to now
use IoUtils::resolvePath() rather than delegating to QDir's absolute
path method, since that doesn't correctly recognize the need for a
drive letter (and qmake did run into problems with some paths, from
splitPathList and a failing test, as a result).
Moved existing ioUtils tests for handling of relative / absolute paths
out into separate functions and expanded significantly. Fixed some
existing tests to use an absolute path where one is needed; added two
tests involving driveless (but rooted) paths; and fixed the test init
to set a value for QT_HOST_DATA/src property (the lack of which lead
to an assertion failure with this fix).
Task-number: QTBUG-50839
Change-Id: I2bfc13c1bfbe1ae09997274622ea55cb3de31b43
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
We have the ability to blacklist tests for CI runs now.
Task-number: QTBUG-35109
Change-Id: I8590e83faba764dce2d52e8c62e2e2c63f7bf219
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The code used to fall back to anonymous login independently for username
and password; however, it should only use a fall-back password if the
username is missing or (case-insensitive) "anonymous". When a
non-anonymous username is given without password, we should simply skip
he PASS message to FTP.
If the FTP server requests a password, in the latter case, QFtp will
signal authenticationRequired; in all cases, if the server rejects the
given credentials, QFtp signals authenticationFailed. Either way, the
client code can then query the user for credentials as usual.
Task-number: QTBUG-25033
Change-Id: I2a4a3b2725819ab19c8a7e4baa431af539edcd8d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
After we stopped sanitizing the fallback font list (with change
6ca48a847a), we now need to make
sure it is ordered so that the fonts that support the writing
system in question are always tested first, otherwise we can end up
loading a lot of fonts that will never be used.
Task-number: QTBUG-65605
Change-Id: Id2a65bbff3e64e6d6e6b4f72500778ee3e811e84
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
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>
Old header.LGPL21 header was used at some files. Replase those with
new header.LGPL one
Remove old header.LGPL21
Task-number: QTBUG-57147
Change-Id: I650e39024ed4876bba27e954c7d61fdb025b46ef
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When we request fallback fonts, we cannot discriminate the fonts
based on the writing system support. This is especially important
since common script is now merged with other scripts, meaning that
a common script character will always go through the fallback
mechanism when not supported by the main font. When drawing
for instance a string of Devanagari characters on macOS, we would
get a list of 33 fallback fonts, but almost all of them would be
the default Devanagari font, since none of the other fallbacks
would support that script. Meaning that we would just check the
same font over and over, which makes no sense. The fallback list
has been retrieved specifically for the given script, so we do
not need to consider that when fetching the fonts.
For most of the common set, we will not have noticed the bug,
because at least one of the writing system-specific fallbacks will
have had support for latin characters as well. But when trying to
mix emojis and some non-common script, we would get a box in
place of the emoji, which had been adopted to the main script and
would only be looked for in the fonts supporting this.
Note that this exposed an issue with the QRawFont test on some
systems. When the sample text contained a space, it would
be possible to get a fallback font for this character, since
we now effectively support fallbacks. This is not the correct
behavior, but it is unrelated to this fix, and it was not what
the QRawFont::unsupportedWritingSystem() test was written to
check. I have therefore removed the space from the sample text
to make the test pass, and will make a separate task of fixing
the issue of merging fonts for whitespace characters.
[ChangeLog][QtGui][Text] Fixed a bug where mixing different
writing systems with emojis could lead to missing glyphs.
Task-number: QTBUG-61882
Change-Id: I00f6043bb01af1f2277723ccf643034aebf3e18f
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Remove black-listing of test; the problem was due to misconfigured
time-zone on the CI system - it was on some zone that presently
coincides with UTC, not actually on UTC as supposed.
This reverts commit 597b96b8fa.
Change-Id: I72ad1dfa38532362c05aef33cd874f7f79879a41
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
tst_QUdpSocket::broadcasting and tst_QUdpSocket::pendingDatagramSize
fail on the new Ubuntu 16.04 clean template.
Task-number: QTBUG-65440
Change-Id: I0e973b9c90b7c5827406bac8138370b61992a115
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
This autotest fails on the new Ubuntu 16.04 template with UTC timezone
in the system settings.
Task-number: QTBUG-65435
Change-Id: I397f01ab3fed354a4eeec8b05415226a75fce5a1
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
On Windows, QFileInfo.isWritable() was returning true in situations
where the file would only be writable with elevated privileges. Using
AccessCheck instead of GetEffectiveRightsFromAcl to get the correct
results.
Done-with: Friedemann Kleint <Friedemann.Kleint@qt.io>
Done-with: Edward Welbourne <edward.welbourne@qt.io>
Task-number: QTBUG-30148
Change-Id: I7a3468ac069bf782ca312078e3a84107b6cd468c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
old style connects have protection against null sender and null receiver,
but new style only had against null sender.
Change-Id: Ie555ac078412918e60c3b60830fe1f3abfb7f5af
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
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>
If a signal is emitted more than once in a multithreaded application the
QSignalEventGenerator::execute function asserts in the check for a valid
signal index. It happens after abandoning the state and all the
connections are disconnected. If we have pending signal to be
processed the QObject::sender() won't be able to resolve the sender
object.
Task-number: QTBUG-61463
Change-Id: I9d4b7266c6dddc9ff2e7453b05a6989876ccb332
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Autotest is taken from the previously reverted
8b1377fde1.
Task-number: QTBUG-60231
Change-Id: I44dd79cba22b6baefdd6d95c176790bef0b7eafe
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
I broke it in commit 4da2dda2aa. It wasn't
flaky or anything: it was plain broken and would never pass. That
indicates no node in the CI has an IPv4 link-local address (and
apparently neither did I at the time).
Change-Id: Ifb5969bf206e4cd7b14efffd14fb62176546916e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
FreeBSD, for example, does not have SO_NREAD and its FIONREAD returns
the full socket buffer size, including IP and UDP headers.
Change-Id: Ifb5969bf206e4cd7b14efffd14fb5d8ca778d16a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
A mysterious file c:\dev\null appeared when running the auto tests on
Windows. Fix by using QMAKE_SYSTEM_NULL_DEVICE.
Amends 5f3529be32.
Change-Id: I0224a9ccd61c4f10b2ddb8f8d690e1849aa88d8a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
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>
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>
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>
... 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>
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>
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>
