+++ This bug was initially created as a clone of Bug #2150894 +++

Description of problem:

Right-click 'Open in files' does not work on first attempt at first login over desktop icon for home location and trash, works fine on second attempt. 

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

Red Hat Enterprise Linux release 8.6 (Ootpa) & Red Hat Enterprise Linux release 8.7 (Ootpa)
nautilus-3.28.1-21.el8.x86_64

How reproducible:

Always.

Steps to Reproduce:

- Login
- The Screen shows HOME and Trash Icon
- Right Click on HOME
- A dropdown menu opens   open / properties / show in files / open in terminal.
- Click “Show in Files”

Actual results:

Does not work on first attempt.

Expected results:

Should work as expected on first attempt too.

Additional info:

--- Additional comment from Ondrej Holy on 2022-12-07 11:28:31 CET ---

This happens when "/usr/bin/nautilus --gapplication-service" is not running. The following is recorded in the journal:

Dec 07 11:06:59 localhost.localdomain dbus-daemon[2360]: [session uid=1000 pid=2360] Activating service name='org.gnome.Nautilus' requested by ':1.19' (uid=1000 pid=2517 comm="/usr/bin/gnome-shell " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Dec 07 11:06:59 localhost.localdomain dbus-daemon[2360]: [session uid=1000 pid=2360] Successfully activated service 'org.gnome.Nautilus'
Dec 07 11:06:59 localhost.localdomain gnome-shell[2517]: Error showing file on desktop: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.FileManager1' on object at path /org/freedesktop/FileManager1

It looks to be a bug in the desktop-icons extensions as the following works even when the service is not running:

dbus-send --print-reply --dest=org.freedesktop.FileManager1 /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems array:string:"file:///home" string:foo

--- Additional comment from Florian Müllner on 2022-12-09 16:29:47 CET ---

(In reply to Ondrej Holy from comment #1)
> It looks to be a bug in the desktop-icons extensions as the following works
> even when the service is not running:
> 
> dbus-send --print-reply --dest=org.freedesktop.FileManager1
> /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems
> array:string:"file:///home" string:foo

But that would bring back https://bugzilla.redhat.com/show_bug.cgi?id=2026622 as far as I can see.

Is there a good reason why nautilus only exports the org.freedesktop.FileManager1 interface from the startup vfunc and not dbus_register()?

--- Additional comment from Ondrej Holy on 2022-12-16 15:05:51 CET ---

It resides in the startup vfunc since ever. The export of org.gnome.Nautilus interface used to be there as well but later was moved to the dbus_register vfunc. The related commits don't contain any explanation. I don't have any experience with this, but it seems that the right place for that is really dbus_register vfunc. So if you think this needs to be fixed on the Nautilus side, feel free to change the component. Just I wonder how is it possible that the dbus-send cmd works properly...

--- Additional comment from Ondrej Holy on 2023-01-10 14:28:31 CET ---

I took look at this again and I finally see what is going on. What the desktop-icons extension really does in RHEL 8 can be reproduced over dbus-send the following way:

$ dbus-send --print-reply --dest=org.gnome.Nautilus /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems array:string:"file:///home" string:foo
Error org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.FileManager1' on object at path /org/freedesktop/FileManager1
$ dbus-send --print-reply --dest=org.gnome.Nautilus /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems array:string:"file:///home" string:foo
method return time=1673335063.362515 sender=:1.82 -> destination=:1.83 serial=95 reply_serial=2

Also, I probably see why the interface is not exported in dbus_register. In the dbus_register vfunc, the org.gnome.Nautilus connection is obtained and thus the /org/gnome/Nautilus interfaces are exported there, but the /org/freedesktop/FileManager1 interface belongs to the org.freedesktop.FileManager1 name that needs to be also acquired and it is not probably desired to synchronously wait there as it could possibly slow down Nautilus startup.

However, as per d-feet it seems that it is irrelevant under what connection the interfaces were exported as all the interfaces are listed under both names, which makes me think that we can possibly export the /org/freedesktop/FileManager1 interface over the org.gnome.Nautilus connection and consequently just try to acquire the org.freedesktop.FileManager1 name without actually blocking the startup. Am I right?

--- Additional comment from Florian Müllner on 2023-01-11 16:38:50 CET ---

> Am I right?

Yes, at least as far as I know.

--- Additional comment from Florian Müllner on 2023-01-12 14:13:39 CET ---

Thanks Ondrej!