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 | [email protected] | 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ webkit-qt mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-qt
