Bug 107929 – [Qt]Non-blocking sockets don't get notified when network status is down in QtWebKit page reloading

• Component: Page Loading
• Status: RESOLVED INVALID

[Chen Zhixiang]

Steps to reproduce this problem:

（1）Must use Linux, Windows has no problem（doesn't know why yet）;
（2）Setup a local apache html page, use the below .htacces file:
    ExpiresActive On
    Header set Cache-Control "no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform" 
    Header set Pragma "no-cache"
  Also, ensure your test html page contains resources num > 6, (css, js, images, etc)
（3）Use Qt's demos/browser to access it in the normal way, then ```disable network```, do a reloading;
（4）You will observe that the loading procedure may hang sometimes (not always)

Reason I guess:
1、Qt-4.8.x use non-blocking sockets and seems to maintain a ```connection pool```;
2、When network status is down, there objects in connection pool may not be notified, they still think network is OK
3、So when page reloading, the read request from these non-blocking sockets gets no response, the GUI seems to hang.

Apply the patch of bug 106761, the GUI will get read timeout error in at most 30s, but this is not perfect —— better to display network connection error at once.

So, how to clear out the ```connection pool``` when do page reloading?

Also I know the normal F5 reloading may use data in cache(this seems to be a common spec for all modern browsers), If use Shift + F5, reloading should not use any cache, or any connection from the ```connection pool```. I doubt Qt code may not provide such mechanism, or somewhere needs a fix.

[Allan Sandfeld Jensen]

Have this been tested in Qt 5?

[Chen Zhixiang]

Yes, Qt 5 also has this problem.

[Jocelyn Turcotte]

This would be a Qt bug and has probably nothing to do with WebKit.

My guess would be that somewhere in the QNetworkAccessManager code we should handle some cleanup through a signal of the bearer management's QNetworkSession.

[Jocelyn Turcotte]

=== 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.