You either have to build QWebEngine (or WebEngineWidgets) from source if you want it for Qt 6.7.2. QWebEngine is available through the Qt Maintenance Tool only in certain versions. For example 6.6.2. I just upgraded from 6.6.2 to 6.9.0 but faced the same problem. Luckily, 6.9.1 (downloaded via Maintenance Tool) Includes Qt WebEngine Module for msvc2022_64, so I upgraded directly to 6.9.1.

@Wycer said in No gn found for cross-compilation: @SamiV123 I do need, main module of my project. I googled a lot and eventually found that link too, however I am not sure what to do next. I tried following their install process but still got the error, I tried installing using apt and also didn't work. If you can guilde me a little more that would be great! And thanks a lot for your time and effort :) Sorry, all I can offer is try following the chromium build instructions, if you can get your env to a point where you can build the chromium source then it should hopefully work for Qt as well. https://www.chromium.org/developers/how-tos/get-the-code/

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