Hi WebKit folks! I'm working on improving the detection of unresponsive web processes and how to recover from that situation on the GTK and WPE ports. Investigating how ResponsivenessTimer and BackgroundProcessResponsivenessTimer work, I see that currently there are 3 ways to detect that the process has become unresponsive: * When there's an user event, the event is passed to the web process and the ResponsivenessTimer is started to check whether there's an answer from the web process in the next 3 seconds. If this doesn't happen, the process is marked as unresponsive. * Same that above, but started from some API call (like reload for example) instead of an user event. * When the WebProcessProxy doesn't have visible pages or it's used for a ServiceWorker, the BackgroundProcessResponsivenessTimer will periodically ping the web process, and mark it as un responsive when there's no answer. This is enabled for non Apple ports only. What I see is that there's no way to check the responsiveness of the web process when there are no API calls or the user is not interacting with the page. I'm thinking on the user watching a video without interacting with the page, or some JS script locking the main thread at some point. To improve this, I've created https://bugs.webkit.org/show_bug.cgi?id=224862 and sent a patch for the ResponsivenessTimer to send a ping to the web process every ten seconds after the last reply from the web process. I was thinking of enabling this feature only for GTK and WPE, but maybe some other ports are interested as well. Just answer this or add some comment to the bug and I'll remove the platform guards. Also, in https://bugs.webkit.org/show_bug.cgi?id=224359 I added a property to WebKitWebView (in GTK and WPE) to signal the web process responsiveness, so with these 2 things the detection should be covered. Then there's the problem of recovering from an unresponsive web process. We should probably show a warning to the users so they can decide whether to wait or stop the page. And then, what to do if the user decides to stop the page? I see 2 options here: * Have some API method that allows to kill the problematic web process, and let the browser call it when needed. The next load will create a new web process. * Modify some of the existent load/reload API calls so they check whether the web process is responsive or not. If it's unresponsive, kill the process before trying to do anything else, and a new web process will be created when the rest of the code is executed. On https://bugs.webkit.org/show_bug.cgi?id=224533 we were leaning towards the second option, so we don't need to add new API and the whole situation is handled inside WebKit. But studying the code I found that the Apple ports seem to use the first one: the object handling the responsiveness is an external class that implements the WKNavigationDelegate inteface, and I guess it uses _killWebContentProcess or _killWebContentProcessAndResetState in order to kill the web process before loading some new content. Am I right regarding how Apple ports work? If the answer is yes, is there any special reason to do it what way? Should we follow that approach too? WDYT? Regards! -- Miguel Gomez Igalia - www.igalia.com