When I open a link in external browser from Akregator, I get a page like file:///var/tmp/kdecache-kadler/krun/3234.0.kde-ships-april-updates-plasma-workspaces-applications-and-platform instead of http://dot.kde.org/2012/04/04/kde-ships-april-updates-plasma-workspaces-applications-and-platform At first, I thought this was an issue in Akregator and just lived with it, right clicking on the entry and choosing copy url and pasting it in Firefox. I finally decided to report the bug and used the handy Help->Report Bug menu entry, which took me to file:///var/tmp/kdecache-kadler/krun/3016.0.wizard.cgi. So this must not be a bug in Akregator, but deeper in the stack. The easiest way to reproduce is using kde-open on a url. kde-open http://www.google.com gives me file:///var/tmp/kdecache-kadler/krun/3255.0. I am running openSUSE 12.1 x86-64 using KDE 4.8.2 (just updated and still there). Oddly enough, I don't have this problem with my home machine only my work machine. I did notice https://bugs.kde.org/show_bug.cgi?id=106239 but I'm not sure how applicable that is since that is from KDE 3.4. I looked under System Settings -> Default Applications -> Web Browser and I have it set to open using the firefox command. If I change it to 'in an application based on the contents of the URL' and do kde-open http://www.google.com, the cache file gets opened in kate.
Having the same problem (for years). It is especially unpractical when an application opens an URL directly without it being visible to the user (e.g. Inkscape → Keys and Mouse Reference).
Confirmed here. Started having the problem since upgrading to KDE 4.9. Apparently you can work around the issue by: 1/ Opening System Settings; 2/ Workspace Appearance and Behavior > Default Applications > Web Browser 3/ Select 'in the following browser' instead of 'in an application...' 4/ Select your browser in the menu (probably under the Internet folder). This requires that your browser has a .desktop entry somewhere in your application folder. That .desktop entry should contain everything needed to launch URLs properly. Now URLs behave normally. I don't know how that got broken in the upgrade, though.
Confirming that this works. Thank you! After creating the .desktop file and restarting X I had to manually change the entry in systemsettings to something else than firefox and than back to firefox – Just choosing it from the list (where it now appears with the .desktop file) did not work, the required information from the .desktop file was not updated. cat /usr/share/applications/kde4/firefox.desktop [Desktop Entry] Type=Application Exec=/usr/local/bin/firefox %u MimeType=application/x-www-browser; Icon=/PATH/TO/firefox/icons/mozicon128.png Terminal=false Name=Firefox Categories=Qt;KDE;Network
I'm seeing the same problem on ArchLinux. kde-open --version Qt: 4.8.2 KDE Development Platform: 4.9.1 KIO Client: 2.0 My default browser is Chromium. However, if I switch my default browser to Firefox, everything works normally.
Glen: fix the chromium desktop file to have %u in its Exec line.
I can confirm this bug. It appeared after upgrading from openSUSE 12.2 (KDE 4.8.4) to openSUSE 12.3 (KDE 4.10.3). The workaround in comment #2 and #3 is not working for me. The .desktop file looks fine dennis@linux-7cch:~> cat /usr/share/applications/firefox.desktop [Desktop Entry] Categories=Network;WebBrowser;GTK; Encoding=UTF-8 Name=Firefox GenericName=Web Browser Comment=Web Browser TryExec=firefox Exec=firefox %u Icon=firefox Terminal=false StartupNotify=true MimeType=text/html;text/xml;application/xhtml+xml;application/vnd.mozilla.xul+xml;text/mml;application/x-xpinstall;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp; Type=Application Keep in mind that there is no /usr/share/applications/kde4/firefox.desktop, only /usr/share/applications/firefox.desktop. Copying the file didn't help here. Other than in comment #4 this is not browser specific for me, it happens with Firefox and Konqueror set via Workspace Appearance and Behavior > Default Applications > Web Browser. This is a usability no-go for me. Hope this gets fixed.
I've managed to work around the issue for some time, but had forgotten what I'd done. Dennis's update today prompted me to figure this out. Ok, so the default web browser has two options: use an application based on the contents or in the browser of your choice, which gives an input box and a button to pick from the menu. When I choose Konqueror or Mozilla Firefox from the menu under Internet -> Web Browser, I get the error scenario I described in comment #1. If I pick Chromium, I get the expected behavior of opening a URL. If I just type firefox or konqueror in the input box, I also get the expected behavior of opening a URL. Looking in the menu editor, it seems that both the Konqueror and Mozilla Firefox entries do not have %u in the command. Once I added %u, it works when I select an entry from the menu. I'm not sure where KDE Menu Editor saves it's changes (/usr/share/applications/firefox.desktop was unaffected and had the %u), but I'd check both it and the desktop files for your web browser under /usr/share/applications to ensure that they have %u in the Exec field.
Thanks Kevin for the suggestions. I added %u after firefox in the input box in Workspace Appearance and Behavior > Default Applications > Web Browser option page. Now indeed it opens the URL, BUT a) not in a new tab but in a new Firefox window (this was different before the upgrade with the same Firefox v21 and the same settings: Firefox opens internal links as tabs as it should be) and b) it opens the URL twice. Now with Konqueror: If I use konqbrowser the bug appears as expected, but when I add %u after it, I get the error "Cannot find program konqbrowser." (my translation) and it opens instead in Firefox as a new tab but not as URL but the file:///var/tmp/kdecache etc. In /usr/share/applications/firefox.desktop I have the %u after firefox, as you can see in comment #6. So unfortunately your workaround haven't worked for me and this seems to be clearly a bug and not a misconfiguration on our side.
I was having this issue for quite some time. Following some research, I went to the System Settings, under Default Applications, and i added '$s' as a parameter to the browser path for the Web Browser Component. This seems to appropriately handle opening links in all kde applications. For example, "/usr/bin/chromium-browser $s" I'm not so sure if this is a bug, or just something that needs better documentation. Is the '$s' parameter specific to kde?
Thanks Hari Seldon. The $s is working for me (Firefox 21, KDE 4.10.3) too.
Firefox told me after a restart, that it was not the standard browser. If I accept its offer to make it the standard browser, I will have again firefox %u instead of firefox $s. If $s is really the only way to fix this bug, one has to change the behaviour of firefox.
%u is the right way to say "I support urls", combined with X-KDE-Protocols=... (list of supported protocols), or Categories=KDE (but not for firefox). If both are not present, then KRun assumes the app supports http, https and ftp. That's supposed to cover the case of firefox, which probably doesn't have X-KDE-Protocols=... nor Categories=KDE. I have never seen $s before. From a KDE point of view, $s makes no sense at all.
So should we better report this downstream, e.g. in the openSUSE bug tracker, or upstream to mozilla?
Right click on kickoff menu launcher icon > Edit applications. Add %u to the command for firefox or chrome. Then save changes. This fixes problem for me.
@Nikola Schnelle: Please read the comments before posting! %u is not working for many others. For me actually only %s was working. But since I had another KDE version back then, this bug may be vanished by now.
(In reply to comment #9) The "$s" workaround is also working for me on OpenSUSE 13.1 wih KDE 4.11.2.
Might be related to bug 341055
%u worked for me under KDE Plasma Version 5.5.5 `/opt/google/chrome/google-chrome --user-data-dir=/dbcom/google-chrome-profiles/Default --enable-logging %u`
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
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 mark the bug 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!
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!