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

[Jocelyn Turcotte]

On Mon, Jan 28, 2013 at 04:42:56PM +0100, Milian Wolff wrote:
> Hey guys,
> 
> have you any plans on handling the WKPageLoaderClient's 
> processDidBecomeResponsive or processDidCrash callbacks?
> 
> I could imagine writing the code required to push these signals all the way up 
> to QML similar to the other webview.experimental.* callbacks such as 
> runJavaScriptAlert in QtWebPageUIClient.
I don't see a good use case that would needs this to be exposed in the API. User code shouldn't have to worry about this and this should all be handled by WebKit2.

> The question is - how could I design the handler in a way that it would be 
> accepted upstream? Especially I wonder whether it would be OK to push the PID 
> or similar of the webprocess when it hangs, such that I could kill it from a 
> C++ object exposed to QML.
Applications shouldn't worry about this.

> Also, I'm not sure how to handle the case when the webprocess crashed. 
> Restarting it shounds simple enough, but will it actually be simple to do? 
> Especially updating any potential references to the web process might be error 
> prone - or is it only stored centrally?
This should already be the case, reloading the page or opening a new one should restart the web process.

> Generally, there is always only web process per webview - right? Or is there 
> even just one per QML/WK2 app - i.e. do multiple webviews share the same 
> webprocess?
There is currently one per UIProcess by default (I think), the ProcessModel argument passed to the WebContext constructor can allow you to have more than one, but I'm not sure how well this works at the moment. I didn't investigate.

There is probably a reason why you ask, are you running into issues around this?

br,
Jocelyn