Bug 347715

KDE uses kio, which by default opens URLs in the appropriate application based on mimetype (text files are opened in your text editor, images are opened in your image viewer, packages are opened in your package manager, etc.).

If you want to change this behaviour go to System Settings, Applications, Default Applications, Web Browser and change the setting there to whatever you want.

As for the freezing, I can't reproduce that here with Frameworks 5.11.0. Feel free to open this bug again if you can still reproduce it with the latest version of kio et al.

I still can reproduce the freezing (Plasma 5.3.1, KF 5.11.0, konsole 15.04.2).

See related,
https://git.reviewboard.kde.org/r/124132/

(In reply to Rex Dieter from comment #3)
> See related,
> https://git.reviewboard.kde.org/r/124132/

I confirm, it fixes this bug.

(In reply to Rex Dieter from comment #3)
> See related,
> https://git.reviewboard.kde.org/r/124132/

That's not a fix, that assumes that all links are HTML, please see my comment on that review request and my earlier comment here. It basically disables proper kio integration in Konsole, which is a pretty major regression.

But as I am unable to reproduce the hanging opening any kinds of links, can you open a second terminal when konsole hangs, and do the following:

Run «gdb -p $(xprop _NET_WM_PID | cut -d' ' -f3)», click on the hanging Konsole window, wait for GDB to load, and then type «thread apply all bt» and hit enter, and copy the output and paste it here (or put it in a text file and add as an attachment).

Alternatively, if gdb complains about «operation not permitted», run «xprop _NET_WM_PID | cut -d' ' -f3» as your normal user, click on the window, note the number it prints out, and then as root run «gdb -p PID» (where PID is the number from the earlier command), and then «thread apply all bt» and hit enter and paste/attach the output here.

Created attachment 93350 [details]
Konsole freeze GDB log

(In reply to Martin Sandsmark from comment #5)
> That's not a fix, that assumes that all links are HTML, please see my
> comment on that review request and my earlier comment here. It basically
> disables proper kio integration in Konsole, which is a pretty major
> regression.

IMHO, it depends on what we expect from "Open link" function. I expect it to work as "Open http:// links in default web browser", even if http link points to RPM package, tar.gz archive or something else.

(In reply to Pulfer from comment #7)
> IMHO, it depends on what we expect from "Open link" function. I expect it to
> work as "Open http:// links in default web browser", even if http link
> points to RPM package, tar.gz archive or something else.

I explained you how to change that in my first comment.

(In reply to Pulfer from comment #6)
> Created attachment 93350 [details]
> Konsole freeze GDB log

Thank you very much for this, I can reproduce this in Dolphin as well now. It seems to be a blocking dbus call in KRun probably, I'll try to find out where.

the problem is line 99 here, it uses a blocking DBus call, which is a really, really bad idea: http://quickgit.kde.org/?p=kservice.git&a=blob&f=src%2Fkdeinit%2Fktoolinvocation.cpp

I'll try to see if we can change that, or possible fix whatever is on the other end.

ok, this is a bit more involved, so I'm not entirely sure what to do here.

KRun::runService() uses KToolInvocation::startServiceByDesktopPath(), which is deprecated, and the deprecation comment mentions KRun as a replacement...

I'm re-assigning it to KIO in any case, since that's where this should be fixed.

Created attachment 93353 [details]
A simple, dumb, stupid and untested patch

I just removed the code that called the deprecated KService function, which means that it will use KProcess directly instead of trying to call KLauncher with a blocking dbus call. Someone should probably debug why KLauncher is hanging sometime, though, but I saw that it somehow depends on KRun again, so it's not a rabbit hole I'm going to go down now.

I doubt this is a good fix, but it should work at least.

After noticing something odd I'm starting to think this is a problem with a service not starting.

After Martin Sandsmark's comment (https://bugs.kde.org/show_bug.cgi?id=347715#c5) (thanks for the keen eye) I did some more investigating. I first ran the original code `KRun::openUrl(...)` (what I'll term the "buggy code") and, of course, links opened just fine.

I then reverted the line to code that caused the bug (`new KRun(...)`--what I'll term the "good code"), expecting Konsole to freeze. But it didn't (I even did a clean to ensure I was compiling the code). This leads me to believe that the code started a service that the buggy code was expecting.

Today I compiled the buggy code and found the bug reproducible.

More investigation to follow...

[Corrections from previous comment]

After noticing something odd I'm starting to think this is a problem with a service not starting. After Martin Sandsmark's comment (https://bugs.kde.org/show_bug.cgi?id=347715#c5) (thanks for the keen eye) I did some more investigating. I first ran the original code `KRun::openUrl(...)` (what I'll term the "good code") and, of course, links opened just fine.

I then reverted the line to code that caused the bug (`new KRun(...)`--what I'll term the "buggy code"), expecting Konsole to freeze. But it didn't (I even did a clean to ensure I was compiling the code). This leads me to believe that the code started a service that the buggy code was expecting. Today I compiled the buggy code and found the bug reproducible. More investigation to follow...

Updated the patch.

https://bugs.kde.org/show_bug.cgi?id=347715

While I was able to get URLs to open I did notice that Qt detected "http://" URLs as the mime type "application/octet-stream," which KDE didn't quite know how to handle (It handled other mime types like "inode/directory" and "text/plain" just fine, though). Should this be considered a bug, too?

(In reply to Jordan Hewitt from comment #15)
> While I was able to get URLs to open I did notice that Qt detected "http://"
> URLs as the mime type "application/octet-stream," which KDE didn't quite
> know how to handle (It handled other mime types like "inode/directory" and
> "text/plain" just fine, though). Should this be considered a bug, too?

application/octet-stream is just a fancy way to say "unrecognised stream of bytes" (bytes == 8 bits, octet == 8 bits). There is no way of guessing what application should open that. That's why the existing code downloads enough data to find out what the data contains before assigning a mimetype.

The problem isn't the KRun call in Konsole (many things call KRun), the problem is that the KRun call calls other stuff which in turn sometimes hangs (waiting on a dbus connection with a blocking call). Therefore the right fix is to fix KRun (which is also why I have re-assigned this bug, and I'm fairly certain that my patch should fix the problem, but I haven't gotten around to testing it yet).

(In reply to Martin Sandsmark from comment #1)
> KDE uses kio, which by default opens URLs in the appropriate application
> based on mimetype (text files are opened in your text editor, images are
> opened in your image viewer, packages are opened in your package manager,
> etc.).
> 
> If you want to change this behaviour go to System Settings, Applications,
> Default Applications, Web Browser and change the setting there to whatever
> you want.

I arrived at this report while researching a different problem. My mistake was the same, so i'll just explain it for fellow idiots. 

In my case the URL being fed to kio was a https link with a bad certificate; instead of launching the web browser, konsole first fired up a "Server Authentication" window listing the reasons why the server failed the authenticity check. After agreeing to continue anyway, i got my browser which offered a similar certificate error. There's really no point in kio's warning before going to the browser, but it can't be helped because kio wants to retrieve the mimetype and needs to establish a https connection before knowing to launch the browser.

What's worse is that on certain URLs this warning never appeared - the notification window freezes and i get myself a handful of unaccessible konsole tabs. Killing the frozen warning window killed the parent along with all its tabs. I never cared to debug what was causing the freeze, likely local to my build, but the resolution is to set the default web browser. Thanks Martin!

Another case for this: with kio, dead URLs get no launch feedback from konsole, only a very tiny plasma notification, and a timeout pop-up after the timeout, which leaves you lost until it appears. Expected behaviour would be for kio to trigger launch feedback while attempting to connect, should this be filed somewhere?

Is this still an issue in Frameworks 5.45? If so, would anyone like to submit the aforementioned patch? We have really good documentation on this these days: https://community.kde.org/Infrastructure/Phabricator

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!