Open Bug 266600 Opened 21 years ago Updated 1 year ago

Open containing folder function does nothing (KDE)

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Version:
1.8 Branch
Platform:
x86
Linux
Type:
defect

Tracking

()

People

(Reporter: johann.petrak, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

This has been tested with the 1.0RC1. When right-clicking a download in the download manager, the option "open containing folder" does nothing at all.
Clicking "open" in the dialog manager, after a file has been downloaded, does nothing in Linux. In Windows it does actually opens the file with the registered program. In the download manager, clicking the directory name that goes after "All files downloaded to" does nothing in Linux. In Windows it actually opens the folder that contains all downloads.
Clicking "open" in the dialog manager, after a file has been downloaded, does nothing in Linux. In Windows it does actually opens the file with the registered program. In the download manager, clicking the directory name that goes after "All files downloaded to" does nothing in Linux. In Windows it actually opens the folder that contains all downloads.
I installed Suse 9.2 and it seems to work now. I guess it was a problem only with Suse 9.1. Sorry about the double post before.
I just tried this and realized it is implemented in a totally flawed way: it started nautilus(!), actually forcing a Gnome desktop on top of my KDE desktop. This is an odd and bad idea: FF does have a built-in way to show local directories with the file:/// protocol. The nautilus program or Gnome might not even be installed on the system FF is running on. FF should not rely on external programs to do that and if it supports that as an additional option, it should allow the user to easily which program gets started and how.
(In reply to comment #4) You are right. It starts nautilus even though it is not my default browser. There is no way to make it start in konqueror. If nautilus is not installed it doesn't work at all.
QA Contact: ali → download.manager
Assignee: bugs → nobody
Bug still alive 3 years later. See bug 270547.
Summary: Open containing folder function does nothing → Open containing folder function does nothing (KDE)
Version: 1.0 Branch → 2.0 Branch
Well, there is in fact a very good loader in KDE called KGet usually very well appreciated. A script has been proposed some time ago to replace the unusable Firefox loader in KDE with KGet. It partially works with Fx 2, because probably developed for Fx 1.5. Sure a small update of this patch would be a fair proposal to KDE users. See: KGet integration for Mozilla and Firefox http://www.polinux.upv.es/mozilla/mejoras.php?idioma=en Script: http://www.polinux.upv.es/mozilla/improvements/kget4mozilla/kget4mozilla-0.2.sh
This should detect whether KDE is running via the DESKTOP_SESSION variable (seeing if it says "kde") and if so, it should use "kfmclient exec" to open the containing folder, making it use KDE's default file manager. But apparently Mozilla only cares about GNOME.
It seems the conclusion of this bug is simply.... in KDE, better use Konqueror.
This is related to Bug 386519. Adding dependency.
Depends on: 386519
Bug 386519 is mixing gnome discussion. To summarize: With Firefox installed in KDE (not gnome), when right-clicking a download in the download manager, the option "open containing folder" does nothing at all. (It should not take 4 years to check/confirm this bug).
Product: Firefox → Toolkit
This also happens in Firefox 3 in Kubuntu Hardy. Creating a symlink from dolphin to nautilus does not fix this. Creating a network.handler-protocol.app.file neither.
Bug 452626 is a duplicate of this one.
(In reply to comment #14) > Bug 452626 is a duplicate of this one. It is not. As I read that bug /something/ happens on KDE with dolphin now. The issue there is that the filemanager does not show the right directory. Could somobody with a plain KDE with dolphin please sort the things out? The 'open containig folder' stuff works fine on gnome but not on KDE. But what's the real issue? Fault of KDE or $Mozilla?
This bug is a really ugly one ! In my case cervisia (KDE CVS tool) is startet which just reports an error. It seems this happens because the entry inode/directory=... in /applications/mimeinfo.cache lists that as the first one (which should not matter). I tried this with a clean user profile. No nautilus is installed here. xdg-open file:///... opens dolphin here as intended. I think firefox should better use this as stated in https://bugzilla.mozilla.org/show_bug.cgi?id=258085#c5 ArchLinux 686 KDE 4.2.0 Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5 (Binary downloaded from mozilla.org not from ArchLinux)
It seems that firefox (and most GTK apps running in kde3 and kde4, such as file-roller and catfish) don't respect kde's file type associations. Instead firefox looks at: - /usr/share/applications/defaults.list : this is, AFAICT, a static file created when you first install the system AND - /usr/share/applications/mimeinfo.cache : this is a dynamically changing file, it's changed when you install a new programme. So for example it will change when you install nautilus or pcmanfm in kde. Firefox will look first at defaults.list but will give preference to mimeinfo.cache. So if the same entry (e.g. inode/directory) exists in both defaults.list and mimeinfo.cache firefox will take whatever mimeinfo.cache says. You can manually make "Open containing folder" use your favourite programme by editing /usr/share/applications/mimeinfo.cache . Basically you need to edit the "inode/directory=" entry and put the desired application's .desktop name up front, so to use dolphin, change it to: inode/directory=kde4-dolphin.desktop; Notice the extra kde4 in kde4-dolphin.desktop , this is necessary because dolphin.desktop is not in the same folder as mimeinfo.cache; mimeinfo.cache is in /usr/share/applications while dolphin.desktop is in /usr/share/applications/kde4 . If a .desktop file is going to be used and it exists in /usr/share/applications then use its plain name without a prefix. To use konqueror instead of dolphin it should be: inode/directory=kde4-kfmclient_dir.desktop; Be aware though that /usr/share/applications/mimeinfo.cache will be changed automatically when you install a new *relevant* programme/file manager such as nautilus. However you can maintain a local copy that will not be changed when you install anything else, put a copy of defaults.list and mimeinfo.cache in your home folder in ~.local/share/applications. The problem that existed with dolphin not using the right folder url has vanished in kde 4.2. The problem was that by default the command line in dolphin.desktop was "dolphin %i -caption "%c" %u" and that didn't work in kde 4.1.2 but it works OK with the same command line in KDE 4.2 (I wouldn't take that to the court, though :) ) I know for sure that it's working OK in kde 4.2 . My system specs: KDE 4.2 Firefox 3.0.5 A wild guess is that in gnome there's gnome-settings-manager that makes whatever file associations you change in Gnome get applied when you log into Gnome, but gnome-settings-manager isn't run in KDE.
(In reply to comment #17) Thank you for explaining all this. I found another workaround somewhere else: Edit cervisia.desktop and kfmclient-dir.desktop located in /usr/share/applications/ and add a line "OnlyShowIn=KDE;" After update-mime-cache firefox will use dolphin.
(In reply to comment #18) Sorry, I meant /usr/share/applications/kde4/
This seems also to be a problem with Xfce. I worked around this now with this command: xdg-mime default Thunar-folder-handler.desktop x-directory/normal For KDE something like that one can be used: xdg-mime default dolphin.desktop x-directory/normal For GNOME there seems to be a different one named x-directory/gnome-default-handler which could be set to nautilus-folder-handler.desktop. What xdg-mime does is simply writing a line like x-directory/normal=dolphin.desktop into the file ~/.local/share/applications/defaults.list. Custom desktop files located in ~/.local/share/applications/ also work with this. I found all this by some googling and be trial and error. Unfortunately there seems to be no documentation about this. ArchLinux 686 Xfce 4.6.0 KDE 4.2.1 GNOME 2.24 Firefox 3.0.7 GranParadiso
Flags: wanted1.9.1?
I solved this by associating the file manager (thunar in my case) to "file" 'Content Type' on firefox preferred applications. Regards, Henrique Abreu Firefox 3.0.7 Xfce 4.4.2 Debian Squeeze
@Kurt (comment #20): unfortunately this does not appear to work for Ubuntu/Kubuntu. I have added those entries to ~/.local/share/applications/defaults.list: inode/directory=dolphin.desktop x-directory/normal=dolphin.desktop
Ideally dolphin.desktop is inside /usr/share/applications/kde4/ , so you have to prefix the entry with kde4-, so it becomes: x-directory/normal=kde4-dolphin.desktop Check where dolphin.desktop is located, I don't use ubuntu so I don't know where it's exactly on your system. Another thing I noticed is I have an entry named "file" in Edit> preferences> applications, selecting "use other" and then selecting /usr/bin/xdg-open, makes it open in the DE's preferred file manager. On a fresh profile I don't see the "file" entry, I don't know what creates it...
Yes, dolphin.desktop is in /usr/share/applications/kde4/, but adding the "kde-" prefix still does not make Firefox use it. Additionally, I've tried using xdg-open for the "file" type in Firefox' preferences, but "Show Containing Folder" still opens Nautilus. (directly calling "xdg-open /some/dir" works) It seems like Ubuntu makes it even worse (for me) than stock Firefox - I should focus on the bug report over there (https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/133133).
*** I think bug 555007 is not a duplicate of this bug. I unmarked it as duplicate of this one of here. Also, I found a workaround for it. ***
Blocks: 140751
I have two systems with Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 installed. One of them is running on KDE 4.6.0 on openSUSE 11.4, and the other KDE 4.9.5 on openSUSE 12.2. On the first one, "Open containing folder" correctly opens the directory using the default KDE file manager, Dolphin. On the second one, the correct directory is opened using the default Gnome file manager, Nautilus. No idea why one system correctly uses Dolphin but the other incorrectly chooses Nautilus.
(In reply to Tristan Miller from comment #30) Try this: - Create ~/.local/share/applications/defaults.list (edit it if it already exists) - Put this in it: [Default Applications] inode/directory=kde4-dolphin.desktop; save it and try "open containing folder" again.
(In reply to Ahmad Samir from comment #31) Yes, that fixes the problem on the openSUSE 12.2 system.
Alex Palecek added the following comment to Launchpad bug report 133133: I was having a similar problem with Firefox on Linux Mint 13 "Maya" MATE. For some reason, SoundConverter was associated with this MIME type, so that when I tried to "Open Containing Folder" in Firefox, it would invoke SoundConverter for any download. By changing the entries in ~/.local/share/applications/mimeapps.list from : inode/directory=soundconverter.desktop; to : inode/directory=caja.desktop; functionality was restored. Thanks! -- http://launchpad.net/bugs/133133
Since I am not a programmer, I cannot submit a patch. However, can't someone simply replace whatever is opening Nautilus with xdg-open? You don't even have to know how it works or where the files are. Just to be clear though, anything involving xdg uses XDG standards. If one is curious, or simply wants or needs to know the standard, check out multiple publications at freedesktop.org. I understand that Mozilla has abandoned Qt, but that does not mean that Linux distributions of Mozilla software should be Gnome specific. The point of the XDG standard is that anything following it should work for any desktop environment that follows it. Both Gnome and KDE follow those standards.
(In reply to Tristan Miller from comment #30) > I have two systems with Mozilla/5.0 (X11; Linux x86_64; rv:19.0) > Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 installed. One of them is > running on KDE 4.6.0 on openSUSE 11.4, and the other KDE 4.9.5 on openSUSE > 12.2. On the first one, "Open containing folder" correctly opens the > directory using the default KDE file manager, Dolphin. On the second one, > the correct directory is opened using the default Gnome file manager, > Nautilus. No idea why one system correctly uses Dolphin but the other > incorrectly chooses Nautilus. Probably on one of the systems you have Nautilus installed and on the other you don't..... Anyway... This is a very annoying bug that is still handled very badly... This bug is still valid for FF 29.0.1 in Linux. It turns out that FF (tested on 29.0.1 on Gentoo) when built with dbus support has a wrong way to "Open containing folder". It first calls (instead of checking if exists first and then calling) org.freedesktop.FileManager1 on the session bus and thus if nautilus is installed it is started as "/usr/bin/nautilus --no-default-window" and in this way FF doesn't honor the XDG at all. So for now a workaround is either to delete the /usr/share/dbus-1/services/org.freedesktop.FileManager1.service or change its Exec to "dolphin" (if you are under KDE, though that may have implications 'cause dolphin doesn't register any org.freedesktop.FileManager1). It needs fix definitely or at least an option to choose in FF preferences Please see also bug #258085
(In reply to PhobosK from comment #36) I've seen the same issue in Fedora. My workaround was to "sabotage" the org.freedesktop.Filemanager1 dbus service by creating ~/.local/share/dbus-1/services/org.freedesktop.FileManager1.service and changing the Exec line to e.g. /usr/bin/false or /usr/bin/true; this is better since it's persistent and isn't affected by system updates... etc. This makes Firefox use whatever file manager I set in ~/.local/share/applications/defaults.list (see comment #31). Changing Exec to /usr/bin/dolphin somehow made "open containing folder" open the file manager, but the firefox UI gets sort of blocked/hung for a while, probably because firefox tries to query the capabilities of org.freedesktop.FileManager1 via dbus first, (just a guess). [..]
Add to the above (about changing Exec to /usr/bin/dolphin) is that I get two dolphin windows opened, one at ~ and the other to the actual folder containing the file from the download manager/library, until the second window is opened Firefox is hung.
I first hit the org.freedesktop.FileManager1 issue a couple of months ago, so my memory is a bit hazy on the issue. In the workaround I posted in comment#37 the Exec line has to be /usr/bin/false, otherwise there's a delay before the file manager is opened. Most likely because /usr/bin/false returns an exit code 1.
Blocks: 1042042
This bug has been open for 10 years. LOL. Maybe I'm oversimplifying things in my head, but from a design perspective it sure would be nice if there were a "Folder" file type in the Applications settings. Since there are dozens of file managers for GNU-Linux, and several mainstream desktop environments to choose from, I would certainly not expect Firefox to read my mind as to what my file manager preference is.
Currently Firefox 33 is using org.freedesktop.FileManager1 to open a filemanager. Sadly, only Nautilus implements this interface. It's not just opening a filemanager but also bidirectional communication with the caller. https://bugzilla.opensuse.org/show_bug.cgi?id=904229#c2 Is Firefox using this bidirectional communication feature or something else, special from org.freedesktop.FileManager1 ? If Firefox isn't using the special features of org.freedesktop.FileManager1, just change Firefox to use "xdg-open $DIRECTORY" to open a filemanager or to look up the default filemanager in: ~/.local/share/applications/mimeapps.list (has priority) /usr/share/applications/mimeinfo.cache If Firefox uses special features from org.freedesktop.FileManager1: In a perfect world, Firefox should check if Nautilus is set as the default filemanager. E.g. running "xdg-mime query default inode/directory" which checks the files: ~/.local/share/applications/mimeapps.list (has priority) /usr/share/applications/mimeinfo.cache Alternatively, Firefox could check if DESKTOP_SESSION is set to "gnome". I wouldn't suggest to check for DESKTOP_SESSION=KDE, because there are a lot of other desktop environments which also use other filemanagers then Nautilus. If the results is negative (depended on which strategy was chosen), Firefox should use the default filemanager (either the on set by the system or set by the user). This can be done by running "xdg-open $DIRECTORY" or looking up the default filemanager in: ~/.local/share/applications/mimeapps.list (has priority) /usr/share/applications/mimeinfo.cache
I am starting to suspect developer malice here. This bug is not fixed but **hardened** over the years: loopholes that enable workarounds get fixed instead. I wonder when Firefox will actually start reinstalling nautilus from the repos when it detects that I have deleted the binary and symlinked it to dolphin (because nothing else works at this point).
Everyone who worries about this bug, please click the little "vote" button at the top and vote for this bug to be solved! Every vote counts! ;-)
(In reply to kolAflash from comment #43) > Everyone who worries about this bug, please click the little "vote" button > at the top and vote for this bug to be solved! > Every vote counts! ;-) The main purpose of voting is to avoid the annoying and useless "Me too!" messages: see bug 374002. Votes do not influence which bugs get fixed. (In reply to Szczepan Hołyszewski from comment #42) > I am starting to suspect developer malice here. That seems uncalled for. Firefox developers working on Linux issues are very few and hard-working. They need more love and support and not users throwing accusations. Also, if you honestly want to see support of Linux continued, you are shooting yourself in the foot with such a comment: Which developer wants to work on supporting an OS when users of that OS accuse them of malice? Scaring developers away is not the way to improve such support! The reality is that there are very few Firefox developers that use GNU/Linux, and all of them probably use GNOME/GTK. GTK developers have contributed at lot to Mozilla/Firefox, whereas KDE has its own browser (Konqueror and now Rekonq). The people that have tried to improve Firefox on KDE have done so by creating add-ons or distribution-specific patches. This is a quick way to get results but tends to bitrot and break sooner or later. The *only* way Firefox support for KDE will improve is if people using Firefox on KDE join Firefox development and do it. If you cannot do it yourself for lack of time or skills, create a kickstarter and hire a developer that can. If you do not have skills, money, or time, and you cannot figure out another way to help, then resign yourself in silence because it will probably get worse. Attacking developers, whining and useless comments (mine ones included, unfortunately) only make developers *less* inclined to follow bug reports about KDE.
(In reply to M Lopez-Ibanez from comment #44) > (In reply to Szczepan Hołyszewski from comment #42) > > I am starting to suspect developer malice here. > > That seems uncalled for. I agree that this is a bit too much, no malice involved; I think it's mostly due to lack of time/resources....etc. > Firefox developers working on Linux issues are very > few and hard-working. Any official stats/references about how many Firefox devs are actually working on Linux? > They need more love and support and not users throwing > accusations. Also, if you honestly want to see support of Linux continued, > you are shooting yourself in the foot with such a comment: Which developer > wants to work on supporting an OS when users of that OS accuse them of > malice? Scaring developers away is not the way to improve such support! > > The reality is that there are very few Firefox developers that use > GNU/Linux, and all of them probably use GNOME/GTK. Again any references/stats? > GTK developers have > contributed at lot to Mozilla/Firefox, Well, the most obvious reason is that Firefox is built on GTK+*. I think if Firefox was built on Qt it would have gotten a lot of contribution from Qt devs, that's the nature of using a toolkit to build your software... > whereas KDE has its own browser > (Konqueror and now Rekonq). That's not really a point since GNOME has its own browser too, it's called Epiphany, a WebKit based browser (it's been renamed to "Web" lately https://wiki.gnome.org/Apps/Web/). > The people that have tried to improve Firefox on > KDE have done so by creating add-ons or distribution-specific patches. This > is a quick way to get results but tends to bitrot and break sooner or later. > IIRC those changes were submitted as bug reports upstream but were rejected hence the distribution patches/addons. > The *only* way Firefox support for KDE will improve is if people using > Firefox on KDE join Firefox development and do it. If you cannot do it > yourself for lack of time or skills, create a kickstarter and hire a > developer that can. If you do not have skills, money, or time, and you > cannot figure out another way to help, then resign yourself in silence > because it will probably get worse. This issue isn't KDE specific; the issue here is that there's no easy was to make Firefox use whatever file manager you set as the default in Linux. Even under GNOME you'd hit the same problem if you want to use a file manager other than Nautilus; you can configure GNOME to use whatever file manager you want but Firefox would ignore those settings. Firefox could use xdg-open (this was suggested in previous comments in this report) which is supposed to be distro-agnostic; given xdg* isn't perfect but it's better than using a dbus method that's only implemented by Nautilus under GNOME. > Attacking developers, whining and > useless comments (mine ones included, unfortunately) only make developers > *less* inclined to follow bug reports about KDE. True, insulting devs isn't good any which way one thinks about it. But I think frustration can lead to such accusations flying around; the open-containing-folder feature misbehaving for anything other than Nautilus has been around for more than 8 years... that is rather a long time. /me going back to "resign myself in silence" :).
New discovery: uninstalling nautilus "solves" the problem. Here's my prophecy: the patch that will finally fix this bug will consist of deletions only.
This works for me in Kubuntu 14.04 without any additional configuration or work-around. I don't have nautilus installed.
If you have nautilus installed this becomes a problem because firefox wants to use dbus engine. Firefox apparently uses the dbus engine first to launch org.freedesktop.FileManager1 which nautilus is currently the only app that gets launched/used this way. You have to install your own org.freedesktop.FileManager1.service file in ~/.local/share/dbus-1/services Also look to see if you have other FileManager1 filemanagers registered to dbus. I had two custom Nemo and Caja, and i just copied those files from their default location to my home directory location and changed the Exec. Firefox gives up, and goes the xdg route - which I thought was supposed to be the standard. This is a complete mess. This link describes the process in detail: http://debian.distrosfaqs.org/debian-user/iceweasel-and-dolphin/ and https://bugzilla.mozilla.org/show_bug.cgi?id=1106916
This is also a problem on FF39 on Windows 7
(In reply to Moltres Rider from comment #49) > This is also a problem on FF39 on Windows 7 Works fine for me on FF40 Windows 7 Ultimate 64-bit
It does absolutely nothing for me in Windows 7 Ultimate 64-bit. It has been broken for me for several months. Using latest version (FF43). Why doesn't it work anymore for me?
UA:"Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 SeaMonkey/2.43a1" ID:20160101003002 en-US c-c:ca2c0fd7c80d758f98954ca7789cb59b3f8ad2d1 m-c:22f51211915bf7daff076180847a7140d35aa353 Both KDE and Gnome libraries present on the system. The X11 login screen is presented by KDE kdm (display manager) but IIUC the window manager is Gnome. When I click "Open containing folder" it opens in Dolphin (by KDE). Some people mentioned Nautilus, and that is installed here, but doesn't open. Note that I'm using the "new dowload manager" which comes built-in with SeaMonkey and used to be available as an extension for Firefox but isn't anymore. So I see two possibilities: - Maybe I'm not seeing it because SeaMonkey's "new download manager" is better? - Maybe I'm not seeing it because I've got Dolphin _in addition_ to Nautilus? In any case, here it does open the KDE file manager, even though my desktop (but not my X11 login screen) is supposedly Gnome and my SeaMonkey is built on Gnome3.
QA Whiteboard: [seamonkey-2.43-unaffected]

Open containing folder function does nothing (KDE)

Is this still an issue?

Compare with e.g. bug 893799 …

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 30 votes.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mak)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(mak)

(In reply to Graham Perrin from comment #53)

Open containing folder function does nothing (KDE)

Is this still an issue?
…

For me at least this is still an issue when using Konqueror as default filemanager. If using Dolphin as the default filemanager, and it responds to the org.freedesktop.FileManager1 dbus interface (this is the default setup in KDE AFAIK), Dolphin gets used appropriately and everything is fine.

Having Dolphin installed and Konqueror as default filemanager will result in Dolphin being used.

In KDE with Konqueror as default filemanager and multiple other filemanagers installed that have a .service file for the org.freedesktop.FileManager1 dbus interface (e.g. having both XFCE's Thunar and KDE's Dolphin installed) may/will result in one of those filemanagers being executed. In my case Thunar was consistently used, until a ln -s /usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service $XDG_DATA_HOME/dbus-1/services/org.freedesktop.FileManager1.service. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1285711#c47

So:

  • If your default filemanager actively listens/responds to the org.freedesktop.FileManager1 dbus interface, it works as expected
  • If your default filemanager supports org.freedesktop.FileManager1 but doesn't actively listen/respond to it, it depends
  • If your default filemanager doesn't support org.freedesktop.FileManager1 but other installed filemanager(s) do, it's still broken
  • If your default filemanager doesn't support org.freedesktop.FileManager1 and no other installed filemanager(s) do (or you overrule the service so nothings responds to it), it works as expected

Firefox 107.0.1 (64-bit), Slackware64-current, KDE Frameworks 5.100.0, XFCE 4.16, Thunar 4.16.11

You need to log in before you can comment on or make changes to this bug.