[Webkit-unassigned] [Bug 246330] [GTK][WPE] Add API to check for web process responsiveness

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=246330

--- Comment #5 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Przemyslaw Gorszkowski from comment #4)
> I am wondering how and when this mechanism should be
> started and stopped on API level (WebKitWebViewGtk.cpp,
> WbKitWebViewWpe.cpp), do you have any suggestions? I am thinking to use for
> that ResponsivenessTimer - or something similar.

It seems ResponsivenessTimer is how WebKitWebView:is-web-process-responsive is already implemented. Each AuxiliaryProcessProxy has a ResponsivenessTimer. WebProcessProxy inherits from AuxiliaryProcessProxy and uses that to call NavigationClient::processDidBecomeUnresponsive. And WebKitWebView installs WebKitNavigationClient, which calls webkitWebViewSetIsWebProcessResponsive.

So there's already a ResponsivenessTimer to use for this. I don't think we need a second one. Just need to make sure that AuxiliaryProcessProxy's timer is actually running. The code that decides whether to run the ResponsivenessTimer is scattered throughout WebPageProxy.cpp. It looks like the code runs the timer when (a) loading a page, or (b) processing user input, and stops the timer (a) to avoid it running during nested run loops, (b) after the user input has been processed, and also (c) in WebPageProxy::dispatchActivityStateChange. This design makes sense based on the assumption that if the user is not doing anything, it doesn't matter whether the process is responsive, so it's OK to check responsiveness only in response to user input. Now, if a video is playing, no user interaction is expected, but you still need to know if the process hangs so you can restart it and resume the video. On a desktop or phone, it's probably OK to fail to detect if the video has frozen, because the user will undoubtedly click or press when it freezes and that will start the timer and detect the problem. But on your devices, that assumption does not work: you need to restart even if there is no user interaction, yes?

So, this turned out to be more complicated than I was expecting. Maybe your original proposal really is the simplest option: just add a new API that will immediately update the is-web-process-responsive property without requiring user interaction, and call it regularly from your application, exactly as you originally proposed. Another option would be to change the WebPageProxy to have two different modes: the current mode, and a new mode that always checks responsiveness instead of only checking during user input. Problem is, if the view is not visible, that wastes battery life, so we'd need to add a way for WebKitWebView to tell WebPageProxy whether it is visible or not... or the API user could be responsible for handling that by telling the responsiveness timer when to start and stop. But then that requires *two* new API functions, one to start the timer and one to stop it! Finally, we could convince Apple to just run the timer always, but if it's not needed for devices where easy user input is expected, maybe we shouldn't?

Perhaps I was wrong to dismiss your original proposal so quickly. I wonder what other WPE/GTK reviewers would prefer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221014/8d539f41/attachment.htm>