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

Milian Wolff milian.wolff at kdab.com
Wed Jan 30 05:49:18 PST 2013


On Tuesday 29 January 2013 13:02:57 Jocelyn Turcotte wrote:
> 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.

See below.

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

See below - some kind of feedback is required. When Safari/Chrome encounter 
such cases they also show some interactive dialog. In QML we do not (yet?) 
have default components for such a task thus the QML app developer must create 
a proper styled dialog for this case.

Oh and of course: QtWebKit does not handle the unresponsive webprocess case at 
all - or am I missing something? And as Adam showed this is probably a non-
straightforward task to handle blindly/automatically somewhere inside 
QtWebKit.

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

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?

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: smime.p7s
Type: application/pkcs7-signature
Size: 3631 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20130130/54ef6960/attachment.p7s>


More information about the webkit-qt mailing list