|Summary:||[Qt] cleaning up QNetworkReply|
|Product:||WebKit||Reporter:||Johannes Zellner <email@example.com>|
|Component:||WebKit Qt||Assignee:||Nobody <firstname.lastname@example.org>|
|Severity:||Normal||CC:||email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org|
|Priority:||P3||Keywords:||EasyFix, Qt, QtTriaged|
Regarding the documentation it is not quite clear who is when responsible to cleanup the QNetworkReply used in the signals QWebPage::unsupportedContent(QNetworkReply *reply); and QWebPage::finished(QNetworkReply*) Using "deleteLater()" on the QNetworkReply, as stated in the docs, is ok in the SLOT connected to QWebPage::unsupportedContent(QNetworkReply *reply), but leads to segfault if used in the SLOT connected to QWebPage::finished(QNetworkReply*)
Can you please provide a simple test case for this?
There's no QWebPage::finished(QNetworkReply*) [signal] present in the API. There are void QWebPage::loadFinished ( bool ok ) [signal] and void QNetworkAccessManager::finished ( QNetworkReply * reply ) [signal] Did you mean the second one?
sorry you are right, I meant the void QNetworkAccessManager::finished ( QNetworkReply * reply ) [signal]
=== Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.