@JoeCFD Where is it located in the relative /QT folder? /... like 5.12.5 , dist, Docs, Examples

@mpergand Thank you man =)

Hi and welcome to devnet,

That's a bit too vast of a topic to have a simpler answer.

What element of Cyber Security do you have in mind ?
At what level ?
Cyber Security starts from giving people access to certain hardware / applications to the boot process of your machines/devices, the kernel/OS they are running, the applications you are using on them, the libraries that composes these applications, the devices you plug in the machines, etc.

The QtWebView module comes to mind for that.

@KH-219Design glad to know I helped and thanks again for your input!

After working perfectly during one full day of tests, the problem resurfaced again yesterday. Anything built in C++ using QWebEngineView works for all of my tests until it gets to one of the problem URLs, then abruptly crashes. No other URLs cause this problem and the page in question loads fine in any "real" browser I try it in.

Since I'm not tied to any particular version of Qt, I've downgraded from Qt 5.14.2 to Qt 5.13.2.

The Qt 5.13.2 QWebEngineView is not crashing. Also, it seems faster than Qt 5.14.2, and doesn't have another annoying behaviour which I believe to be graphics driver-related, which is that for certain pages of a well known UK based left wing newspaper the URL loads and then the whole web engine widget goes grey, and the program freezes.

With no interest in faffing around further, I'm concluding that inside Qt 5.14.2, either the implementation of Chromium or the Qt WebEngine wrapper is buggy, at least for my particular combination of hardware and software.

Original Problem
Using MSVC 2017 + Qt 5.14.2, QWebEngineView crashes randomly on certain URLs which do not appear to be doing anything out of the ordinary.

Solution
Avoid Qt 5.14.2, or at least avoid the pre-built MSVC 2017 version which comes when you use the offline installer for Qt 5.14.2. In my case this meant downgrading to Qt 5.13.2.

hi vpettersson,

i got the same errors and got it working with 3 symlinks:

in sysroot/opt/vc/include/EGL

mv egl.h egl.h-old
mv eglext.h eglext.h-old
mv eglplatform.h eglplatform.h-old

ln -s /home/jw78/raspi/qt-everywhere-src-5.15.2/qtwebengine/src/3rdparty/chromium/third_party/khronos/EGL/eglext.h eglext.h
ln -s /home/jw78/raspi/qt-everywhere-src-5.15.2/qtwebengine/src/3rdparty/chromium/third_party/khronos/EGL/egl.h egl.h
ln -s /home/jw78/raspi/qt-everywhere-src-5.15.2/qtwebengine/src/3rdparty/chromium/third_party/khronos/EGL/eglplatform.h eglplatform.h

of course you must adjust your paths (/home/jw78/raspi/qt-everywhere-src-5.15.2)

there are many egl.h/eglext.h/eglplatform.h to include and because of the include order the comiler fetches first the files in sysroot/opt/vc/include/EGL
probably the better solution is to reorder the "-I" flags for the compiler, but i have no idea how to do this

i did not
dpkg --purge libraspberrypi-dev

@jsulm
http://download.qt.io/official_releases/qt/5.12/5.12.8/single/qt-everywhere-src-5.12.8.tar.xz

i downloaded it form here and followed this steps https://www.tal.org/tutorials/building-qt-512-raspberry-pi

according to that i can say that 3rd party content also built along with the code

hi
wish this help
https://forum.qt.io/topic/117637/easy-way-to-cross-compile-qt-for-raspberry-pi

The following command fixed.

sudo xcode-select -s /Applications/Xcode.app/Contents/Developer

It's a QT bug ( https://bugreports.qt.io/browse/QTBUG-79254 )

If somebody every needs it again I implemented a workaround which I posted here:
https://stackoverflow.com/questions/62152845/touch-freeze-in-qtwebengine-after-opening-a-dropdown-menu

Great !

Since you have it working now, please mark the thread as solved using the "Topic Tools" button so that other forum users may know a solution has been found :-)

In case, there's an answer that provides the correct hint, you can also use the three button menu to mark it as the correct answer.

@forca maybe you need to do some additional steps

From QSslSocket documentation:

Describes the peer verification modes for QSslSocket. The default mode is AutoVerifyPeer, which selects an appropriate mode depending on the socket's QSocket::SslMode.
QSslSocket::QueryPeer 1
QSslSocket will request a certificate from the peer, but does not require this certificate to be valid. This is useful when you want to display peer certificate details to the user without affecting the actual SSL handshake. This mode is the default for servers. Note: In Schannel this value acts the same as VerifyNone.

And looking at this QWebEnginePage browser example, check the Downloading Favicons code snippet, which may help you accessing the underlying QSslSocket

@hsynkrkmz
From posts I have seen elsewhere: this happens with QtWebEngine, sometimes. It seems to very picky about where it gets destroyed. If you are waiting for definitive answer, you might like to try moving around where/how you destroy it and see if different behaviour.

@Yakov-Eremin
read this: https://doc.qt.io/qt-5/qtwebengine-features.html#html5-geolocation

to check if geoclue is working properly simply test if it delivers a position: https://doc.qt.io/qt-5/qml-qtpositioning-positionsource.html#example-usage