228147 2021-07-21 07:39:59 -0700 [WPE][GTK] WebKitWebView:is-web-process-responsive seems to become FALSE too aggressively? 2021-07-21 09:17:24 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux RESOLVED INVALID P2 Normal --- 1 mcatanzaro webkit-unassigned aperez bugs-noreply cgarcia magomez mcatanzaro oldest_to_newest 1778419 0 mcatanzaro 2021-07-21 07:39:59 -0700 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. 1778420 1 mcatanzaro 2021-07-21 07:40:46 -0700 (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. 1778421 2 aperez 2021-07-21 07:51:31 -0700 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. 1778423 3 mcatanzaro 2021-07-21 08:03:33 -0700 See also: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/965 https://gitlab.gnome.org/GNOME/epiphany/-/issues/1561 1778424 4 magomez 2021-07-21 08:06:37 -0700 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. 1778432 5 mcatanzaro 2021-07-21 09:00:41 -0700 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. 1778437 6 mcatanzaro 2021-07-21 09:17:24 -0700 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.