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

Jocelyn Turcotte jocelyn.turcotte at digia.com
Thu Jan 31 07:56:01 PST 2013


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


More information about the webkit-qt mailing list