"Open containing folder" is only working if nautilus is present
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Confirmed
|
Unknown
|
|||
firefox (Ubuntu) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Binary package hint: firefox
Tools->Downloads-> (Right click)->Open containing folder
Result: Nothing happens (not even an error).
Expected: An error, a dialog asking to choose a file manager or just konqueror showing the folder.
Fix: add the following line to prefs.js
user_pref(
ProblemType: Bug
Architecture: i386
Date: Fri Aug 17 12:54:22 2007
DistroRelease: Ubuntu 7.04
Package: firefox 2.0.0.5+1-0ubuntu1
PackageArchitec
SourcePackage: firefox
Uname: Linux localhost 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux
In Mozilla Bugzilla #266600, Johann Petrak (johann-petrak) wrote : | #1 |
In Mozilla Bugzilla #266600, Gnikolov (gnikolov) wrote : | #2 |
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.
In Mozilla Bugzilla #266600, Gnikolov (gnikolov) wrote : | #4 |
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.
In Mozilla Bugzilla #266600, Johann Petrak (johann-petrak) wrote : | #5 |
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 Mozilla Bugzilla #266600, Gnikolov (gnikolov) wrote : | #6 |
(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.
In Mozilla Bugzilla #258085, Gervase Markham (gerv-mozilla) wrote : | #7 |
This is an automated message, with ID "auto-resolve01".
This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.
While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.
If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.
The latest beta releases can be obtained from:
Firefox: http://
Thunderbird: http://
Seamonkey: http://
In Mozilla Bugzilla #258085, Peter-vanderwoude (peter-vanderwoude) wrote : | #8 |
I'm not sure you can't do this with the Launchy extension
In Mozilla Bugzilla #258085, Dsotm (dsotm) wrote : | #9 |
(In reply to comment #2)
> I'm not sure you can't do this with the Launchy extension
You can't.
This bug still exists. Even with a custom filemanager defined in Windows, "open containing folder" in FF 2.0 still uses Windows Explorer.
In Mozilla Bugzilla #258085, Stephanie Daugherty (sdaugherty-deactivatedaccount) wrote : | #10 |
Confirming as feature request.
In Mozilla Bugzilla #266600, Diorser (diorser) wrote : | #11 |
Bug still alive 3 years later.
See bug 270547.
In Mozilla Bugzilla #266600, Shawn Wilsher (sdwilsh) wrote : | #12 |
*** Bug 270547 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #266600, Diorser (diorser) wrote : | #13 |
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://
Script:
http://
Manuel López-Ibáñez (manuellopezibanez) wrote : "Open containing folder" not working in Kubuntu | #14 |
Binary package hint: firefox
Tools->Downloads-> (Right click)->Open containing folder
Result: Nothing happens (not even an error).
Expected: An error, a dialog asking to choose a file manager or just konqueror showing the folder.
Fix: add the following line to prefs.js
user_pref(
ProblemType: Bug
Architecture: i386
Date: Fri Aug 17 12:54:22 2007
DistroRelease: Ubuntu 7.04
Package: firefox 2.0.0.5+1-0ubuntu1
PackageArchitec
SourcePackage: firefox
Uname: Linux localhost 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux
Manuel López-Ibáñez (manuellopezibanez) wrote : | #15 |
Manuel López-Ibáñez (manuellopezibanez) wrote : | #16 |
Even better would be to use the "--select" option of konqueror to focus on the relevant file as FF does in Windows, but I don't see how to make that work with prefs.js syntax.
Why Firefox developers hate Linux so much and KDE in particular? :-(
Changed in firefox: | |
status: | New → Confirmed |
In Mozilla Bugzilla #266600, D. Brodzik (amyrose) wrote : | #17 |
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.
In Mozilla Bugzilla #266600, Diorser (diorser) wrote : | #18 |
It seems the conclusion of this bug is simply....
in KDE, better use Konqueror.
In Mozilla Bugzilla #266600, Jürgen 'jiha' Harter (jiha-bugzilla) wrote : | #19 |
This is related to Bug 386519. Adding dependency.
Jani Monoses (jani) wrote : Re: "Open containing folder" not working in Kubuntu | #20 |
it is not working in xubuntu 8.04 either. Is firefox not using xdg-open to open a folder? Is nautilus hardcoded now in upstream or ubuntu patches? IIRC this used to work in xubuntu with thunar in 7.10
Changed in firefox: | |
importance: | Undecided → Medium |
No joy in Kubuntu 8.04 KDE 3.5.9 either. It's a tad inconvenient really and this has been a problem for a while now! Two distributions have gone by and this has persisted!
Alexander Sack (asac) wrote : | #22 |
this needs to be properly filed upstream ...
affects firefox
status incomplete
i assume this is a firefox 3 issue
affects ubuntu/firefox-3
status confirmed
unfortunatley, ffox 2 wont see any non-critical fixes anymore
affects ubuntu/firefox
status wontfix
Changed in firefox-3.0: | |
status: | New → Incomplete |
Changed in firefox: | |
status: | Confirmed → Incomplete |
status: | New → Incomplete |
I'm not sure whether it's a Firefox 3 issue myself, but I can confirm that it's an issue with Firefox 2. I reinstalled it when I upgraded to Kubuntu Hardy Heron and the problem still persists. It would be nice if this was fixed for Firefox 2 though since I'm not sure when Firefox 3 is going to stop being beta and then there's the fact that anyone using (K)(X)Ubuntu 8.04 is stuck with this version until October.
John Vivirito (gnomefreak) wrote : Re: [Bug 133133] Re: "Open containing folder" is only working if nautilus is present | #24 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
TWO wrote:
| I'm not sure whether it's a Firefox 3 issue myself, but I can confirm
| that it's an issue with Firefox 2. I reinstalled it when I upgraded to
| Kubuntu Hardy Heron and the problem still persists. It would be nice if
| this was fixed for Firefox 2 though since I'm not sure when Firefox 3 is
| going to stop being beta and then there's the fact that anyone using
| (K)(X)Ubuntu 8.04 is stuck with this version until October.
|
Firefox-2 will not see a fix for this since it is nearing EILS and at
this point Firefox-2 will only see very Important fixes for example any
and all security risks firefox-2 wont load (do to upstream error not
profile error) things like that. I wont say that this bug isnt important
im just saying this is what is planed at this point. Looks like
Firefox-3 is very near release releasing EC1 and if not blockers found
they will push that to final in a few weeks.
Yes this is a Firefox bug/feature not sure which at the moment but i see
it in Firefox-3 b5 and rc1 both of which are our(Ubuntu-
Im gonna wait and look at a few things to see if we can ship the fix, I
will ask our head maintainer about what he would like to do. Thiis can
be fixed in Firefox-2 in Intrepid but we are thinking about removing
Firerfox-2 just before Intrepid release if we see that Firefox-3 is
doing good standing on its feet.
- --
Sincerely Yours,
~ John Vivirito
https:/
https:/
Linux User# 414246
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iD8DBQFILK6bqig
PreH8xieGyPUxtJ
=PNwD
-----END PGP SIGNATURE-----
Alexander Sack (asac) wrote : Re: [Bug 133133] Re: "Open containing folder" is only working if nautilus is present | #25 |
On Thu, May 15, 2008 at 06:35:39AM -0000, TWO wrote:
> I'm not sure whether it's a Firefox 3 issue myself, but I can confirm
> that it's an issue with Firefox 2. I reinstalled it when I upgraded to
> Kubuntu Hardy Heron and the problem still persists. It would be nice if
> this was fixed for Firefox 2 though since I'm not sure when Firefox 3 is
> going to stop being beta and then there's the fact that anyone using
> (K)(X)Ubuntu 8.04 is stuck with this version until October.
>
The fact that firefox 3 is called "beta" doesn't mean that its
instable or something. We put firefox 3 intentionally as default as
our testing showed that its ready for prime time.
BTW, mozilla thinks so too:
http://
Please test if this an issue for you in ffox 3
Firefox 2 wont see any non-critical fixes. Marking accordingly
affects ubuntu/firefox
status wontfix
- Alexander
Changed in firefox: | |
status: | Incomplete → Won't Fix |
In Mozilla Bugzilla #266600, Diorser (diorser) wrote : | #26 |
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).
darkmethod (darkmethod) wrote : | #27 |
see:
http://
Open Containing Folder in Firefox under Linux
Posted by flori on 09/11/2007
After Downloading a file in firefox and right-clicking on the filename in the download manager, you can choose the popup menu entry "Open Containing Folder". This should open a filebrowser for the directory this file was saved in. I have to admit, that this never worked for me under Linux, only under MacOS X and under Windows. I assume the reason for this is, that you have a lot of options under Linux, but no general default for a file manager. Firefox did never show a very smart reaction (and only displays an error) if no filebrowser could be found: Perhaps asking me what to do would be a good idea?
I finally couldn't take it anymore and researched how to configure this feature. I wanted XFCE4's file manager Thunar to be opened, so this is what you have to do: Open the about:config dialog in you location toolbar (or pick it from the Help menu). Now right click onto the configuration entry list, and choose New -> Boolean from the popup menu. Create the following two entries and set them both to true:
network.
Now choose New -> String from the popup menu, and set the value to thunar:
network.
This will start thunar with containing directory (with a file:// url) as an argument. You can as well use nautilus or konqueror or whatever here. Another possibility is to use open, which would cause firefox itself to open the directory as a file:// url.
In Mozilla Bugzilla #258085, panzi (grosser-meister-morti) wrote : | #28 |
This bug is really annoying for KDE users. Most fix it by making a link called "nautilus" linking "konqueror". But that's an ugly hack. Why not just use xdg-open (if it exits)? This will open the right app for the currently running desktop environment. There is no reason at all why this xdg-open should not be used under *nix. I for myself did an even uglier hack to tell Firefox to use Konqueror, see: http://
Just running xdg-open file://
In Mozilla Bugzilla #266600, Manuel López-Ibáñez (manuellopezibanez) wrote : | #29 |
This also happens in Firefox 3 in Kubuntu Hardy.
Creating a symlink from dolphin to nautilus does not fix this. Creating a network.
In Mozilla Bugzilla #266600, Manuel López-Ibáñez (manuellopezibanez) wrote : | #30 |
Bug 452626 is a duplicate of this one.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #31 |
This still does not work in Kubuntu Hardy with Firefox 3
Changed in firefox-3.0: | |
status: | Incomplete → New |
Manuel López-Ibáñez (manuellopezibanez) wrote : | #32 |
The workaround above doesn't work for me either. I don't get any warnings or errors or any output in console.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #33 |
There is a word-around here but it seems too invasive, so I haven't tested it. I don't want to break my profile.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #34 |
There is no information requested, so this cannot be Incomplete.
Changed in firefox: | |
status: | Incomplete → New |
Changed in firefox: | |
importance: | Undecided → Unknown |
status: | New → Unknown |
Changed in firefox: | |
status: | Unknown → Confirmed |
Changed in firefox-3.0: | |
importance: | Undecided → Medium |
status: | New → Triaged |
In Mozilla Bugzilla #266600, Jürgen 'jiha' Harter (jiha-bugzilla) wrote : | #35 |
(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?
drewster1829 (arruud) wrote : | #36 |
The workaround darkmethod posted is probably for Firefox 2, based on the date of the article. I tried it with Firefox 3 and Ubuntu Hardy, and it does not work.
Alexander Sack (asac) wrote : | #37 |
also referenced this bug now in the comments section of https:/
In Mozilla Bugzilla #266600, Kjb-temp-2009 (kjb-temp-2009-deactivatedaccount) wrote : | #38 |
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/
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:/
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)
In Mozilla Bugzilla #266600, Ahmad Samir (ahmad.samir) wrote : | #39 |
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/
AND
- /usr/share/
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/
inode/directory
Notice the extra kde4 in kde4-dolphin.
To use konqueror instead of dolphin it should be:
inode/directory
Be aware though that /usr/share/
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-
In Mozilla Bugzilla #266600, Kjb-temp-2009 (kjb-temp-2009-deactivatedaccount) wrote : | #40 |
(In reply to comment #17)
Thank you for explaining all this.
I found another workaround somewhere else:
Edit cervisia.desktop and kfmclient-
After update-mime-cache firefox will use dolphin.
In Mozilla Bugzilla #266600, Kjb-temp-2009 (kjb-temp-2009-deactivatedaccount) wrote : | #41 |
(In reply to comment #18)
Sorry, I meant /usr/share/
Kurt J. Bosch (kujub-deactivatedaccount) wrote : | #42 |
Hi,
this problem affects other distributions.
Please consider to vote for this upstream.
https:/
In Mozilla Bugzilla #266600, Kjb-temp-2009 (kjb-temp-2009-deactivatedaccount) wrote : | #43 |
This seems also to be a problem with Xfce.
I worked around this now with this command:
xdg-mime default Thunar-
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/
What xdg-mime does is simply writing a line like
x-directory/
into the file ~/.local/
Custom desktop files located in ~/.local/
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
In Mozilla Bugzilla #266600, Henrique Abreu (hgabreu) wrote : | #44 |
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
Kokoko3k (kokoko3k) wrote : | #45 |
- mimeTypes.rdf Edit (52.3 KiB, application/rdf+xml)
firefox version: 3.1b3
De: Kde 3.5
I'm using archlinux and i haven't any problem.
I think it's just a matter of mimetypes (located at: ~/.mozilla/
Attached you'll find mine which uses /usr/bin/xdg-open, but if "file" is defined, you can easilly go through:
Menu Edit, Preferences, Applications, scroll down until "file", and select something useful for you in the second column.
racerraul (racerraul) wrote : | #46 |
I got this to work by following the instructions on the following links, but with a few changes.
http://
Open About:Config and add the following entries
network.
network.
Notice that in the following entry I am actually telling thunar to open my downloads assigned folder.
network.
I then tested it and FF prompted me for the application to use.
I then navigated to /usr/bin/thunar hit OK and selected the check mark to remember my choice.
Hope that works for some of ya. But that got it to work for me.
Ahmad Syukri Abdollah (syockit) wrote : | #47 |
racerraul, what happens when you double click on the file in the Download Manager list instead of selecting "Open Containing Folder"? Do you get it to open with the associated program, or do you also get it opened with Thunar?
In my case, when I tried opening the containing folder the first time,
- Firefox asked me to select the program to use, naturally I'd select /usr/bin/nautilus for my GNOME environment.
- I also marked the checkbox "Remember my choice for file links".
Then it will open Nautilus for any file I right-clicked and clicked "Open Containing Folder". But the side effect is, for all files I try to open (either by double clicking, or right click and select "Open", it will still try to open with Nautilus, coming up with error "the location is not a folder".
I wonder why opening a folder is treated as opening a file link in Firefox?
racerraul (racerraul) wrote : | #48 |
I just tried it after I downloaded a BIOS update file... dos.exe type...
It attempted to run it with wine...
perhaps if you don't have any file types associated with the file it will do that? Just guessing.
I also tried a .pls file from di.fm and it opened with xmms (my player of choice).
In Mozilla Bugzilla #266600, Kevin Brosnan (kbrosnan) wrote : | #49 |
*** Bug 446204 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #266600, Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing) wrote : | #50 |
MarcRandolph (mrand) wrote : | #51 |
Since Mythbuntu ships with xfce, this affects anyone that does a default Mythbuntu install and tries to use Firefox. Not the most common Mythbuntu use-case, but plenty of people do it. Confirmed on 9.10 Beta.
dewert (dewert) wrote : | #52 |
Not entirely sure if this is related, but I had the exact problem described at http://
What happened there was that firefox was using EasyTag instead of konqueror/dolphin.
Now, while this is slightly different, the fact is that firefox seems to be using /usr/share/
Oddly, the next option (which I didn't delete) was Thunar, but this, apparently, was ignored.
In Mozilla Bugzilla #266600, Mozilla-bugs-thequod (mozilla-bugs-thequod) wrote : | #53 |
@Kurt (comment #20):
unfortunately this does not appear to work for Ubuntu/Kubuntu.
I have added those entries to ~/.local/
inode/
x-directory/
In Mozilla Bugzilla #266600, Ahmad Samir (ahmad.samir) wrote : | #54 |
Ideally dolphin.desktop is inside /usr/share/
x-directory/
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...
Daniel Hahler (blueyed) wrote : | #55 |
I've tried adding the stanza for "file" proposed by Kokoko3k in comment #17:
<RDF:Description RDF:about=
NC:
NC:
to mimeTypes.rdf in the new test user profile, without any luck.
Also, "file" does not appear in the list of applications, as mentioned in the same comment (for the new profile). It appears in my regular users profile however (but seems to apply to unknown files also).
After all, it should boil down to make Firefox call xdg-open when opening files, and folders.
I've not found the place to patch this though, but the path goes via mozilla/
f.reveal() gets called to show the folder, but I could not find where "reveal" is defined, nor if it goes via the catch block.
Here's the related code from the firefox source:
function showDownload(
{
var f = getLocalFileFro
try {
// Show the directory containing the file and select the file
f.reveal();
} catch (e) {
// If reveal fails for some reason (e.g., it's not implemented on unix or
// the file doesn't exist), try using the parent if we have it.
let parent = f.parent.
if (!parent)
return;
try {
// "Double click" the parent directory to show where the file should be
parent.
} catch (e) {
// If launch also fails (probably because it's not implemented), let the
// OS handler try to open the parent
openExter
}
}
}
In Mozilla Bugzilla #266600, Mozilla-bugs-thequod (mozilla-bugs-thequod) wrote : | #56 |
Yes, dolphin.desktop is in /usr/share/
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:/
kanat (kanat2) wrote : | #57 |
Hi, I noticed in my Easytag problem this disconnect in mime types:
Firefox prefers x-directory/normal
before checking inode/directory
KDE can't access x-directory/normal
can only set inode/directory
grep directory /usr/share/
I use Mandriva 2009.1. Under Configure Your Desktop/System Settings/
I can only change inode/directory, can't access x-directory/normal.
On Linux, Firefox should not prefer x-directory/normal MIME type to open folders.
It should check inode/directory first.
In Mozilla Bugzilla #266600, Kevin Brosnan (kbrosnan) wrote : | #58 |
*** Bug 555007 has been marked as a duplicate of this bug. ***
Micah Gersten (micahg) wrote : | #59 |
Resetting to Triaged in firefox as we moved to an unversioned source package.
Changed in firefox (Ubuntu): | |
status: | Won't Fix → Triaged |
In Mozilla Bugzilla #266600, Saulantolinez-ruiz (saulantolinez-ruiz) wrote : | #60 |
*** 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. ***
Changed in firefox: | |
importance: | Unknown → Medium |
Tom Chiverton (bugs-launchpad-net-falkensweb) wrote : | #61 |
user_pref(
does not appear to work with FireFox 4 (beta 12).
Tom Chiverton (bugs-launchpad-net-falkensweb) wrote : | #62 |
FWIW
xdg-open /tmp/
works as expected (loads Dolphin) , so this is a FireFox bug...
Don Rhummy (donrhummy) wrote : | #63 |
I am getting this with Firefox 4, openSUSE 11.3. It attempts to use EasyTag and none of the changes I make in about:config help, nor did changing "inode/directory" and "x-directory/
Tom Chiverton (bugs-launchpad-net-falkensweb) wrote : | #64 |
Under Natty, I get Dolphin opening now. Woot!
In Mozilla Bugzilla #266600, Matěj Cepl (mcepl) wrote : | #65 |
*** Bug 506587 has been marked as a duplicate of this bug. ***
rb.eng (rb-engch) wrote : | #66 |
Under Oneiric I had a similar problem where the "open containing folder" would start up the software center. The solution I found was to edit the following file:
~/.
in my case there was a line in the [Added Associations] section for inode/directory which pointed to software center:
inode/
after deleting this line and saving the file and trying "open containing folder" it worked correctly in nautilus. Looking again at the above file I noted in the section [Default Associations] the line:
inode/
Hope this helps find a work around for you.
no longer affects: | firefox-3.0 (Ubuntu) |
In Mozilla Bugzilla #266600, Psychonaut (psychonaut) wrote : | #67 |
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 Mozilla Bugzilla #266600, Ahmad Samir (ahmad.samir) wrote : | #68 |
(In reply to Tristan Miller from comment #30)
Try this:
- Create ~/.local/
- Put this in it:
[Default Applications]
inode/directory
save it and try "open containing folder" again.
In Mozilla Bugzilla #266600, Psychonaut (psychonaut) wrote : | #69 |
(In reply to Ahmad Samir from comment #31)
Yes, that fixes the problem on the openSUSE 12.2 system.
In Mozilla Bugzilla #266600, Bugzilla-tf (bugzilla-tf) wrote : | #70 |
*** Bug 868768 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #266600, Alex Palecek (alex-palecek) wrote : | #71 |
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
~/
from :
inode/
to :
inode/
functionality was restored.
Thanks!
In Mozilla Bugzilla #266600, Thomas Sisson (thomas-sisson-1) wrote : | #72 |
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 Mozilla Bugzilla #266600, PhobosK (phobosk) wrote : | #73 |
(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
So for now a workaround is either to delete the /usr/share/
It needs fix definitely or at least an option to choose in FF preferences
Please see also bug #258085
In Mozilla Bugzilla #266600, Ahmad Samir (ahmad.samir) wrote : | #74 |
(In reply to PhobosK from comment #36)
I've seen the same issue in Fedora. My workaround was to "sabotage" the org.freedesktop
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
[..]
In Mozilla Bugzilla #266600, Ahmad Samir (ahmad.samir) wrote : | #75 |
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.
In Mozilla Bugzilla #266600, Ahmad Samir (ahmad.samir) wrote : | #76 |
I first hit the org.freedesktop
In Mozilla Bugzilla #266600, systemhealer (system-healer) wrote : | #77 |
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.
In Mozilla Bugzilla #266600, kolAflash (colaflash) wrote : | #78 |
Currently Firefox 33 is using org.freedesktop
https:/
Is Firefox using this bidirectional communication feature or something else, special from org.freedesktop
If Firefox isn't using the special features of org.freedesktop
~/.local/
/usr/share/
If Firefox uses special features from org.freedesktop
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/
/usr/share/
Alternatively, Firefox could check if DESKTOP_SESSION is set to "gnome".
I wouldn't suggest to check for DESKTOP_
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/
/usr/share/
In Mozilla Bugzilla #266600, Rulatir (rulatir) wrote : | #79 |
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).
In Mozilla Bugzilla #266600, kolAflash (colaflash) wrote : | #80 |
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! ;-)
Uqbar (uqbar) wrote : | #81 |
I think more about stupidity that malice.
Firefox is not a Qt/KDE application but rather a GTK+ one. Some packager thinks that if you use Firefox you obviously are willing not only to install the full GNOME bag of stuff, but also ditching KDE in favor of it.
When I install Firefox, I am not asking for anything but Firefox. If I have program X to browse directories, I wish I keep it as it is.
Firefox package(r) instead thinkis he knows more than I do.
Uqbar (uqbar) wrote : | #82 |
Forget about bugs filed at Mozilla.
The notorious bug no.915 (https:/
They just sat down and wait until HTML5 became a standard and that bug went out of meaning.
In Mozilla Bugzilla #266600, Manuel López-Ibáñez (manuellopezibanez) wrote : | #83 |
(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-
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 Mozilla Bugzilla #266600, Ahmad Samir (ahmad.samir) wrote : | #84 |
(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.
> 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:/
> The people that have tried to improve Firefox on
> KDE have done so by creating add-ons or distribution-
> 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
In Mozilla Bugzilla #266600, Rulatir (rulatir) wrote : | #85 |
New discovery: uninstalling nautilus "solves" the problem.
Here's my prophecy: the patch that will finally fix this bug will consist of deletions only.
emr (emrecio) wrote : | #86 |
Yeah, I am going to try and uninstall caja (the app that is causing me grief with firefox). I am trying to run open files dialog on firefox on Fedora 21 / KDE.
Next step is to just switch to chrome or something.
Manuel López-Ibáñez (manuellopezibanez) wrote : | #87 |
I cannot reproduce this bug anymore in 14.04 and the work-around is not needed. Thus, I am closing it. If you are still seeing it, please open a new report describing your setup. Is obvious that the info provided here is very outdated.
Changed in firefox (Ubuntu): | |
status: | Triaged → Fix Released |
In Mozilla Bugzilla #266600, Manuel López-Ibáñez (manuellopezibanez) wrote : | #88 |
This works for me in Kubuntu 14.04 without any additional configuration or work-around. I don't have nautilus installed.
In Mozilla Bugzilla #266600, emr (emrecio) wrote : | #89 |
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
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://
In Mozilla Bugzilla #266600, U279673 (u279673) wrote : | #92 |
(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
In Mozilla Bugzilla #266600, Timothy-holt123 (timothy-holt123) wrote : | #93 |
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?
In Mozilla Bugzilla #266600, Antoine-mechelynck-gmail (antoine-mechelynck-gmail) wrote : | #94 |
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:ca2c0fd7c80
m-c:22f51211915
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.
In Mozilla Bugzilla #266600, oid8 (oid8) wrote : | #90 |
great suggestion to sabotage gnome! see also: https:/
https:/
https:/
In Mozilla Bugzilla #266600, Graham Perrin (grahamperrin-gmail) wrote : | #95 |
> Open containing folder function does nothing (KDE)
Is this still an issue?
Compare with e.g. bug 893799 …
Changed in firefox: | |
importance: | Medium → Unknown |
In Mozilla Bugzilla #266600, Release-mgmt-account-bot (release-mgmt-account-bot) wrote : | #96 |
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](https:/
In Mozilla Bugzilla #266600, Autonag-nomail-bot (autonag-nomail-bot) wrote : | #97 |
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.
In Mozilla Bugzilla #266600, 9-peter-e (9-peter-e) wrote : | #98 |
(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.freedeskto
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.freedeskto
So:
* If your default filemanager actively listens/responds to the `org.freedeskto
* If your default filemanager supports `org.freedeskto
* If your default filemanager doesn't support `org.freedeskto
* If your default filemanager doesn't support `org.freedeskto
Firefox 107.0.1 (64-bit), Slackware64-
In Mozilla Bugzilla #266600, Koraciqid (koraciqid) wrote : | #99 |
Created attachment 9383414
same problem
Thanks from susinorse1970.
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.