Bug 809456 - Firefox's Download's Open Containing Folder opens nautilus, not thunar, which is the preferred File Manager
Summary: Firefox's Download's Open Containing Folder opens nautilus, not thunar, which...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: exo
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-03 12:30 UTC by Jan Pazdziora (Red Hat)
Modified: 2013-08-01 17:25 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-08-01 17:25:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Xfce 9801 0 None None None Never

Description Jan Pazdziora (Red Hat) 2012-04-03 12:30:40 UTC
Description of problem:

I'm using XFCE. I have Preferred Applications -> Utilities -> File Manager set to Thunar.

When I use in Firefox's Downloads window right click and select Open Containing Folder, nautilus window opens, not thunar's.

Version-Release number of selected component (if applicable):

$ rpm -q firefox
firefox-11.0-1.fc16.i686

How reproducible:

Deterministic.

Steps to Reproduce:
1. Have Preferred Applications' File Manager set to Thunar.
2. Open Firefox's Downloads window, make sure there is at least one downloaded entry listed.
3. With right click, select Open Containing Folder.
  
Actual results:

Nautilus window appears.

Expected results:

Thunar window appears.

Additional info:

Comment 1 Jan Horak 2012-04-03 13:28:50 UTC
Firefox uses GIO for showing file in file browser.
The XFCE might not change /usr/share/applications/defaults.list where GIO determines the default application.

Corresponding line should be:
inode/directory=nautilus.desktop

Please attach defaults.list and consider changing component to xfce4-something.

Comment 2 Jan Pazdziora (Red Hat) 2012-04-03 14:05:15 UTC
You are right that the line says nautilus.desktop:

$ grep inode/directory /usr/share/applications/defaults.list 
inode/directory=nautilus.desktop
$ rpm -qf /usr/share/applications/defaults.list
shared-mime-info-0.91-5.fc16.i686
$ 

However, I disagree that this is the line Firefox should use to determine which application to run -- how would that work on multiuser system when one user is running XFCE with thunar and the other runs Gnome with nautilus? The user setting definitely cannot be in the /usr/share/* file.

What is the file which XFCE is supposed to modify for Firefox to pick up the preferred application?

Comment 3 Jan Horak 2012-04-04 07:12:40 UTC
Sorry, firstly it looks into: $HOME/.local/share/applications then it checks /usr/share/applications/defaults.list. XFCE should use libgio to set default applications, function like:
http://developer.gnome.org/gio/2.30/GAppInfo.html#g-app-info-set-as-default-for-type
But I'm no GIO expert by any way.

Comment 4 Jan Pazdziora (Red Hat) 2012-04-04 08:03:34 UTC
Thank you, Jan.

After some hacking I came up with a patch to ~/.local/share/applications/mimeapps.list which causes both the Open Containing Folder in Firefox, as well as gvfs-open file:/// to start thunar:

--- mimeapps.list.orig	2012-04-04 09:29:23.000000000 +0200
+++ mimeapps.list	2012-04-04 09:53:06.000000000 +0200
@@ -1,3 +1,6 @@
 
+[Default Applications]
+inode/directory=thunar.desktop
+
 [Added Associations]
-inode/directory=totem.desktop;
+inode/directory=fedora-Thunar-folder-handler.desktop;thunar.desktop;

Flipping component to exo as I believe it should ensure that it stores the setting for gvfs-open / Firefox to consume.

Comment 5 Jan Pazdziora (Red Hat) 2012-04-04 08:09:43 UTC
Actually, exo kinda works but it should be improved.

The situation is this -- I start with my default mimeapps.list which only has

 [Added Associations]
 inode/directory=totem.desktop;

in it -- don't ask me how it got there, I don't know. The gvfs-open and Firefox open directories in nautilus.

I open Preferred Applications (/usr/lib/xfce4/exo-1/exo-helper-1 --configure) and it says Thunar under File Manager.

I change the Thunar selection to Nautilus, the mimeapps.list changes to

--- mimeapps.list.orig	2012-04-04 09:29:23.000000000 +0200
+++ mimeapps.list	2012-04-04 10:00:41.000000000 +0200
@@ -1,3 +1,5 @@
-
 [Added Associations]
 inode/directory=totem.desktop;
+x-scheme-handler/file=exo-file-manager.desktop
+x-scheme-handler/trash=exo-file-manager.desktop
+

and directories get opened in Nautilus -- still but at least now the behaviour matches what the Preferred Applications says.

I now change the Nautilus in Preferred Applications back to Thunar, the mimeapps.list stays the same

--- mimeapps.list.orig	2012-04-04 09:29:23.000000000 +0200
+++ mimeapps.list	2012-04-04 10:00:58.000000000 +0200
@@ -1,3 +1,5 @@
-
 [Added Associations]
 inode/directory=totem.desktop;
+x-scheme-handler/file=exo-file-manager.desktop
+x-scheme-handler/trash=exo-file-manager.desktop
+

but voila, now both gvfs-open and Firefox behave as expected -- they observe the preferred application setting.

So IMO the main cause of the problem / confusion is that exo-helper-1 --configure only updates the mimeapps.list when the selection changes but it does not check that it's there if I open the Preferred Application, see something selected there but the selection does not affect the behaviour.

Comment 6 Kevin Fenzi 2012-04-04 18:18:03 UTC
ok, so sounds like the initial behavior is whats tripping things up here. 

Would you be willing to file this upstream against exo in bugzilla.xfce.org ? 

If not I can.

Comment 7 Fedora End Of Life 2013-01-16 23:17:27 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Jan Pazdziora (Red Hat) 2013-01-17 09:13:18 UTC
(In reply to comment #6)
> ok, so sounds like the initial behavior is whats tripping things up here. 
> 
> Would you be willing to file this upstream against exo in bugzilla.xfce.org
> ? 
> 
> If not I can.

Oops, I seem to have dropped the ball here. Could you please do the filing? I assume you already have login there and stuff.

Thank you.

Comment 9 Kevin Fenzi 2013-01-22 23:01:20 UTC
https://bugzilla.xfce.org/show_bug.cgi?id=9801

Comment 10 Fedora End Of Life 2013-07-04 06:03:12 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 11 Fedora End Of Life 2013-08-01 17:25:37 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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