Your message dated Thu, 01 May 2025 12:28:43 -0700
with message-id <3038981.6M6d0yLqnL@soren-desktop>
and subject line angelfish: Stop depending on QQuickWebEngineDownloadItem
private header
has caused the Debian Bug report #1059164,
regarding angelfish: Stop depending on QQuickWebEngineDownloadItem private
header
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1059164: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059164
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: angelfish
Version: 22.11-1+b4
Severity: normal
Tags: upstream
Dear Maintainer,
Angelfish currently depends on a private header for QQuickWebEngineDownloadItem.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057755 for context.
This can be determined using the following command:
$ nm -D /usr/bin/angelfish-webapp | grep Qt_5_PRIVATE_API
U
_ZN22QQuickWebEngineProfile16downloadFinishedEP27QQuickWebEngineDownloadItem@Qt_5_PRIVATE_API
U
_ZN22QQuickWebEngineProfile17downloadRequestedEP27QQuickWebEngineDownloadItem@Qt_5_PRIVATE_API
It isn't clear to me exactly why this is happening. There is a public API for
WebEngineDownloadItem.
https://doc.qt.io/qt-5/qml-qtwebengine-webenginedownloaditem.html
Qt 6 also has a public version of this API, which was renamed
WebEngineDownloadRequest.
https://doc.qt.io/qt-6/qml-qtwebengine-webenginedownloadrequest.html
Looking at Angelfish's code, it appears that it is using the public Qt 5
version of this API, but for some reason it is pulling in the private header at
some point.
I haven't been able to determine if this is because of something explicit
Angelfist is doing or if it is some bug on Qt's side.
Privacy Browser doesn't exhibit this behavior when using the C++ version of
WebEngineDownloadItem, so if it is a bug in Qt it is specific just to QML.
But even more concerning is that, on Qt 6, Anglefish explicitly pulls in the
private header for WebEngineDownloadRequest, even though I can't see anything
they are doing that can't be done with the public API.
>From https://sources.debian.org/src/angelfish/22.11-1/src/downloadsmodel.cpp/
#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
#include "qquickwebenginedownloaditem.h"
using DownloadItem = QQuickWebEngineDownloadItem;
#else
#include <private/qquickwebenginedownloadrequest_p.h>
using DownloadItem = QQuickWebEngineDownloadRequest;
#endif
The current upstream maintains this behavior. From
https://invent.kde.org/network/angelfish/-/blob/master/lib/angelfishwebprofile.cpp?ref_type=heads
#include <private/qquickwebenginedownloadrequest_p.h>
Depending on a private header when all the needed functionality appears to
already be available in a public API doesn't make any sense and complicates
efforts to include proper security support for Qt WebEngine in stable.
If Anglefish does somehow need some functionality that is not included in the
public API the best course of action would probably be to request that Qt
publicly expose that functionality.
If Angelfish doesn't actually need anything that isn't in the public API then
it should be easy to stop using the private header.
Looking through the code it appears the plumbing for this class and its methods
have been significantly modified between Qt5 and Qt 6.
If, for some reason, the QML version of the Qt 6 WebEngineDownloadRequest is
still pulling in private versions of the methods, this would be a bug that I
would imagine Qt would be willing to address.
As this behavior doesn't exist for the C++ classes, I would not imagine that it
is intentional.
In the case of the current Qt 5 behavior, if this isn't something that is being
explicitly done by Angelfish in some way, it is probably easiest to just let it
go and expire when Qt 5 is removed from Debian.
Altering these high-level APIs doesn't feel like the type of change Qt would be
interesting in making to the Qt 5 LTS branch.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages angelfish depends on:
ii libc6 2.37-12
ii libgcc-s1 13.2.0-7
ii libkf5configcore5 5.107.0-1
ii libkf5configgui5 5.107.0-1
ii libkf5coreaddons5 5.107.0-1
ii libkf5dbusaddons5 5.107.0-1
ii libkf5i18n5 5.107.0-1+b1
ii libkf5notifications5 5.107.0-1
ii libkf5windowsystem5 5.107.0-1
ii libqt5core5a 5.15.10+dfsg-5
ii libqt5gui5 5.15.10+dfsg-5
ii libqt5network5 5.15.10+dfsg-5
ii libqt5qml5 5.15.10+dfsg-2
ii libqt5quick5 5.15.10+dfsg-2
ii libqt5sql5 5.15.10+dfsg-5
ii libqt5webengine5 5.15.15+dfsg-2+b1
ii libqt5webenginecore5 [qtwebengine-abi-5-15-15] 5.15.15+dfsg-2+b1
ii libqt5widgets5 5.15.10+dfsg-5
ii libstdc++6 13.2.0-7
ii qml-module-org-kde-kirigami2 5.107.0-1+b1
ii qml-module-qtfeedback 5.0~git20180903.a14bd0b-5
ii qml-module-qtwebengine 5.15.15+dfsg-2+b1
angelfish recommends no packages.
angelfish suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
I am marking this as done as it is now fixed in unstable and testing.
--
Soren Stoutner
so...@debian.org
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
