Bug 400006 - Opening a HTTP link downloads the page instead of opening it
Summary: Opening a HTTP link downloads the page instead of opening it
Status: RESOLVED NOT A BUG
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.54.0
Platform: Kubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2018-10-18 20:10 UTC by Matej Mrenica
Modified: 2021-09-29 15:21 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot (184.85 KB, image/png)
2018-11-20 09:46 UTC, Matej Mrenica
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matej Mrenica 2018-10-18 20:10:01 UTC
SUMMARY


STEPS TO REPRODUCE
1. Create a link in Libre office
2. Open it
3. 

OBSERVED RESULT
The target page is downloaded and then opened

EXPECTED RESULT
The target page is opened

SOFTWARE VERSIONS
(available in About System)
KDE Plasma Version: 5.14.1
KDE Frameworks Version: 5.51
Qt Version: 5.12-beta2

ADDITIONAL INFORMATION
This bug is probably in bad component and/or product.
Also see: https://www.reddit.com/r/kde/comments/9pbbrb/when_i_open_a_link_in_an_app_i_am_redirected_to_a/
Comment 1 Nate Graham 2018-10-19 03:51:23 UTC
What's the link in question? What version of LibreOffice?
Comment 2 Matej Mrenica 2018-10-19 06:09:49 UTC
(In reply to Nate Graham from comment #1)
> What's the link in question? What version of LibreOffice?

LO 6.1.2 and theese links inside a .rtf document: 

https://gitlab.gnome.org/GNOME/gimp 
https://www.gimp.org/release-notes/gimp-2.8.html 
https://docs.gimp.org/2.6/en/gimp-concepts-main-windows.html https://docs.gimp.org/2.8/en/gimp-concepts-script-fu.html
Comment 3 Kai Uwe Broulik 2018-10-19 06:17:18 UTC
Can you check your setting in System Settings → Applications → Default Applications → Web Browser? Is "open in application based on the contents" checked? If so, see if the problem persists if you explicitly choose a web browser.

What KIO does is when you click a link it first tries to figure out what content there is and then open it in the appropriate application, e.g. image viewer for a JPEG. Not sure why it downloads a website first, though.

In any case, given it significantly slows down opening links and the fact that web browsers can open virtually any file these days, maybe we should revisit the default for that option to just open http(s) links in the browser no matter what.
Comment 4 Matej Mrenica 2018-10-19 06:26:04 UTC
(In reply to Kai Uwe Broulik from comment #3)
>Is "open in application based on the contents"
> checked?

No it's not: https://imgur.com/a/1ln6g1m

If I make it so, it gets even worse. Webpages begin to open in Libreoffice Writer (to edit them I guess).
Comment 5 Kai Uwe Broulik 2018-10-19 06:39:58 UTC
Can't reproduce then. Please provide the output of the following commands

xdg-mime query default text/html
xdg-mime query default x-scheme-handler/http
xdg-mime query default x-scheme-handler/https
xdg-settings get default-web-browser
kreadconfig5 --file kdeglobals --group General --key BrowserApplication
Comment 6 Matej Mrenica 2018-10-19 06:43:31 UTC
(In reply to Kai Uwe Broulik from comment #5)
> Can't reproduce then. Please provide the output of the following commands
> 
> xdg-mime query default text/html
> xdg-mime query default x-scheme-handler/http
> xdg-mime query default x-scheme-handler/https
> xdg-settings get default-web-browser
> kreadconfig5 --file kdeglobals --group General --key BrowserApplication

In this order:

libreoffice-writer.desktop
userapp-Nightly-8ZJWMZ.desktop
userapp-Nightly-8ZJWMZ.desktop
firefox-nightly.desktop
firefox-nightly.desktop
Comment 7 Andrew Crouthamel 2018-11-05 03:03:23 UTC
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!
Comment 8 Matej Mrenica 2018-11-05 07:24:07 UTC
The requested info was provided, wasn't it?
Comment 9 Andrew Crouthamel 2018-11-05 14:03:33 UTC
(In reply to mthw0 from comment #8)
> The requested info was provided, wasn't it?

Looks like it has, just the Status was accidentally left in NEEDSINFO. Moving to REPORTED.
Comment 10 Matej Mrenica 2018-11-13 19:34:15 UTC
This bug by itself wouldn be that bad but there are some other thing that make it even worse. Webpages openned like this are often changed (or damaged). In the worst cases links are not openned at all and a warning like this "Folder with name /home/mthw/.cache/kioexec/krun/8099_0/ already exists." appears, not necessarily when the same link is oppened twice.
Comment 11 Matej Mrenica 2018-11-20 09:46:50 UTC
Created attachment 116424 [details]
Screenshot

All 'get new ...' windows are affected like this
Comment 12 Nate Graham 2019-01-23 03:45:51 UTC
Can't reproduce myself, but I recognize a lot of these symptoms. It
s what happens when KIO is told to fetch a remote resource from a GTK app. Usually this happens only for things on like Samba and NFS shares; it shouldnb't be happening for HTTP(s) links. The fact that it is makes me suggest that LibreOffice is sending the URL request strangely, or else your browser has gotten de-registered to handle HTTP(s) URLs.

If you change your default web browser to just the regular Firefox, does the issue presist?
Comment 13 Matej Mrenica 2019-01-23 08:25:18 UTC
After further testing: Firefox (Stable) works correctly, Firefox Nightly (AUR) also works correctly. The problems only happens when using FF Nightly from a tarbal. So since I replaced it everything seems to run fine. Could you by any chance try this with a FF Nightly from a tarbal if you see the same issue?
Comment 14 Nate Graham 2019-01-23 23:03:08 UTC
Definitely a problem with using Firefox nightly from a tarball: system integration piece didn't get installed properly. Other than AppImages, Linux apps aren't self-contained; they need various system integration bits copied to various places. Making sure that this happens is one of the the advantages to using either AppImages or a package manager.
Comment 15 Alex Rocha 2019-01-23 23:42:58 UTC
I had the same problem today. In my case, it was with Chromium Stable for Arch Linux x64 (latest Chromium/Kernel/Plasma/Frameworks/Qt). Links throughout the system, including KDE/Qt applications, opened as "file:///home/alex/.cache/kioexec/krun/15088_0/whats-new"

It happened after I added a second user in Chromium. In the Plasma application settings, in Default Web Browser, I had "with the following command: chromium". I changed the command to chromium --profile-directory="Default" and it was fixed.
Comment 16 Nate Graham 2019-01-23 23:47:10 UTC
Very weird. That one definitely seems like a bug in Chromium, and I encourage you to report it to them.
Comment 17 t.soernes 2019-03-09 22:09:23 UTC
I have the same problem with Plasma 5.14.5.1 and Firefox 65.0.2-1 (non nightly) on fedora 29
Comment 18 t.soernes 2019-03-09 22:16:53 UTC
Firefox is installed from default repository not tarball. Running the commands from Kai Uwe Broulik all yield "firefox.desktop".
Comment 19 shscs911 2019-04-01 12:30:52 UTC
I had the same issue with opening links from Calibre Ebook Viewer in Google Chrome Stable. It was resolved after adding a '%U' to the commandline flag. '/usr/bin/google-chrome-stable --allow-running-insecure-content' ==> '/usr/bin/google-chrome-stable %U --allow-running-insecure-content'.
Comment 20 Mitchell 2020-02-11 14:22:11 UTC
Having the same issue. Trying to open any link from an application that isn't my browser results in this. Tried on Google Chrome, Chromium and Firefox.
Comment 21 Avamander 2020-08-18 21:56:22 UTC
I solved it by purging okular, kate, libreoffice-writer, firefox. Resetting default application in system settings and then setting it to /usr/bin/chromium-browser.
Comment 22 Avamander 2020-08-18 21:57:53 UTC
This also happens on Ubuntu 20.04, so not just Arch packages.
Comment 23 Avamander 2020-08-18 21:59:32 UTC
I also wouldn't call or mark it resolved.

I had to change nothing in my Chromium settings and all my packages are mainline. This is something weirder.
Comment 24 Dolandemort 2020-10-12 01:34:04 UTC
I discovered the cause of this for me was having the incorrect command set in the firefox.desktop file listed in the start menu (not sure how it's called in KDE). I found it was necessary to specify "/usr/bin/firefox %U" instead of just "/usr/bin/firefox".
Comment 25 Airton 2021-05-19 21:10:46 UTC
(In reply to Dolandemort from comment #24)
> I discovered the cause of this for me was having the incorrect command set
> in the firefox.desktop file listed in the start menu (not sure how it's
> called in KDE). I found it was necessary to specify "/usr/bin/firefox %U"
> instead of just "/usr/bin/firefox".

Excellent! Thank you! This is exactly what was happening here and that %U save me. Or my computer!

My system is a Kubuntu 20.04 and the problem was with Google Chrome needing that %U in menu's launcher.
Comment 26 emg81 2021-09-29 15:21:06 UTC
(In reply to Dolandemort from comment #24)
> I discovered the cause of this for me was having the incorrect command set
> in the firefox.desktop file listed in the start menu (not sure how it's
> called in KDE). I found it was necessary to specify "/usr/bin/firefox %U"
> instead of just "/usr/bin/firefox".

Thanks, that helped me too. That %U was missing in my case.