1

enter image description here

My problem is similar to this, but not to this, nor to others linked in these two, which address the general problem of making Firefox to use the default file manager by a necessary setting that specifies that program.

That is to say that no solution expected to work is in fact working here: this doesn't seem to be a general problem of the type "avoid a program taking over the file manager when opening a folder in that program from context menu" or "'Show in folder' in Firefox downloads does not use my default file manager", but a more Thunar-specific problem of the form "Thunar doesn't respect the settings specifying the default file manager for Firefox".

As said in the first linked question,

"I've tried to modify every mimeapps.list and defaults.list and mimeinfo.cache files possible, every single one of them has the following line etc"

In my case that line is inode/directory=org.kde.dolphin.desktop; , and I have added that even to ~/.config/mimeapps.list.

Dolphin is my default in all my settings.

I have even installed the xfce4-settings and then used xfce4-mime-settings to select Dolphin as file manager (uselessly it seems, as this does not relate to any Xfce or Thunar-specific files) - and I have also selected it in ~/.config/xfce4/helpers.rc and /etc/xdg/xfce4/helpers.rc.

I am in Kubuntu 22.04, I have installed Thunar because I need it's bulk renamer associated with a Dolphin context/service menu, I have fixed this problem many times and I was not expecting it to appear here.

That's why I think is a different problem, based on some setting specific to Thunar or to Firefox - or somehow to them together.

No other application but Firefox seems affected (unlike in the case of the second linked post) and the same Firefox problem with any other application - excepting Thunar - was fixed in the past by modifying the aforementioned files.

Replacing thunar with dolphin in its /usr/share/applications/thunar.desktop launcher didn't help.

UPDATES:

As said here, and here after sending kill signal to Thunar the problem disappears until the Firefox browser is restarted.

Removing the very file /usr/share/applications/thunar.desktop is useless.

Adding that file to ~/.local/share/applications and removing the MimeType line doesn't help.

Completely removing all "thunar" files from usr/bin (because I've noticed that thunar and thunar -B can be run from other location) Firefox stops opening Thunar of course but opens the default file manager Dolphin only after 10-15 seconds!

cipricus
  • 4,066
  • 4
  • 47
  • 106

2 Answers2

1

Based on this post - linking to this:

Looking at /usr/share/dbus-1/services/ we find:

/usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service
/usr/share/dbus-1/services/org.xfce.FileManager.service
/usr/share/dbus-1/services/org.xfce.Thunar.FileManager1.service

I have copied the line SystemdService=plasma-dolphin.service from the "dolphin" file into the other two, replacing the corresponding "thunar" lines there — and restarted the system.

In order to avoid this changes being reverted in case Thunar is updated, I've locked thunar at current version in Synaptic Package Manager (synaptic-pkexec).

(The solution of moving thunar binary from usr/bin —and running it when needed from a different location— works, but then Firefox tends to open Dolphin with a rather long delay: the above fixes this problem.)

Other solutions from link, which I haven't tested but are confirmed to work (but which I guess shouldn't be used on a desktop like Xfce - where Thunar is handling the desktop - without supplementary settings):

  • running killall Thunar at login

  • running systemctl --user mask thunar

cipricus
  • 4,066
  • 4
  • 47
  • 106
0

For Debian-based operating systems, I have developed a script to workaround this issue: 林博仁 Buo-ren Lin / filemanager-dbus-service-workaround · GitLab

It works by renaming the org.freedesktop.FileManager1 dbus activation service files out of the way using the dpkg diversions mechanism, this prevents the workaround become ineffective due to package updates.

Buo-ren Lin
  • 189