[webkit-qt] WK2/QML handling of unresponsive/crashed web process

[Jocelyn Turcotte]

On Thu, Jan 31, 2013 at 03:46:59PM +0100, Milian Wolff wrote:
> I have created a bug and attached a patch for that: 
> https://bugs.webkit.org/attachment.cgi?id=185771
> 
> But I noticed that this will need some more work: I simulated a hanging 
> process via:
> 
>  kill -stop $(pidof QtWebProcess)
> 
> This renders essentially freezes all WebViews in a QML app. Apparently only 
> after one tries to interact with the process (i.e. clicks somewhere inside the 
> webview) will the responsiveness timer kick in and fire eventually. On devices 
> without such interaction a JavaScript app in the webview could go nuts and go 
> into an infinite loop and won't ever be noticed... This is undesirable - do 
> you have any suggestions how it could be handled? Intermediate "are you alive" 
> ping/pongs between child/host? That might not be nice battery wise for static 
> websites though...

You could try sending a dummy mouse move event from your application. A user interface without user input feels like an edge case and it should probably be handled in an edgy way.

> Furthermore I could not figure out how one would handle the "process became 
> unresponsive" case: Calling .reload() on the webview will just hang. Should 
> QtWebKit automatically kill the webprocess in such cases?

I looked quickly and there is the WKPageTerminate function that might achieve this for the unresponsiveness case, we could expose it in QML if needed.

Cheers,
Jocelyn