[Qtwebengine] Debugging issue with QWebEngineView freezing on Qt 5.12.3

[Thuan Seah Tan]

Thanks. I suppose it is fine for me to run the configure and skip all the
other modules that I don't want to be build (including qtbase,
qtwebchannel, qtwebsocket, etc) and just build the qtwebengine library in
isolation?

Before I kick of a build (from our past experience, it can take a while,
like a day or 2), am I right to say the handling on the mouse click on a
link in QWebEngineView is handled in a separate thread (i.e. one of the
Chrome threads)? That's my initial assessment considering the freezing of
the webpage interaction did not cause the main UI thread to lock up.

On Fri, Jul 5, 2019 at 5:17 PM Allan Jensen <Allan.Jensen at qt.io> wrote:

> On Freitag, 5. Juli 2019 07:00:32 CEST Thuan Seah Tan wrote:
> > Hi all,
> >
> > We are currently migrating our software from Qt 5.4.1 to Qt 5.12.3 and
> > encountered an issue where the QWebEngineView would freeze (i.e. not
> > responding to mouse click on links but still responding to window resize)
> > but the main application thread runs fine.
> >
> > Currently we suspect it has something to do with how we handle drag and
> > drop. I am trying to debug this in Visual Studio 2017 and there are a
> > number of Chrome threads which I can't inspect the callstack for. They
> all
> > seem to be external code for some reason. Beyond that I don't see any
> > thread that could be related to QWebEngineView. Can anyone provide some
> > assistance as to how to troubleshoot the freezing issue?
>
> To get full debug info edit src/core/config/common.pri, there are two GN
> args
> that remove debug-info from blink and v8, comment those out. Note this
> will
> the debug library much larger (up to 4GB).
>
> As for the thread with QWebEngineView, it is the main UI-thread, thread 1.
>
> 'Allan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qtwebengine/attachments/20190708/72c2ebf1/attachment.html>