Clicking links in the RSS reader quiterss results in a massive delay since upgrading KDE from standard Ubuntu Xenial packages to the KDE PPA ones (kio 5.22.0-0ubuntu1~ubuntu16.04~ppa1). It can take 1-2 minutes until something happens, either all clicked addresses in that time frame open in bulk (in Firefox), which means there is the chance that some "not responding" error occurs in FF because of everything happening at once, or a popup titled "Error -- KIO Client" appears which says "Connection to host XYZ is broken". In both cases the opened links are lost and one has to remember what they did two minutes ago. This does not happen for all applications (in case you want me to open a quiterss bug): I've tested the konsole command xdg-open 'https://forum.kde.org/viewtopic.php?f=289&t=124392&p=327270#p327270' from bug 342677, which works exactly the same. It took around 75 seconds to open and the konsole freezes during that time. However, clicking stuff in mails in thunderbird does somehow bypass this problem and everything is opened instantly. Reproducible: Always Steps to Reproduce: 1. Click link in certain applications, e.g. xdg-open 'https://forum.kde.org/viewtopic.php?f=289&t=124392&p=327270#p327270' or some news feed in quiterss 2. Wait 1-2 minutes Actual Results: 3. link opens in firefox or error message from "KIO Client" pops up Expected Results: 2. Instant opening of the link 3. Everyone is happy because the system responds in an instant, nothing is lost during waiting time As the popup does not contain the full URL but just the host, the page clicked cannot be retrieved in case an error occurs. Therefore I chose "Grave", as waiting up to 2 minutes PER CLICK (or losing stuff on the way) isn't acceptable. Note that this is an Ubuntu Xenial LTS installation that doesn't get rebooted that often, current uptime is 17d.
running the xdg command with strace results in: trace xdg-open 'https://forum.kde.org/viewtopic.php?f=289&t=124392&p=327270#p327270' execve("/usr/bin/xdg-open", ["xdg-open", "https://forum.kde.org/viewtopic."...], [/* 76 vars */]) = 0 brk(NULL) = 0x560b4479f000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9674e55000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=280150, ...}) = 0 mmap(NULL, 280150, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9674e10000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0 mmap(NULL, 3967488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f9674869000 mprotect(0x7f9674a29000, 2093056, PROT_NONE) = 0 mmap(0x7f9674c28000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7f9674c28000 mmap(0x7f9674c2e000, 14848, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f9674c2e000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9674e0f000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9674e0e000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9674e0d000 arch_prctl(ARCH_SET_FS, 0x7f9674e0e700) = 0 mprotect(0x7f9674c28000, 16384, PROT_READ) = 0 mprotect(0x560b429d2000, 8192, PROT_READ) = 0 mprotect(0x7f9674e57000, 4096, PROT_READ) = 0 munmap(0x7f9674e10000, 280150) = 0 getuid() = 1000 getgid() = 1000 getpid() = 6029 rt_sigaction(SIGCHLD, {0x560b427c6540, ~[RTMIN RT_1], SA_RESTORER, 0x7f967489e4a0}, NULL, 8) = 0 geteuid() = 1000 brk(NULL) = 0x560b4479f000 brk(0x560b447c0000) = 0x560b447c0000 getppid() = 6027 stat("/home/bzzz/Downloads", {st_mode=S_IFDIR|0700, st_size=69632, ...}) = 0 stat(".", {st_mode=S_IFDIR|0700, st_size=69632, ...}) = 0 open("/usr/bin/xdg-open", O_RDONLY) = 3 fcntl(3, F_DUPFD, 10) = 10 close(3) = 0 fcntl(10, F_SETFD, FD_CLOEXEC) = 0 geteuid() = 1000 getegid() = 1000 rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGINT, {0x560b427c6540, ~[RTMIN RT_1], SA_RESTORER, 0x7f967489e4a0}, NULL, 8) = 0 rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f967489e4a0}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f967489e4a0}, NULL, 8) = 0 read(10, "#!/bin/sh\n#---------------------"..., 8192) = 8192 read(10, " echo \"Use --novendor to overrid"..., 8192) = 8192 read(10, "desktop\n if [ -r \"$dir/$defau"..., 8192) = 6362 stat("/usr/local/sbin/kde-open5", 0x7ffd2093e500) = -1 ENOENT (No such file or directory) stat("/usr/local/bin/kde-open5", 0x7ffd2093e500) = -1 ENOENT (No such file or directory) stat("/usr/sbin/kde-open5", 0x7ffd2093e500) = -1 ENOENT (No such file or directory) stat("/usr/bin/kde-open5", {st_mode=S_IFREG|0755, st_size=31696, ...}) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9674e0e9d0) = 6030 wait4(-1, [waits...] [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 6030 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=6030, si_uid=1000, si_status=0, si_utime=8, si_stime=2} --- rt_sigreturn({mask=[]}) = 6030 exit_group(0) = ? +++ exited with 0 +++ after that, I ran the same command again one folder higher (~/), and it instantly opened the web page: strace xdg-open 'https://forum.kde.org/viewtopic.php?f=289&t=124392&p=327270#p327270' execve("/usr/bin/xdg-open", ["xdg-open", "https://forum.kde.org/viewtopic."...], [/* 76 vars */]) = 0 brk(NULL) = 0x561eef8a1000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efe17cc7000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=280150, ...}) = 0 mmap(NULL, 280150, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7efe17c82000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0 mmap(NULL, 3967488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7efe176db000 mprotect(0x7efe1789b000, 2093056, PROT_NONE) = 0 mmap(0x7efe17a9a000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7efe17a9a000 mmap(0x7efe17aa0000, 14848, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7efe17aa0000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efe17c81000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efe17c80000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7efe17c7f000 arch_prctl(ARCH_SET_FS, 0x7efe17c80700) = 0 mprotect(0x7efe17a9a000, 16384, PROT_READ) = 0 mprotect(0x561eedfb6000, 8192, PROT_READ) = 0 mprotect(0x7efe17cc9000, 4096, PROT_READ) = 0 munmap(0x7efe17c82000, 280150) = 0 getuid() = 1000 getgid() = 1000 getpid() = 6061 rt_sigaction(SIGCHLD, {0x561eeddaa540, ~[RTMIN RT_1], SA_RESTORER, 0x7efe177104a0}, NULL, 8) = 0 geteuid() = 1000 brk(NULL) = 0x561eef8a1000 brk(0x561eef8c2000) = 0x561eef8c2000 getppid() = 6059 stat("/home/bzzz", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0 stat(".", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0 open("/usr/bin/xdg-open", O_RDONLY) = 3 fcntl(3, F_DUPFD, 10) = 10 close(3) = 0 fcntl(10, F_SETFD, FD_CLOEXEC) = 0 geteuid() = 1000 getegid() = 1000 rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGINT, {0x561eeddaa540, ~[RTMIN RT_1], SA_RESTORER, 0x7efe177104a0}, NULL, 8) = 0 rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7efe177104a0}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7efe177104a0}, NULL, 8) = 0 read(10, "#!/bin/sh\n#---------------------"..., 8192) = 8192 read(10, " echo \"Use --novendor to overrid"..., 8192) = 8192 read(10, "desktop\n if [ -r \"$dir/$defau"..., 8192) = 6362 stat("/usr/local/sbin/kde-open5", 0x7ffd2bdad3f0) = -1 ENOENT (No such file or directory) stat("/usr/local/bin/kde-open5", 0x7ffd2bdad3f0) = -1 ENOENT (No such file or directory) stat("/usr/sbin/kde-open5", 0x7ffd2bdad3f0) = -1 ENOENT (No such file or directory) stat("/usr/bin/kde-open5", {st_mode=S_IFREG|0755, st_size=31696, ...}) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7efe17c809d0) = 6062 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 6062 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=6062, si_uid=1000, si_status=0, si_utime=7, si_stime=2} --- rt_sigreturn({mask=[]}) = 6062 exit_group(0) = ? +++ exited with 0 +++ Now it works instantly in all folders with this very link, but external links from e.g. quiterss still do not succeed. I just found an engadget post that had 10 errors in 10 tries and xdg-open is also not capable of opening it in Firefox: strace xdg-open 'https://www.engadget.com/2016/06/29/ai-laywer-shoots-down-160000-parking-tickets/' execve("/usr/bin/xdg-open", ["xdg-open", "https://www.engadget.com/2016/06"...], [/* 76 vars */]) = 0 brk(NULL) = 0x55931402b000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f51bd424000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=280150, ...}) = 0 mmap(NULL, 280150, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f51bd3df000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\t\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1864888, ...}) = 0 mmap(NULL, 3967488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f51bce38000 mprotect(0x7f51bcff8000, 2093056, PROT_NONE) = 0 mmap(0x7f51bd1f7000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bf000) = 0x7f51bd1f7000 mmap(0x7f51bd1fd000, 14848, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f51bd1fd000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f51bd3de000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f51bd3dd000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f51bd3dc000 arch_prctl(ARCH_SET_FS, 0x7f51bd3dd700) = 0 mprotect(0x7f51bd1f7000, 16384, PROT_READ) = 0 mprotect(0x55931213f000, 8192, PROT_READ) = 0 mprotect(0x7f51bd426000, 4096, PROT_READ) = 0 munmap(0x7f51bd3df000, 280150) = 0 getuid() = 1000 getgid() = 1000 getpid() = 6169 rt_sigaction(SIGCHLD, {0x559311f33540, ~[RTMIN RT_1], SA_RESTORER, 0x7f51bce6d4a0}, NULL, 8) = 0 geteuid() = 1000 brk(NULL) = 0x55931402b000 brk(0x55931404c000) = 0x55931404c000 getppid() = 6167 stat("/home/bzzz/Downloads", {st_mode=S_IFDIR|0700, st_size=69632, ...}) = 0 stat(".", {st_mode=S_IFDIR|0700, st_size=69632, ...}) = 0 open("/usr/bin/xdg-open", O_RDONLY) = 3 fcntl(3, F_DUPFD, 10) = 10 close(3) = 0 fcntl(10, F_SETFD, FD_CLOEXEC) = 0 geteuid() = 1000 getegid() = 1000 rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGINT, {0x559311f33540, ~[RTMIN RT_1], SA_RESTORER, 0x7f51bce6d4a0}, NULL, 8) = 0 rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f51bce6d4a0}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f51bce6d4a0}, NULL, 8) = 0 read(10, "#!/bin/sh\n#---------------------"..., 8192) = 8192 read(10, " echo \"Use --novendor to overrid"..., 8192) = 8192 read(10, "desktop\n if [ -r \"$dir/$defau"..., 8192) = 6362 stat("/usr/local/sbin/kde-open5", 0x7ffcd2708070) = -1 ENOENT (No such file or directory) stat("/usr/local/bin/kde-open5", 0x7ffcd2708070) = -1 ENOENT (No such file or directory) stat("/usr/sbin/kde-open5", 0x7ffcd2708070) = -1 ENOENT (No such file or directory) stat("/usr/bin/kde-open5", {st_mode=S_IFREG|0755, st_size=31696, ...}) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f51bd3dd9d0) = 6170 wait4(-1, [waits 75s] KRun(0x2635210) ERROR (stat): 124 "Connection to host www.engadget.com is broken." [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0, NULL) = 6170 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=6170, si_uid=1000, si_status=1, si_utime=19, si_stime=2} --- rt_sigreturn({mask=[]}) = 6170 exit_group(4) = ? +++ exited with 4 +++
I think the root cause is that KDE is trying to open url internally, then passes it to the browser. This approach has several flaws, including big delay, redirection issues, proxy etc. Passed url should go directly to browser. The root cause was reported in: https://bugs.kde.org/show_bug.cgi?id=354246
In other words - xdg-open runs kde-open5 which uses KRun mechanism from KIO. When no external browser is set in System Setting then it causes issues. Workaround (not fix!) is to setup "firefox" as default browser in System Setting -> Application -> Default application -> Web browser. You can also put there x-www-browser if Firefox is your system default.
*** Bug 354246 has been marked as a duplicate of this bug. ***
I'm trying to fix this, but I need some help. I found out that since redirectionHandlingEnabled is enabled by default, this statement in transferjob.cpp at https://cgit.kde.org/kio.git/tree/src/core/transferjob.cpp#n114 handles the redirection. I tried to disable the redirection in krun.cpp at https://cgit.kde.org/kio.git/tree/src/widgets/krun.cpp#n1147, but I broke it because kde-open5 "never ends", but instead waits for something. I suspect foundMimeType() should be call (which is triggered when mimetype signal is emitted at https://cgit.kde.org/kio.git/tree/src/widgets/krun.cpp#n1151, but with redirectionHandlingEnabled=false this switch case at https://cgit.kde.org/kio.git/tree/src/core/slaveinterface.cpp#n250 is never triggered and then mimetype signal isn't emit.
While bug 354216 was marked as a duplicate of this one, it describes the root cause much better: kde-open5 is not coping well with several http(s) variants. As this bug is kept open and the bug 354216 marked as a duplicate, it may be useful to change the title of this bug to reflect this cause. I'm hitting this same issue mostly when clicking on links in mail messages in KMail, presently with kmail 17.04.1 on Fedora 26. Before stumbling on this bug I thought kde-open5 was mangling certain urls (like improperly escaping special characters such as '#', '&', '?' and similar), but now I believe it's the improper redirection handling that's causing most of it. So I'd be very happy to see some progress on this bug. Unfortunately I don't know the kde codebase at all so I'm not in a position to answer Andrea's questions in comment 5. Can someone else chime in ? Thanks. And lastly, the workaround suggested in comment 3 works for me for now.
The comment 6 above is wrong, probably added by accident in this bug report. Bug 354216 is *not* a duplicate of this one - it looks as a completely different story. This bug is a duplicate of (or in fact is duplicated by) bug 354246. I described it in comment 2 and comment 3, also description in bug 354216 is very good.
Oops, that was a typo in comment 6 indeed. I meant to refer to the bug that was actually set as a duplicate of this one. Sorry about the confusion. The core remains though, I'd very much like to see this one fixed, although the helpful workaround does reduce the urgency.
I looked at the code, it might be tricky to fix it. First thing why KDE is not opening URL in the browser but tries to connect to URL internally. This is a feature, not a bug :) When you pass URL pointing to, for example, zip archive it will open directly in Ark, not in the browser. This is pretty neat if you ask me :) The problem is in two cases: * connection refuse/timeout/etc when KDE is configured with wrong proxy (or any other cause). Usually when browser is configured differently than KDE (for example proxy). It is hard to say if this is a bug or not. * URL content is behind some kind of authorization, for example link to internal Jira issue. KDE internally follows redirection to login page, then recognizes content as HTML and opens new (redirected) URL in the browser. This is exactly what was described in bug 354246. I think that bug 354246 was wrongly marked as duplicate, it is a different case.
Issue with redirect is in fact a regression introduced... more than 7 years ago. Please check lines 1393 and 1478: https://github.com/KDE/kdelibs/blame/fee65b598f0d68ae7b4fbc3f76cb0c083f6d30ef/kio/kio/krun.cpp Now it is hosted in different repository but history is lost: https://github.com/KDE/kio/blame/master/src/widgets/krun.cpp Sorry for cross-posting. I commented the same in bug 354246, but it is closed as a duplicate.
Works for me in KDE Frameworks 5.49. I've seen a few of these "slow URL loading" bugs, but they all seems to have been fixed since they were filed. Let me know if anyone can still reproduce with a recent version of KDE Frameworks.
Most probably it is not resolved, simply it is now harder to reproduce because internet connections are faster. After rethinking it I don't know if it is a bug or a feature, even if I don't like how it behaves :) The main issue is that by default for all URLs KDE tries to get content type first, then open URL. It is a default setting in: System Settings -> Default applications -> Web browser: "open in application based on the contents of the URL" It is a neat feature, but it causes lags when: * network connection is slow * KDE has wrong proxy settings * URL should be opened in the browse, because browser uses... (you name it: authentication - like Mutual SSL, proxy, cookies, specific user agent, etc) Another problem is described in Bug 354246 where KDE opens redirected URL.
Konrad, do we need to re-open this ticket? The current bug status looks a bit ambiguous.
Chris, I don't know, it's up to you. I can't reproduce it right now (no proxy) and the most annoying problem related to this feature is described in separate Bug 354246.
Running into this on plasma-framework 5.61 With the default applications URL handler set to "in an application based on the contents of the URL" it takes 1:16 to open http://google.com with kde-open5 Attached log
Created attachment 122495 [details] kde-open5 strace with timestamps
Created attachment 122496 [details] Malformed kioslaverc Figured out the culprit. My ~/.config/kioslaverc had some old malformed proxy entries. Nuking the rc and running without properly opens URL based on mimetype instantly. Uploading the bad kioslaverc as an example