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 _______________________________________________ webkit-qt mailing list webkit-qt@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-qt
