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

[Milian Wolff]

On Wednesday 30 January 2013 15:52:17 Milian Wolff wrote:
> On Wednesday 30 January 2013 15:22:20 Jocelyn Turcotte wrote:
> > On Wed, Jan 30, 2013 at 02:49:18PM +0100, Milian Wolff wrote:
> > > The process-question I asked to clarify my understaning for when I have
> > > to
> > > work on writing the code to handle the unresponsive/crashed web process.
> > > 
> > > My use case is a WebView as a local-HTML renderer (opposed to a full
> > > fledged browser). It would be embedded in a bigger QML app and just part
> > > of the full package. One does not want it to show a blank white page
> > > showing "web process crashed": To get rid of it after all, the user
> > > would
> > > have to press some reload GUI element. Especially on embedded devices
> > > with limited screen real estate you don't want to clutter it with such a
> > > reload button.
> > > 
> > > Rather one might want to reload the page automatically and increase some
> > > crash counter. If it failed for N times consecutively though one should
> > > probably show a proper error page - but that should be properly styled
> > > and integrated into the rest of the application. It could e.g. contain
> > > additional information and offer to report a bug or something.
> > > 
> > > None of these things above are possible to handle right now using
> > > QtWebKit
> > > from QML - or am I missing something?
> > 
> > Ok, same idea as suggested on my response to Alexis, how about exposing
> > the
> > processDidCrash signal (along with processDidBecomeUnresponsive for
> > unresponsiveness), which could then be handled by the QML code to call
> > reload automatically, or prompt the user first, or just ignore it and let
> > the user press the reload button. Would that solve your issue?
> 
> Yes it would, if QtWebKit automatically killed the unresponsive process upon
> reload.

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...

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?

Cheers
-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20130131/b82eff36/attachment.sig>