QWebEngineView crashes on Chromium error

Jez1337

Hello, I'd be grateful if anybody could help explain why my QWebEngineView is crashing on two specific URLs, in a list I use for unit testing.

After setting the Url, the web engine view abruptly stops in the middle of loading the page, reporting an access violation.

Both URLs load fine in a normal Chrome browser. After isolating the code into the below example, I suspect it's a bug in QWebEngineView, but I wanted to check here first, in case any good souls on the forum know what's happening.

#include <QtWidgets/QApplication>
#include <QWebEngineView>

int main(int argc, char *argv[])
{
	QApplication a(argc, argv);
	QWebEngineView w;

	QUrl url = "...";
	w.setUrl(url);
	w.show();
	return a.exec();
}

Errors received

The first URL has some bad HTML in it, so Chrome is reporting a error before crashing, but this might just be a red herring:

[12668:6072:0121/105533.540:INFO:CONSOLE(16)] "Error parsing a meta element's content: ';' is not a valid key-value pair separator. Please use ',' instead."
[12668:8880:0121/105534.846:ERROR:legacy_cache_storage_cache.cc(2335)] Cache size: 32768 does not match size from index: 0
Exception thrown at 0x00007FF9F58BA049 (Qt5WebEngineCored.dll) in TestExample.exe: 0xC0000005: Access violation reading location 0x0000000000000100.

The second URL doesn't have any HTML errors:

[7872:5844:0121/122601.206:WARNING:backend_impl.cc(1844)] Destroying invalid entry.
Exception thrown at 0x00007FF9F673A049 (Qt5WebEngineCored.dll) in TestExample.exe: 0xC0000005: Access violation reading location 0x0000000000000100.

System info

Qt 5.14.2, x64, using the prebuilt binaries from the Qt website (in Qt 5.6 these URLs worked fine and were tested literally hundreds of times)
Compiling using Visual Studio 2017, running on Windows 10

Jez1337

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

jsulm

Removed offending URLs.
Please try other URLs, don't post such URLs here.

Jez1337

Hi jsulm, my apologies for the example URLs pointing to websites which may contain adult content.

I elided the context to make my post shorter but ironically in light of your response, I'm building a tool which adds parental controls to a web browser, consequently have to test using a variety of pages to ensure the parental controls screen out the correct websites.

By pure fluke, those are the only URLs in the test list which cause Web Engine to crash, so unfortunately those are the URLs which cause the problem. Otherwise I would have obviously provided different ones. I don't think it will be easy for anybody to replicate the problem without the test data, because googling this issue has drawn a blank. Also just to point out, gently and with the greatest respect, that this is preventing me from testing my parental controls, which are aimed at protecting people from inappropriate content online.

jsulm

@Jez1337 You could download that page without all the adult content and if you can reproduce the issue with that downloaded html/JavaScript you can post it here.

Jez1337

Hello, thank you for this suggestion, I've just carried it out. I scraped the source of the two (literally) offending URLs in Python, loaded them on a local server, and tried to access them by pointing my QWebEngineView via:

w.setUrl(QUrl("http://localhost/example1.html");

In both cases, they now load correctly in the QWebEngineView. This means that:

Both sites work in Qt 5.14.2 when I host their source code locally
Both sites work in Qt 5.6 when using the live version from the original site
Both sites do not work in Qt 5.14.2 when using the live version from the original site

So what could possibly be happening which makes QWebEngineView crash when using the live versions?

KH-219Design

The idea that I am going to mention is a "long shot". I'm just sharing an anecdote in case it helps, but it may well just be a red herring.

While using a WebEngineView from QML recently, I found that my program would crash if the current web page tried to open any new popup. If I'm not mistaken, websites with "adult content" are notorious for doing that, so maybe you are having the same issue.

My gut tells me that what I encountered does represent a Qt/QML bug that needs fixing, but I found a workaround and didn't have time to investigate enough to prove whether it merited filing a bug against Qt.

Below you can see my workaround in QML. Since you are using C++, I'm thinking that maybe there is a similar way you can override handling of onNewViewRequested in C++. I've only done it from QML so I don't know offhand how you can do it.

  WebEngineView {
    id: thisWeb

    anchors.fill: parent
    url: dlViewModel.targetUrl

    onNewViewRequested: function (request) {
      // Any user can trigger newViewRequested by simply holding the CTRL key while clicking any hyperlink.
      // per Qt Docs: "If this signal is not handled, the requested load will fail."
      // Using 5.15 on Linux, "fail" for us meant CRASH.
      // (refer to: https://doc.qt.io/qt-5/qml-qtwebengine-webengineview.html#newViewRequested-signal)
      // Some of their sample code make it seem like just using an empty
      // function body would be sufficient to avoid the crash. However, in our
      // testing that was not the case. This is the ONLY thing that managed
      // to avoid a crash:
      request.openIn(thisWeb)
    }
 
....

Jez1337

Well at this stage I'm happy to follow up any ideas :) It was a big surprise to upgrade to the nice shiny Qt 5.14 and then have this explode in my face. If you'll excuse the metaphor.

I will have a look at how to implement this in C++ and let you know how I get on, thanks!

Jez1337

I've been testing the above code to load the following HTML page, which launches a popup in the most naive way possible:

<!DOCTYPE html>
<html>
<head>
<script>
    function init()
    {
        window.open("http://www.w3schools.com");
        window.open("https://www.google.com");
    }
    document.addEventListener("DOMContentLoaded", init, false);
</script>
</head>
<body>
        Hello World
</body>

This isn't causing QWebEngineView to crash, it just loads the first page and ignores the attempts to open the popup windows.

I'm dimly aware of other ways to open popups, so before ruling this out as a cause of the issue, was it a page as simple as this one which was causing your QML WebEngineView program to crash?

Jez1337

Testing on a colleague's computer with an identical development environment showed both URLs working, suggesting that, rather than a problem with Qt, it was something local to my machine.

I uninstalled Qt (I'm using the pre-build binaries), reinstalled it, and hey presto, everything now works correctly.

We keep meticulous notes on the installation steps so it's a complete mystery how I ended up with a corrupted development environment, especially since we use the pre-built binaries which really leave almost no scope for things not to be installed correctly.

Assuming that the issue doesn't resurface in the next few days, I will mark this topic as closed.

To anybody experiencing similar unexplained crashes in the future, my solution seems to have been to do a clean install of the Qt libraries.

KH-219Design

@Jez1337 just to close the loop on your simple HTML with the window.open calls...

In my case, yes, your HTML page is sufficient to trigger the QML WebEngineView crash that I had run into (and that I am able to avoid by adding my onNewViewRequested code shared earlier).

So if your HTML page did not produce a crash for you, then it seems safe to say that whatever issue I am having is indeed different from whatever issue you were having.

I'm glad to know your issue has subsided! May we both continue with our good luck!

If I do find the time to dig into my WebEngineView crash any further, then your sample HTML page is actually very helpful! It makes my program crash ASAP right at launch time (instead of my old method of loading a page and then manually ctrl-clicking). So you came to this forum for help and ended up helping me instead. You have my gratitude.

Jez1337