Bug 228147 - [WPE][GTK] WebKitWebView:is-web-process-responsive seems to become FALSE too aggressively?
Summary: [WPE][GTK] WebKitWebView:is-web-process-responsive seems to become FALSE too ...
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2021-07-21 07:39 PDT by Michael Catanzaro
Modified: 2021-07-21 09:17 PDT (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2021-07-21 07:39:59 PDT
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.
Comment 1 Michael Catanzaro 2021-07-21 07:40:46 PDT
(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.
Comment 2 Adrian Perez 2021-07-21 07:51:31 PDT
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.
Comment 4 Miguel Gomez 2021-07-21 08:06:37 PDT
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.
Comment 5 Michael Catanzaro 2021-07-21 09:00:41 PDT
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.
Comment 6 Michael Catanzaro 2021-07-21 09:17:24 PDT
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.