1cd79cf429
Prior to switching the protocol handler to use QHttp2Connection this particular issue (see bugreport) was not a problem because the handling of the IO-device being destroyed was simply to drop any pointer to it. QHttp2Stream, however, also has to keep track of the lifetime of the IO-device, because it needs to abort the stream if the data it's uploading is destroyed earlier than expected. Now, since QHttp2Stream might also have other errors come up, we have to connect to the generic 'errorOccurred' signal from it and handle whatever issues arise, notifying our users that the request for some reason cannot be fulfilled. It's thanks to this part that we were now, in certain cases, grabbing a stale pointer to the HttpNetworkReply and trying to call functions on it. We fix this somewhat indirectly. Because, after a HttpReply is destroyed, we shouldn't even have any references to it in the first place. And while it would usually be done as part of handling the deleted() signal, we actually disconnect from HttpNetworkReply's signals when we have processed one of the finished*() functions. But since we were still connected to the stream's signals we would still try to handle it. For the http1 protocol handler this was already handled in QHttpNetworkConnection::removeReply, which the HttpNetworkReply itself calls at start of destruction. The function will go through any place that the reply can be referenced and removes it. For http/2 it would remove it from the list of requests yet to be sent, but not from the in-progress list. So, we now add a new virtual function to the AbstractProtocolHandler and specialize it in Http2 to handle exactly this. Fixes: QTBUG-136549 Change-Id: Ie41863677a3b163f77d10bc3904ca515f6840be3 Reviewed-by: Mate Barany <mate.barany@qt.io> (cherry picked from commit b0b9adf06675c5caa37105ceee157245e3dcca21) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 6b4e11e63ead46dde5c1002c123ca964bb6aa342)
This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.
Linux X11:
* The user must be logged in to an active desktop; you can't run the
autotests without a valid DISPLAY that allows X11 connections.
* The tests are run against a KDE3 or KDE4 desktop.
* Window manager uses "click to focus", and not "focus follows mouse". Many
tests move the mouse cursor around and expect this to not affect focus
and activation.
* Disable "click to activate", i.e., when a window is opened, the window
manager should automatically activate it (give it input focus) and not
wait for the user to click the window.