tree 7616aa94c67d4be22923d16a3bbeb7d9e0be8656
parent 93769ed5b8233b615016d72c97ececb307f82130
author jocelyn.turcotte@digia.com <jocelyn.turcotte@digia.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> 1368635473 +0000
committer jocelyn.turcotte@digia.com <jocelyn.turcotte@digia.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> 1368635473 +0000

[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):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150120 268f45cc-cd09-0410-ab3c-d52691b4dbfc