FS#72366 - qt5-webengine fails to load urls from resources
Attached to Project:
Arch Linux
Opened by kachelaqa (kachelaqa) - Thursday, 07 October 2021, 14:43 GMT
Last edited by Antonio Rojas (arojas) - Sunday, 07 November 2021, 10:06 GMT
Opened by kachelaqa (kachelaqa) - Thursday, 07 October 2021, 14:43 GMT
Last edited by Antonio Rojas (arojas) - Sunday, 07 November 2021, 10:06 GMT
|
Details
Description:
The QWebEngineView widget can load urls from internal resource urls (like qrc:/test.html), but this stopped working recently. There are no error messages - the widget just fails to load the page. The QTextBrowser widget can also load resource urls, but is unaffected by the problem. So the issue seems specific to WebEngine, rather than Qt5. I tried installing the latest PyQt5 (which comes with precompiled upstream binaries) into a Python venv using pip, and could not reproduce the problem with that. So it appears to be an archlinux packaging issue rather than an upstream bug. I have discovered that downgrading qt5-base to 5.15.2+kde+r200-1 restores the functionality. So there seems to have been some change in the build environment after that point which has indirectly affected qt5-webengine in some way. I am unsure how to debug the problem any further. Versions affected: qt5-base 5.15.2+kde+r237-1 qt5-webengine 5.15.6-2 Steps to reproduce: I have attached a minimal C++ test-case that reproduces the problem on my system. To try it, run: tar -xf testcase.tar.gz qmake-qt5 testcase.pro && make ./testcase This will load the resource url by default, and show it correctly in the top widget (QTextBrowser) but not the bottom one (QWebEngineView). Loading the html directly like this: ./tescase test.html will show the page correctly in both widgets. It also shows that a resource url referenced *within* the html page still works correctly - it only seems to be direct loading of urls that no longer works as expected in WebEngine. |
This task depends upon
Closed by Antonio Rojas (arojas)
Sunday, 07 November 2021, 10:06 GMT
Reason for closing: Upstream
Additional comments about closing: Not related to packaging
Sunday, 07 November 2021, 10:06 GMT
Reason for closing: Upstream
Additional comments about closing: Not related to packaging
We have basically a package per upstream commit in https://archive.archlinux.org/packages/q/qt5-base/ - if you can pinpoint exactly which one causes the issue that would be helpful.
https://invent.kde.org/qt/qt/qtbase/-/commit/f6751d15aae40ae246b01a9dad5d9ce8c32610f9
https://invent.kde.org/qt/qt/qtbase/-/commit/e583929ec19f818db2821d5fa2c0f9d81b5545af
https://invent.kde.org/qt/qt/qtbase/-/commit/d23de39db3b84c8c9a80da36d8d0de8da4321566
none of which look related to me. If you can reproduce this on Wayland, that would rule out the last two. If that's the case, can you try building f6751d15aae40ae246b01a9dad5d9ce8c32610f9 to confirm?
I rebuilt (using _commit=f6751d15aae40ae246b01a9dad5d9ce8c32610f9) which produced qt5-base-5.15.2+kde+r201 - and the problem persists on my system.
Since this commit isn't part of the qt-5.15.2 official-release, it explains why I can't reproduce the problem when using the latest PyQt5 packages from PyPI (which are built with vanilla qt5). So it seems highly plausible that this particular commit must be the smoking gun.
It isn't really feasible for me to test on Wayland (I use Openbox WM and no particular DM as such) - and in any case, those other two commits look completely unrelated.
Comparing the sources of the latest official releases for Qt5 & Qt6 reveals that the changes from this commit have already landed in Qt6. So I suppose this *is* an upstream bug in Qt6 - but not (yet) in Qt5. And it appears there's some further changes related to qrc-handling slated for qt-6.3 which could confuse things even more: https://doc-snapshots.qt.io/qt6-dev/qtwebengine-changes-qt6.html#qrc-scheme.
I don't personally care about Qt6, because I mainly use Python for development, and PyQt6 has already removed its support for resources. So at some point, I will have to phase out my use of the qt resource-system from all my projects. At the moment, I'm thinking sooner is better than later...
All fixes for Qt5 need to fo through Qt6 first, which is the only supported version for non-paying customers. So if you want this to ever get fixed in Qt5 you'll have to report it upstream for Qt6. The fix will then be ported to the KDE patch collection, from which we make our packages.