The previous version was good, just not optimal. Because the input was
an unsigned 64-bit number, compilers needed to generate extra code to
deal with HW instructions that only convert 64-bit signed input. And
that was useless because a double uniformly distributed from 0 to 1 can
only have 53 bits of randomness.
The previous implementation did exactly what the Microsoft libstdc++ and
libc++ implementations do. In my opinion, those implementations have an
imperfect distribution, which is corrected in this commit. In those, all
random input bigger than 0x20000000000000 has a different frequency
compared to input below that mark. For example, both 0x20000000000000
and 0x20000000000001 produce the same result (4.8828125e-4).
What's more, for the libc++ and MSVC implementations, input between
0xfffffffffffff001 and 0xffffffffffffffff results in 1.0 (probability 1
in 2⁵³), even though the Standard is very clear that the result should
be strictly less than 1. GCC 7's libstdc++ doesn't have this issue,
whereas the versions before would enter an infinite loop.
Change-Id: Ib17dde1a1dbb49a7bba8fffd14eced3c375dd2ec
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The path wouldn't match if the cookie's path was root ('/') and the
URLs path was empty.
Change-Id: I6dcd10f1fdf4f48f14e50f1b169cbdfda7005849
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
All systems must implement it by now. If there's any system still
without it, that means it has no IPv6 support, so they can disable
QtNetwork entirely.
[ChangeLog][Deprecation Notice] Starting with Qt 5.10, IPv6 support is
mandatory for all platforms. Systems without proper IPv6 support, such
as the getaddrinfo() function or the proper socket address structures,
will not be able to build QtNetwork anymore.
Change-Id: I3868166e5efc45538544fffd14d8c28046f9191b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
All POST requests that were redirected would previously turn into GET
requests. This does not follow the standard for HTTP codes 307 and 308.
Task-number: QTBUG-63142
Change-Id: Ibd25a9566066e589670a9bc34e5dc5111f8139d5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
In some cases when a session isn't needed (i.e. for localhost), the
session is not opened at all. If a program (e.g. our tests) redirects
from localhost to a different system (e.g. the qt network test
servers, or the internet) it will wait for a session forever. So, we
need to check if a session is needed for the redirect-target and then
open one. It is usually opened in
QNetworkReplyHttpImplPrivate::_q_startOperation
Change-Id: Id3b78182a3fb3f63f0235ecb1fb665df8bd0c4ca
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
From: https://tronche.com/gui/x/xlib/events/exposure/expose.html
"The circumstances in which the X server generates Expose events
are not as definite as those for other events."
On windows with XCB_GRAVITY_NORTH_WEST flag set we should not get
expose events according to e2665600c0,
but as stated earlier this might not always be true.
Nevertheless, sometimes we get expose event from X server when shrinking
window, but most of the time we don't. Make the test not flakey by
checking that we get at least 1 expose event, instead of exactly 1.
Now running test 500 times in a loop does not fail.
Task-number: QTBUG-63424
Change-Id: I8004e622020cc09e11b7d592faf6d9ee1b9cfee2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 542e11ab2b)
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
Tests should not use QCursor to emulate mouse move, see QCursor::setPos() docs.
The flakiness of the test on XCB is not surprising when the test queries geometry
even before the window has been shown. With the re-factored version I could not
reproduce flakiness anymore.
Removed Q_OS_MAC and closed QTBUG-26274 as test passes on macOS from which I
assume that the underlying issue has been fixed.
Removed Q_OS_QNX ifdef as test does not rely on QCursor anymore.
This patch also fixes the issues on minimal / offscreen platform plugins.
QCursor::setPos() is evil for auto test purposes.
Note:
We intentionally use QTest::mouseMove(QWindow *window, ..), not the QWidget overload.
The QWindow version gets routed through QWSI, which ensures that all necessary events
are generated as expect. In QWidget code path this is currently disabled by
QTEST_QPA_MOUSE_HANDLING.
Change-Id: I285c26cff09e3f2750f8c2abbb1f46c8f7be984a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 1af927976a)
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
We already cleared 'cookedHeaders', which is a QHash for 'known headers'
(enumerators as keys instead of strings), now do the same for 'rawHeaders'-
not to end up with some weird mix of headers from all possible redirect
responses and the final response.
Task-number: QTBUG-61300
Change-Id: Ifd6655c4167840bb00d29446d36ce65ba2d5491a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
A few tests would QSKIP depending on the inclusion of SSL, producing
multiple lines of noise in the output.
And one test used https in one of its configurations without checking to
see if it could, causing an UnknownProtocolError.
Change-Id: I5f54bf1005f962cc027c099b816fbe245dc43d3f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
On macOS, absence of a QPA menu means that we should be using our
own internal logic since there's no entity on the QCocoaMenuDelegate
to take care of the shortcuts.
Change-Id: I35ed8f0b55445f61d0528709d4debb636a502002
Task-number: QTBUG-61039
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We were using the default ones, provided by RFC7540. It appears they are way
too restrictive and conservative: when downloading something relatively big,
a stream keeps spending the whole session/its own 'recv' windows and thus
we have to constantly send WINDOW_UPDATE frames. This significantly slows
down our HTTP/2 implementation, making it orders of magnitude slower than
HTTP/1.1. To fix this:
- We send SETTINGS_INITIAL_WINDOW_SIZE in the first SETTINGS frame
to inform our peer that per-stream WINDOW is bigger than 64Kb
- We increase the session's receive window size.
Task-number: QTBUG-63722
Change-Id: I31312fcfd5f0fc0aee6aaa5d3562cc7d1b931adc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Error out if it's missing or broken (Mersenne Twister not present).
This ensures that we never have a low-quality random generator in Qt.
Change-Id: I0a103569c81b4711a649fffd14ec80649df7087e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Auto-reset events are automatically reset to non-signaled when we get
notified about the signaled state. This implies that we cannot check the
event state again in activateEventNotifiers. Instead, store the signaled
state in a QAtomicInt and test and decrement that.
This amends commit 85403d0a.
Task-number: QTBUG-63555
Change-Id: I0adee3d2929783f98d91060f9106c8b5266d72fa
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Unique begins with a "y" sound, hence a unique is correct.
Change-Id: I9eb6b4d4c9ddab45af931e97c041c24edf163eca
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
... so that it comments the actual code, not what this code was before.
Change-Id: Ib191b9d7bd3ae3cda39a15f0f711cb1dd3c5c2b7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The autotest has been blacklisted for RHEL 7.1 and RHEL 7.2 earlier already
and it is still failing in 7.4.
Task-number: QTBUG-46116
Change-Id: I0f33be849513a2debaf8c093dcd413fa09b5c681
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
Commit ba1b73175b tried
blacklisting this autotest in Windows 7 only. This however
does not work. We can't pin point blacklisting to a specific
Windows version.
Task-number: QTBUG-63122
Change-Id: I5edb5b56fd86ad194214818a838db9cfd6be2ad1
Reviewed-by: Simo Fält <simo.falt@qt.io>
This autotest has been blacklisted already in RHEL 7.1
and RHEL 7.2. This one extends it to 7.3 and 7.4.
Task-number: QTBUG-52523
Change-Id: I3e2d8cd882d9f7dc58a65bde88e3aa16438b13c3
Reviewed-by: Simo Fält <simo.falt@qt.io>
308 Permanent Redirect was introduced after redirection support was
initially added to Qt.
[ChangeLog][QtNetwork][QNetworkAccessManager] Added support for HTTP status 308.
Task-number: QTBUG-63075
Change-Id: I1c6cda331d776237113ef8854de9abfe7e41ed3e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We're not going to crash to avoid core dumps getting recorded by
systemd, filling up filesystems or showing dialog boxes. We just need to
exit without running destructors. Now, exit() isn't supposed to run
function-scope destructors, so just in case we use _exit().
Change-Id: I0b48fc8e90304e0dacc3fffd14e909ff248ce1a1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
<future> is needed by QThread::create. Instead of a fragile series
of preprocessor tests, move its detection to a configure test.
This dramatically simplifies the code, but on the other hand ties
the availability of QThread::create() to the system used to compile
Qt (rather the one used to compile an application).
Change-Id: If1b06363379bf29126cfa68f2a0651cbb78a67f7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Commits aba336c2b4 (in Qt 5.2) and
aba336c2b4 (in 5.6) both tried to deal
with this problem, with different levels of success. This is the third
attempt (and hopefully the charm).
Instead of modifying the path that the user provides, go straight ahead
and declare it invalid. This is supported by RFC 3986, which declares
this expansion impossible:
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
The "path-abempty" and "path-noscheme" cases are the two issues we
already handle. This commit adds the third one: path-absolute, which
requires that the first segment of the path be of non-zero length.
That is, it is now possible again to have http://example.com//path
constructed piece-wise, without it producing http://example.com/path.
Additionally, it catches the case of http://example.com//path parsed
from full URL then followed by setAuthority("").
Change-Id: I69f37f9304f24709a823fffd14e67a5e7212ddcd
Reviewed-by: David Faure <david.faure@kdab.com>
The qWaitFor functions themselves can not trigger a test failure, as that
will not result in the test function exiting early, so every single call
to qWaitFor needs to be wrapped in a QVERIFY.
Change-Id: Id15a1549f31d06cdbf788e1d84ea431c28636ec8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The test tst_QXmlSimpleReader::inputFromSocket() is failing with
"QTestLib: This test case check ("(((server->listening)))") failed
because the requested timeout (5000 ms) was too short, 11700 ms would
have been sufficient this time".
Increased the timeout, since it's better to wait than to fail.
Task-number: QTBUG-63539
Change-Id: I804549648ea834e41d3c87871f5bab90f209385c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When many runnables are executed, this improves the
performance by not resizing the queue for each runnable,
which was the case in the previous version, because of
many calls to QVector::takeFirst().
Also add a test that makes sure tryTake() is safe to
call and does not leave the queue in a bad state that
tries to use nullptr entries.
Change-Id: I608134ecfa9cfc03db4878dcbd6f9c1107e13e90
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We can't qWaitForWindowExposed on native menu bars. Other test
functions in this file are already disabling the native manu bar.
Task-number: QTBUG-24326
Change-Id: Iecf907ca84589159417d0d942c911485a41af164
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
A "compound widget" is a widget that has a focus proxy set to an inner
child. This is normal for complex black-box components where focus handling
is delegated to the children. Since the compound can have several
children, a local tab order might exist between them.
The current implementation of setTabOrder had no idea about
compound widgets. As such, when connecting two compounds in the
tab chain, it would just break up their inner tab order and
cause tabbing to ignore children other than the proxy.
The new implementation recognizes compound widgets, and add some
extra code to figure out the correct tab targets. This way, the
local tab order between the children will be preserved.
This implementation was inspired by the patches of Marek Wieckowski posted
in the linked bug report, and later modified by Nikita Krupenko.
[ChangeLog][Widgets] QWidget::setTabOrder() will now preserve the local
tab order inside a widget if it has a focus proxy set to an inner child.
Task-number: QTBUG-10907
Change-Id: I0673d39d70ec8c6bf64af30bf978d67c651b2f3c
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
The original test was using QSslSocket::waitForEncrypted function, which
is apparently a bad idea on Windows: connecting to 'www.qt.io' we have
to verify certs and there is no guarantee a given Windows VM has the required
CA certificate ready in its cert store. In such cases we start a background
thread (aka CA fetcher's thread) and it calls a (potentially blocking for
a significant amount of time) function (CryptoAPI). When finished, this
thread reports the results via queued connection, which does not work
if we are sitting in a tiny-loop inside waitForEncrypted. Re-factor
the test to use signals/slots and a normally running event loop.
Also, the last test makes a wrong assumption about Windows - fixed.
Task-number: QTBUG-63481
Change-Id: I4abe9cda2a6c52d841ac858cccb6bf068e550cb8
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Convert QSysInfo/QOperatingSystemVersion to __builtin_available where
required or possible, or to QOperatingSystemVersion where
__builtin_available cannot be used and is not needed (such as negated
conditions, which are not supported by that construct).
Change-Id: I83c0e7e777605b99ff4d24598bfcccf22126fdda
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QWindowContainer assumed that a widget could never change from
native to non-native. This is not a fact when the window container
is reparented to toplevel and back. In this case, usesNativeWidgets
would be stuck at true, and parentWasChanged() would go down the
native widget path, triggering an assert.
The solution is to always recalculate the usesNativeWidgets bool.
Task-number: QTBUG-63168
Change-Id: I88178259878ace9eb5de2ee45ff5e69b170da71c
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Błażej Szczygieł <spaz16@wp.pl>
Swapping from RHEL 7.2 to 7.4 produces new autotest failures.
Task-number: QTBUG-63433
Change-Id: I3e59aa73b5874cfec06e166f521e06b0c7829743
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This avoids looping prior to the main 16-byte loop, by performing one
load that may include bytes prior to the start of the string. This is
guaranteed not to fault, since str points to a valid character, but it
may cause Valgrind to print warnings.
Change-Id: I6e9274c1e7444ad48c81fffd14dcae854bba24b2
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
By the time we call setKeyboardMode(true), the menu may
already have taken focus. This change sets keyboardFocusWidget
before opening the popup, and makes sure that keyboardFocusWidget
is not set to the popup. (We cannot remove the assignment from
setKeyboardMode(), since it's called from several places.)
[ChangeLog][QtWidgets] Fixed widget losing focus after showing
menu second time.
Task-number: QTBUG-56860
Change-Id: Ic01726bf694e6f365dd7b601ad555156e0fdf6c5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
From: https://tronche.com/gui/x/xlib/events/exposure/expose.html
"The circumstances in which the X server generates Expose events
are not as definite as those for other events."
On windows with XCB_GRAVITY_NORTH_WEST flag set we should not get
expose events according to e2665600c0,
but as stated earlier this might not always be true.
Nevertheless, sometimes we get expose event from X server when shrinking
window, but most of the time we don't. Make the test not flakey by
checking that we get at least 1 expose event, instead of exactly 1.
Now running test 500 times in a loop does not fail.
Task-number: QTBUG-63424
Change-Id: I8004e622020cc09e11b7d592faf6d9ee1b9cfee2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When tabbing/searching for the next focus widget, the current
code would check if the next widget in the focus chain
had a focus proxy, and if so, ignore it. The exact reason
for this behavior is not clearly understood, but some widgets
(e.g QSpinBox) has children (a QLineEdit) that sets the parent
as focus proxy. If we didn't ignore children with focus proxy, tabbing
from a QSpinBox would lead us to find the inner QLineEdit, which
(because of its proxy), would lead us back to the QSpinBox. And
therefore not be able to tab out.
But ignoring the focus proxy has other problems. Normally a focus
proxy is the next sibling to the widget it acts as a proxy for, and
tabbing to the widget will therefore appear correct. But if the
focus proxy is not the next sibling, the logic will fail, since
the tab would anyway give focus to the next sibling. This becomes very
apparent if the focus proxy is a child of the widget, since then
its likely that the focus proxy is not the _first_ child among all
the children. So tabbing to the parent would not give focus to
the proxy.
This patch will change this logic so that you are allowed to tab to a
widget with a focus proxy. But we check that if you do so, you actually
end up moving focus in the right direction. If not, we ignore it like
before. This will ensure that we tab correctly when dealing with focus
proxies, and especially when focus proxies are used to construct
compound widgets.
[ChangeLog][Widgets] When tabbing to a widget with focus proxy, focus
will now be given to the proxy rather than just being ignored.
Task-number: QTBUG-10907
Change-Id: I66d1da5c941fdd984bb2783cc355ca65b553b5dd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
"generate" is better than "get", and we already have "generate(it, it)"
which uses std::generate(). This changes:
- get32() → generate()
- get64() → generate64() and QRandomGenerator64::generate()
- getReal() → generateDouble()
Change-Id: I6e1fe42ae4b742a7b811fffd14e5d7bd69abcdb3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Due to the complex event forwarding logic between QCompleter,
QComboBox, QLineEdit and QWidgetLineControl, in some cases the
same single user return key press could result in duplicated
activated() signals being emitted by QComboBox. The first one
would be emitted because QLineEdit emitted editingFinished()
as a result of QCompleter::eventFilter() having forwarded the
return key press event to QComboBox. The second one, would
happen right after, as QCompleter::eventFilter() would process
the same event on behalf of its popup.
(We recall that QCompleter is installed as its own popup event
filter. That's also the case for the completer's widget, although
the purpose there is limited to focus-out events).
The current fix consists on skipping the emit as a result of
QLineEdit::editingFinished() if the completer's popup is still
active. For this to be accurate, it helps to test whether the
completer's popup is visible, so we will not be hiding it in
QWidgetLineControl::processKeyEvent() anymore. Indeed, we know
that if the popup is visible, that means that processKeyEvent()
was called after being forwarded by the completer's popup event
filter. Furthermore, the popup will be hidden by its event filter
shortly after it returns from said event forwarding call.
Based on a patch by Alexey Chernov <4ernov@gmail.com>.
Task-number: QTBUG-51858
Task-number: QTBUG-51889
Change-Id: I013f6c3000ae37b5b0ec20eaf5cf7746c9c903e3
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
