When a URL scheme of a link is unsupported or when QWebEnginePage::acceptNavigationRequest() returns false for the link-clicking request, the page stays the same, no navigation occurs. But if the page was not fully loaded by the time the link was clicked, no content is added after the click. The issue occurs when the page with the link is generated by a sequential, streaming QIODevice passed to QWebEngineUrlRequestJob. It may also occur with standard-scheme pages (e.g. https), but I haven't tested that.

Attached an example that reproduces the bug. The example also contains a workaround for QTBUG-106461, which can be enabled by passing a number as the first command line argument to the example program (could be useful for testing with versions that don't contain fixes for that bug).

The output of the example program shows that reading from the QIODevice continues even as the page content stops appearing in the web view. This indicates that the current behavior is not intentional. A proper fix, of course, is to load the page normally despite the link click. If this is impossible to implement using Chromium API, then at least the IO device should be closed and the QWebEngineUrlRequestJob destroyed as soon as a link is clicked.

The only workaround I know of is to use a button instead of a link. Note that image links (i.e. <a href="..."><img src="..."></a>) also stop page updates - this is what occurs in a real-world application I develop.