I've attached a screenshot showing . Epiphany watches the new WebKitWebView:is-web-process-responsive property and terminates the web process immediately if it changes to TRUE. This only makes sense to do if the process responsiveness check is relatively conservative. I thought it would only fire if the web process did not respond to a ping from the UI process for 10 seconds. However, it seems to be firing more often than I would expect. I noticed it fired today about two seconds after I started loading a page, which seems much too fast. We should investigate to see if there might be any logic errors, perhaps involving PSON or other tricky edge cases, for example.
(In reply to Michael Catanzaro from comment #0) > I've attached a screenshot showing . Oops, there's really no point in a screenshot since it doesn't prove anything.
WebProcesses are also considered unresponsive when the system is under heavy load (e.g. building WebKit) and for example launching Epiphany with a saved session that has many tabs. The WebProcesses which need to be spawned all at once will do progress slowly, and most will be considered unresponsive.
See also: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/965 https://gitlab.gnome.org/GNOME/epiphany/-/issues/1561
I'm afraid WebKit only waits 3 seconds for an answer from the web process before marking it as unresponsive. This is not a lot and, as Adrian mentions, if the system is loaded some views can be marked as unresponsive despite they are just slow. Those 3 seconds are the default value used by Apple as well. We could increase the value for our ports if we think it's too small, or the browser could wait some extra time once the flag is activated to ensure that the process stays unresponsive for a while. Not sure what's the best option here.
Ah OK, that's a much simpler explanation. Both options seem fine to me: either increase our timeout, or make the browser responsible for implementing its own longer timeout. That's hardly difficult. Probably Epiphany should not assume it's reasonable to immediately kill the unresponsive process.
Let's close this since it's based on an invalid premise (I assumed, without checking, that the timeout was much longer than it actually is). The existing API is sufficient for browsers to implement smarter logic.