Bug 168604 – [GTK] Do something with processDidBecomeUnresponsive

• Status: NEW
• Component: WebKitGTK

[Michael Catanzaro]

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.

[Michael Catanzaro]

I think Evolution has had problems with this as well, though I've never noticed had any problems with it myself.

[Michael Catanzaro]

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

[Milan Crha]

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.

[Michael Catanzaro]

Separately, we ought to handle processes that exceed reasonable CPU usage. See bug #169456.