168604 2017-02-20 09:14:52 -0800 [GTK] Do something with processDidBecomeUnresponsive 2017-03-13 12:13:07 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux NEW https://bugs.webkit.org/show_bug.cgi?id=168479 P2 Normal --- 1 mcatanzaro webkit-unassigned bugs-noreply mcatanzaro mcrha tpopela oldest_to_newest 1278950 0 mcatanzaro 2017-02-20 09:14:52 -0800 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. 1279074 1 mcatanzaro 2017-02-20 15:08:43 -0800 I think Evolution has had problems with this as well, though I've never noticed had any problems with it myself. 1279075 2 mcatanzaro 2017-02-20 15:09:41 -0800 (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. 1279288 3 mcrha 2017-02-21 01:40:05 -0800 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. 1287280 4 mcatanzaro 2017-03-13 12:13:07 -0700 Separately, we ought to handle processes that exceed reasonable CPU usage. See bug #169456.