Part of this test was skipped on Mac OS X, due to a bug in timer
handling. This bug has been fixed[1] and the test now passes again.
[1] https://codereview.qt-project.org/#change,21953
Task-number: QTBUG-24319
Change-Id: Iad0a315cfdfcfb007e8aa9243cfef4b2f2b33895
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
This test is like qguieventdispatcher, it duplicates a corelib test in
the gui test suite, since the QtGui library often gets a different event
dispatcher implementation from the platform plugin.
Change-Id: Ifd724066950bc3b98a804bc2e5d40ce7b0429af4
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The failure was fixed by commit e430ddfafc
and the test has not failed again in the >500 CI builds that have
occured since that commit was merged,
Task-number: QTBUG-23061
Change-Id: I41063f9dbc6b6d7d6b99f1a0c20708b0842353d5
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
The number of paint events is correct now, but the first expected region
is still incorrect. Move the XFAIL to the region comparison.
Change-Id: I3e706cf703b20a0e98b644b3082172fc3142b44f
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
QTimeLine appears to have very poor timing characteristics. Historical
CI logs show roughly one failure in every twenty-five test runs on
Windows, and less frequent failures on Mac and Linux.
The root of the problem seems to be that QTimeLine's currentTime
counter appears to run at a variable speed and the only guarantee is
that it is slower than wall time. The frameChanged() test
function waited for double the expected duration of the timeline and
still found that the timeline had failed to finish in about one in every
thirty test runs. The interpolation() test function also failed for the
same reason, though less often.
This commit makes the frameChanged test more strict so that the poor
timing will be demonstrated more often, waiting only 1.5 times the
duration instead of double the duration. It also makes the test fail
gracefully so that this known issue won't disrupt CI when the test is
made significant in a later commit.
Task-number: QTBUG-24796
Change-Id: If469d43abb662e24445a9da619052eea9cf7c581
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
QTimeLine::currentTime() is an integer in the range [0..duration], not a
float in the range [0.0..1.0]. The aim of the test appears to be to
verify that currentTime() is at least 90% of the way to duration() when
the timeline is almost due to finish, so verify that and give the
corresponding 10% tolerance on reaching the end state.
Change-Id: I38646947c3b9189a4e8e91a450c6071430ddc66a
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
This test hangs ~2.6% of the time in CI.
Task-number: QTBUG-25342
Change-Id: I2c3531140e15edfe2dc2524e101b84e3206a4e61
Reviewed-by: Kalle Lehtonen <kalle.ju.lehtonen@nokia.com>
When destroying a window immediately after showing it, we can sometimes
provoke a crash in Cocoa after the show-window-animation has finished
(which appears to assume that the window's view will always be valid).
Prevent the crash by not removing the view from the window. When
recreating a window, we explicitly release the old window, but we do not
release the view, so we can freely add it to the new window (i.e. this
does not introduce new bugs related to recreating the platform window).
Task-number: QTBUG-24977
Change-Id: I466ce75b04785401032a0a2d4a2c494910cd1672
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
Otherwise, the order of updating of the indexes will cause
inconsistent results because it will rely on ordering within a
QHash (which is indeterminate).
Task-number: QTBUG-25325
Change-Id: I7d99578c8ee2954b8562dc5aff7dc32e74d41fb5
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This test has not failed in the last 500 Continuous Integration runs.
Task-number: QTBUG-22769
Change-Id: Ib2e95bb2291757941baa0ea46d568816eef20b09
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
This makes it easier to find insignificant tests that have no associated
bug report.
Change-Id: Ia71d59da062818d3860b0365d063e044705267fd
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
When encountering a null preprocessing directive (which is supposed to
be ignored), the moc preprocessor will leave a PP_NEWLINE token in the
token stream. That will confuse the parser.
The PP_NEWLINE token need to be ignored in the preprocessing phase.
Task-number: QTBUG-22717
Change-Id: I1e502a7e5bc6fa8ce2f82109ba7199b95747ff0a
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Lots of uses of the annotations and error names, plus a bunch of local
unit test names (including one file that had to be renamed).
The meta object generator is updated to support both the old and new
names. That means some references to com.trolltech *must* remain in the
source code.
Task-number: QTBUG-23274
Change-Id: Icc38ae040232f07c437e7546ee744a4703f41726
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
Reviewed-by: Lorn Potter <lorn.potter@nokia.com>
Change the old com.trolltech ones to org.qtproject and introduce Use
the alternate domain name for the Qt Project because the dash
character is not valid in interface and error names.
Task-number: QTBUG-23274
Change-Id: Iac1699e70525d67f983c10560932acff6b2ecde6
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
The testChildrenLayoutsChanged fails randomly. This happens rarely,
f.i. wasn't spotted by CI when QHash randomization itself was merged;
but is indeed reproducible by running the test a few times in a row.
This is now blocking api_merges integration, and I have no idea
how to fix it.
This patch marks the test as insignificant for now (the bug
tracking this test failure is QTBUG-25325), and switches the failing
tests from QVERIFY(a == b) to a proper QCOMPARE (so that the
expected values do show up in the build logs).
Change-Id: I16f0e28bcbb06dbac2e7169f4676a19ccf626a92
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
http://unicode.org/versions/corrigendum6.html:
> in Unicode 5.0, the list of characters with the Bidi_Mirrored property
> was made consistent for brackets and quotation marks, in preparation for
> new constraints on bidi mirroring. However, after publication of
> Unicode 5.0.0 it was discovered that this change adversely affected
> several quotation mark characters in deployed data.
Task-number: QTBUG-25169
Change-Id: Id49caf401af2d5a1e6dbcc32b2f350aa20b7f901
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
The test fails consistently on the CI (but never fails on any
of the developer machines). This is possibly a timing issue.
Change-Id: Ie40d9c38c3128a93898b0e50bfde5a754bd2b7fb
Reviewed-by: Giuseppe D'Angelo <dangelog@gmail.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
The key returned by QHash::key is an arbitrary one that maps to the
given value. The test instead relied on it being a specific one.
Change-Id: I090351797e8b52036d78160fd810518a11e8107d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Applied Bill King's suggestion in QTBUG-1363. Columns of
hStmt must be accessed in order.
Verified using ODBC driver on SQL Server 2005 on Windows 7.
Added test for length of text field for MS SQL Server over ODBC.
Task-Id: QTBUG-1363
Change-Id: I6673dafe75e3ef394d41e439adb45096c1421068
Reviewed-by: Bill King <bill.king@nokia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
The hash autotest is wrong: it assumed that the iterator on the hash
would reach the end after iterating on two elements with identical key.
But three elements were added to that hash, and the third one
can appear after the other two.
That code path is left for the map test only.
Change-Id: I51de7987e2b132b6caff7bb4bac6a57fb7fcb530
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I have run the test 250 times in each of these configs with no
crashes observed, so assuming the instability has been fixed
by another change.
ubuntu 11.10 64 bit
ubuntu 10.04 32 bit
windows 7 msvc2010 64 bit (debug)
windows 7 msvc2010 32 bit (release)
Task-number: QTBUG-20686
Change-Id: I02bab165c263cf79684c7723eae1e278839b1e37
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
Just XFAIL the failing test instead of ignoring the whole test.
Task-number: QTBUG-25272
Change-Id: Iedca9913032f13c6610b049a0313c9e4336216e0
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Just implementing the ### Qt5 suggestion about making
controlTypes a virtual function.
Change-Id: Ic1db47fe488f089de965438e456e9b48e0b96f32
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This test has been XPASS'ing since a long time now.
Change-Id: Ibfcd1b5078e0b8efed9ed0740a4238d24ef8ca33
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
That was a regression introduced in 1c5db1aff
Example:
signals: int *someSignal();
would produce this code:
int* _t0 = int*();
which does not compile
So have special handling for pointer to change it to '= 0'
Change-Id: Ie695e15e309d15c3cfd5c5a69ac8bf6d61ae9915
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
This test hangs 2-3% of the time.
Task-number: QTBUG-25284
Change-Id: I32e01696262be2de7e015b8f811d1666551426cc
Reviewed-by: Toby Tomkins <toby.tomkins@nokia.com>
The new QUrl is able to distinguish a URL component that is empty from
one that is absent. The previous one already had that capability for
the port, fragment and query, and the new one extends that to the username,
password and path. The path did not need this handling because its
delimiter from the authority it part of the path.
For example, a URL with no username is one where it's set to QString()
(null). A URL like "http://:kde@kde.org" is understood as an
empty-but-present username, for which toString(RemovePassword) will
return "http://@kde.org", keeping the empty-but-present username.
Change-Id: I2d97a7656f3f1099e3cf400b199e68e4c480d924
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
This test no longer fails, so we can remove CONFIG+=insignificant_test
Task-number: QTBUG-22767
Change-Id: If3ca194fc982ad8fdc3e9a7f62fc346190ff01ea
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
This test no longer fails, so we can remove CONFIG+=insignificant_test
Task-number: QTBUG-22766
Change-Id: I379873d5c483157e414201e5f8a13c3f4407f9fd
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
This does not fail anymore, remove CONFIG+=insignificant_test
Change-Id: I4f98cfad563adfa460910976317c91e852db6872
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
I can't say for sure why q*linecontrol passes an empty rect to
the updateNeeded() signal when an input mask is set; presumably
the empty rect at some point has meant "full update", but there
are a few problems with this. Surely a full update is wrong,
even if the semantics have been lost in translation somewhere
(likely the qlinecontrol refactoring). This fix ensures
that empty rects from updateNeeded() are interpreted as a request
to update the whole widget. A further improvement would be to
ensure the line control doesn't request a full update when an
input mask is set. The cursor is usually wider when a mask is
set but because of QLineEdit::paintEvent()'s implementation,
there is currently a mismatch between the cursor width as seen
by q*linecontrol and what is actually drawn, which causes
rendering artifacts if updateNeeded() sends the cursorRect().
Since QLineEdit and Q*LineControl aren't actively developed, it's
best to keep this fix minimal, although the performance cost of
updating the whole line edit when an input mask is set is
unfortunate.
Task-number: QTBUG-7174
Change-Id: Ie51e015d760915e07b0220b770f04fc958d93a12
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
Most of the tests were removed while QUrl::toEncoded or fromEncoded
were deprecated in the development process. Since they aren't
deprecated in the end, bring them back.
Change-Id: Ibdb6cd3c4b83869150724a8e327a03a2cd22580d
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
By having the default value equal to zero, we follow the principle of
least surprise. For example, if we had
url.path()
and we refactored to
url.path(QUrl::DecodeSpaces)
Then instead of ensuring spaces are decoded, we make spaces the only
thing encoded (unicode, delimiters and reserved characters are
encoded).
Besides, modifying the default can only be used to encode something
that wasn't encoded previously, so having the enums as Encode makes
more sense.
As a side-effect, toEncoded() does not support any extra encoding
options.
Change-Id: I2624ec446e65c2d979e9ca2f81bd3db22b00bb13
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
This allows things like http://example.com/{1234-5678}?id={abcd-ef01}.
But do not allow it in other parts of the URL. I could allow it in the
fragment, but in the username and password it would be too ugly.
In order to do that, make DecodeReserved use two bits and have
PrettyDecoded set only one of them. That way, toString(PrettyDecoded)
can be distinguished from toString(PrettyDecoded | DecodeReserved),
just as path(PrettyDecoded) can be distinguished from
path(PrettyDecoded & ~DecodeDelimiters).
Also, take the opportunity to avoid decoding the reserved characters
in the query. Keep them encoded as they should be.
Change-Id: I1604a0c8015c6b03dc2fbf49ea9d1dbed96fc186
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
DecodeReserved applies to all characters between 0x21 and 0x7E that
aren't unreserved, a delimiter, or the percent sign itself.
Change-Id: Ie64bddb6b814dfa3bb8380e3aa24de1bb3645a65
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
There's little value in having the DecodeUnambiguousDelimiters option
since neither QUrl nor QUrlQuery can return values that are ambiguous
in that particular context, ever.
This option could be used to encode a character if, when placed
in a URL, it would need to be encoded. Such cases are hash (#) or
question marks (?) in the path component, or slashes (/) and at signs
(@) in the userinfo.
However, we don't need two enums for that, since there are no
other characters that can appear in either form. Still, leave two bits
for this enum. In the future, if we want to split the gen-delims from
the sub-delims, we are able to.
Change-Id: If5416b524680eb67dd4abbe7d072ca0ef7218506
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
This tests how QUrl encodes and decodes certain characters and leaves
some other ones alone. It also tests that the output of toString() (in
whichever encoding was being tested) is also parsed again to be
exactly the same as the previously decoded form.
Change-Id: Ie358d001f8b903409db61db48bde1ea679241a60
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
This is the same fix as the previous commit did for the other
components of the URL. But we're also changing how we handle the "[]"
characters in a query: previously the handling was like for other
sub-delims; now, they're always decoded, assuming that the RFC had a
mistake and they were meant to be decoded.
Change-Id: If4b1c3df8f341cb114f2cc4860de22f8bf0be743
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
