We have an issue in Epiphany where attempting to Stop or close an unresponsive web process takes a very long time (I think 30 seconds). It would be useful for us to have a way to detect this and kill the process immediately. I do think this should really be handled by WebKit, not the application, though: if the web process doesn't respond to Stop or close within a second or two, something's gone wrong and it surely needs to be killed. The WebKit::NavigationClient and WebKit::LoaderClient classes expose processDidBecomeUnresponsive/processDidBecomeResponsive alongside processDidCrash. I don't know what the difference between the two clients is, but we implement WebKit::LoaderClient in WebKitLoaderClient.cpp. We should probably handle unresponsive notifications there, e.g. by manually killing the web process and then calling webkitWebViewWebProcessCrashed.
I think Evolution has had problems with this as well, though I've never noticed had any problems with it myself.
(In reply to comment #0) > We > should probably handle unresponsive notifications there, e.g. by manually > killing the web process and then calling webkitWebViewWebProcessCrashed. Or just expose a new signal for unresponsive process.
It's not always stuck, it can sometimes do something with a large page in the main thread, which makes the WebProcess "unresponsive". Like the recent hyphenation issue. The 30 seconds can be about D-Bus timeouts, it is as such in the evolution side at least, when talking to its web extension.
Separately, we ought to handle processes that exceed reasonable CPU usage. See bug #169456.