I tried to submit a bug report e.g. for konqueror and also kmail, but at the last step, it always fails with e.g.: "Error sending the bug report: /https://bugs.kde.org/rest/... What I see here is that "https:" is really prefixed(!) with a "/" I assume this is the problem.
What version is this with? What distro is this on? If it's not distro packages, how was drkonqi built? Also, please get debug output: edit ~/.config/QtProject/qtlogging.ini and add: [Rules] org.kde.drkonqi=true org.kde.drkonqi.bugzilla=true save the file. try to file a crash up to that error, and get the drkonqi debug output from where your Qt logs to (likely .xsession-errors; could also be journalctl though).
Operating System: openSUSE Tumbleweed 20200411 KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1 Kernel Version: 5.6.2-1-default OS Type: 64-bit Processors: 4 × Intel® Core™ i5-6300U CPU @ 2.40GHz Memory: 15,5 GiB of RAM I get no output when activating the qlogging flags. Can it be that this is not written since KF5 is not compiled in debug mode ? I tried to compile drkonqi master now, but I don't have the latest KF5 libs yet in tumbleweed, requested version "5.69.0", have "5.68.0" so I have to wait some more days ...
on opensuse I'm fairly confident output goes to journald and I'm also fairly confident that debug message are compiled-in. if you find out where your drkonqi binary lives you can probably also try to run it manually which should then print the debug output to the terminal QT_LOGGING_RULES="org.kde.drkonqi=true;org.kde.drkonqi.bugzilla=true" DRKONQI_IGNORE_QUALITY=1 PATH_TO_DRKONQI --appname konqueror --signal 11 --pid `pidof konqueror` --startupid 0 --bugaddress submit@bugs.kde.org --dialog --appversion 999 (you need to replace PATH_TO_DRKONQI. this is assuming konqueror is running)
Created attachment 127583 [details] logs logs from a crash I forced by kill -4 of a kwrite instance
Well, that I thought would be more useful :| Please also add kf5.kio.*=true to qtlogging.ini and try again. Note that the output will likely contain plaintext passwords now, you'll want to replace them before attaching it to the bugreport.
That does not help either. The only additional output is: Apr 16 11:04:22 lapi drkonqi[10500]: kf5.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/audiocd.so" supports protocols ("audiocd") Apr 16 11:04:22 lapi drkonqi[10500]: kf5.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/ftp.so" supports protocols ("ftp") Apr 16 11:04:22 lapi drkonqi[10500]: kf5.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/ghelp.so" supports protocols ("ghelp") Apr 16 11:04:22 lapi drkonqi[10500]: kf5.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/recentlyused.so" supports protocols ("recentlyused") Apr 16 11:04:22 lapi drkonqi[10500]: kf5.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/file.so" supports protocols ("file") Apr 16 11:04:22 lapi drkonqi[10500]: kf5.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/kdeconnect.so" supports protocols ("kdeconnect") Apr 16 11:04:22 lapi drkonqi[10500]: kf5.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/remote.so" supports protocols ("remote") Apr 16 11:04:22 lapi drkonqi[10500]: kf5.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/trash.so" supports protocols ("trash") Apr 16 11:04:22 lapi drkonqi[10500]: kf5.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/http.so" supports protocols ("http", "https", "webdav", "webdavs") Apr 16 11:04:22 lapi drkonqi[10500]: kf5.kio.core: "/usr/lib64/qt5/plugins/kf5/kio/help.so" supports protocols ("help") I have killed all http.so processes before the test in the hope that this will then add additional output when its maybe started new, but no...
:( You can try putting KDE_FORK_SLAVES=1 into /etc/environment and logging out and in again. That should make drkonqi fork() directly and ideally then make the debug output appear. Should that not work I presume you could build the Plasma/5.18 branch manually if I gave you a patch?
Created attachment 127641 [details] logfile new logfile attached. Shows a HTTP 400 "Bad request" error
Huh. I am thinking what is happening is that you have a cookie and KIO is trying to be smart and inject the cookie into the request so the API goes "WTF" seeing as it's not cookie based. Will have to try to reproduce on Monday. Thanks for the logs!
Git commit abb0115bf7bee74c5be19191fc6bc0e1c84d5326 by Harald Sitter. Committed on 20/04/2020 at 07:26. Pushed by sitter into branch 'Plasma/5.18'. disable automatic cookie injection the http slave reads the cookie metadata and defaults to auto, which would try to find applicable cookies in the cookiejar and inject it into every request. this is problematic because that cookie is not from drkonqi but rather some other software (e.g. konqueror). as such the cookie is entirely useless for us but gets in the way when bugzilla finds the cookie to be unacceptable for whatever reason (outdated,invalid,unexpected). force all apijobs to disable cookies entirely. we have no use for them. FIXED-IN: 5.18.5 M +4 -0 src/bugzillaintegration/libbugzilla/apijob.cpp https://commits.kde.org/drkonqi/abb0115bf7bee74c5be19191fc6bc0e1c84d5326
It'd be lovely if you could test that fix. I can't actually reproduce the problem on my end. I've verified that indeed it's automatic cookie injection that makes your cookie end up in the requests and the commit does disable that. So, assuming the cookie is the culprit you should be able to file reports. On a related note, if you were logged in via konqueror you may want to logout and back in again or change your password seeing as the uploaded log contains the cookie :|