[Qt] Fix a crash under ~PingLoader when the QNAM on the page has been destroyed.

https://bugs.webkit.org/show_bug.cgi?id=116035
Reviewed by Allan Sandfeld Jensen.

Source/WebCore:

The previous fix only moved the crash location from WebKit down to QNetworkReplyHttpImpl
which expects its QNetworkAccessManager to still be alive.

Fix it by watching the QNetworkReply's destroyed() signal and avoid the dangling pointer
instead. The QNetworkReply doesn't need to be aborted in this case anyway.

* platform/network/qt/QNetworkReplyHandler.cpp:
(WebCore::QNetworkReplyWrapper::QNetworkReplyWrapper):
(WebCore::QNetworkReplyWrapper::release):
(WebCore::QNetworkReplyWrapper::stopForwarding):
  Rename resetConnections to stopForwarding since not all connections are related
  to data forwarding to the client anymore.
(WebCore::QNetworkReplyWrapper::receiveMetaData):
(WebCore::QNetworkReplyWrapper::replyDestroyed):
(WebCore::QNetworkReplyWrapper::didReceiveFinished):
* platform/network/qt/QNetworkReplyHandler.h:
(QNetworkReplyWrapper):

Source/WebKit/qt:

* tests/qwebpage/tst_qwebpage.cpp:
(tst_QWebPage::networkReplyParentDidntChange): Change test to match the new expectation.
(tst_QWebPage::destroyQNAMBeforeAbortDoesntCrash):

Change-Id: I5e82b8ccc8fccf496669af8de76888e367480f67
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150120 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@digia.com>

0 files changed, 0 insertions, 0 deletions