On some machine where file-roller is installed, when I want to open
https://cpan.metacpan.org/authors/id/S/SI/SISYPHUS/Math-MPFR-4.25.tar.gz
from Firefox, Firefox proposes to open the file with "Archive Manager"
as the recommended application. If I choose to do this, nothing happens!

I suppose that this corresponds to file-roller, as
/usr/share/applications/org.gnome.FileRoller.desktop contains
"Name=Archive Manager".

If I look at stderr (which is not visible by default), I can see the
following message that appears when I click OK to open the file:

Failed to register: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown

First, any recommended application is expected to work without
any issue. Moreover, when something is wrong for an X application,
the application should display an error message in a dialog box,
so that the user can know what's going on; stderr is not sufficient
as it is not visible by default.

Works as expected on a fresh installation of bookworm.

Can you provide the output of the following command

dpkg --list | grep dbus


P.S. Regarding "First, any recommended application is expected to work
without any issue" => This sounds a bit strange when you are actually using
a totally free operating system built by volunteers! Please consider how
much you can "expect" or "request" here. Better to spend time yourself to
improve Debian. If you think the application or X-Windows itself should do
things differently, you are welcome to provide improvements and patches to
the upstream projects!

ii  dbus                                         1.14.6-1                             amd64        simple interprocess messaging system (system message bus)
ii  dbus-bin                                     1.14.6-1                             amd64        simple interprocess messaging system (command line utilities)
ii  dbus-daemon                                  1.14.6-1                             amd64        simple interprocess messaging system (reference message bus)
ii  dbus-session-bus-common                      1.14.6-1                             all          simple interprocess messaging system (session bus configuration)
ii  dbus-system-bus-common                       1.14.6-1                             all          simple interprocess messaging system (system bus configuration)
ii  dbus-user-session                            1.14.6-1                             amd64        simple interprocess messaging system (systemd --user integration)
ii  dbus-x11                                     1.14.6-1                             amd64        simple interprocess messaging system (X11 deps)
ii  libdbus-1-3:amd64                            1.14.6-1                             amd64        simple interprocess messaging system (library)
ii  libdbus-1-3:i386                             1.14.6-1                             i386         simple interprocess messaging system (library)
ii  libdbus-1-dev:amd64                          1.14.6-1                             amd64        simple interprocess messaging system (development headers)
ii  libdbus-glib-1-2:amd64                       0.112-3                              amd64        deprecated library for D-Bus IPC
ii  libdbusmenu-glib4:amd64                      18.10.20180917~bzr492+repack1-3      amd64        library for passing menus over DBus
ii  libdbusmenu-gtk3-4:amd64                     18.10.20180917~bzr492+repack1-3      amd64        library for passing menus over DBus - GTK-3+ version
ii  libnet-dbus-perl                             1.2.0-2                              amd64        Perl extension for the DBus bindings
ii  libqt5dbus5:amd64                            5.15.8+dfsg-3                        amd64        Qt 5 D-Bus module
ii  xdg-dbus-proxy                               0.1.4-3                              amd64        filtering D-Bus proxy

BTW, I'm a bit surprised that this is related, as the file-roller
package does not depend on libdbus-1-3 (there's also no mention
of dbus in the description and the man page).

Note: I've just done some tests, remotely as I'm not in front of
the machine where it is installed. Outside of Firefox, file-roller
appears to work, but it takes at least 25 seconds before the window
appears! I've just done a test with strace, and it froze on

1678666206.918658 poll([{fd=9, events=POLLIN}], 1, 25000

1678666232.046417 poll([{fd=9, events=POLLIN}], 1, 25000

Thus there's a 25-second timeout. In this test, it occurred twice,
so it took 50 seconds to appear.

What I meant is that some applications appear to have specific
requirements about a desktop environment (here this appears to
be a GNOME application, though it was not presented as a GNOME
application in Firefox). If there are specific requirements,
then the application shouldn't be proposed by Firefox (at least
not by default) if there requirements are not satisfied.

Control: severity -1 important
Control: tags -1 + moreinfo unreproducible
specific to the system where you reproduced this (and possibly other
systems) that is not the same as in the environment where I tested.

I tried to reproduce this in a virtual machine. In case the problem was
the absence of GNOME, I didn't use GNOME, and in case the problem was
a missing dependency, I didn't install Recommends.

The base VM was the output of autopkgtest-build-qemu(1) for bookworm.
This is not *completely* minimal: it has systemd-logind, among other
things.

For the test environment, I installed:

* wget, with Recommends (to download the test file)
* firefox-esr, file-roller, openbox, xdm and xorg, without Recommends

and then rebooted and logged in. In an xterm in the openbox environment,
after using wget to download the test file you named:

`file-roller Math-MPFR-4.25.tar.gz` works as expected for me.

`firefox-esr ./Math-MPFR-4.25.tar.gz`, followed by choosing
"Archive Manager" to handle the file, also works as expected for me.

This might possibly be relevant? Non-merged /usr is no longer a supported
configuration for bookworm, except as a transitional state while upgrading
from bullseye to bookworm.

This often indicates a D-Bus method call timing out. Running

    dbus-monitor --session

in the same environment as file-roller will log the D-Bus method calls
that are happening, which should give some indication of which specific
call is timing out.

Reading the system log (the systemd journal) might also provide useful
information.

Similarly, when launching file-roller from Firefox, using dbus-monitor
and reading the system log should reveal more information about how and
why it's failing to start.
is not the only commonly-used implementation of the D-Bus protocol
(there are implementations in GLib and in libsystemd), and the fact that
a component uses D-Bus is an implementation detail which wouldn't make
sense to mention in a man page, in the same way that "is written in C++"
wouldn't be relevant in a man page.

In this particular case, "Failed to register: %s" seems likely to be
coming from gio/gapplication.c in glib2.0.

file-roller appears to have the single-instance design, where the first
instance of file-roller that is run claims a D-Bus name, and the second
and subsequent instances send messages to the first instance asking
it to implement the desired UI. gapplication is one implementation of
that design, and it might be the messages being exchanged between the
instances that are timing out.

"GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown" means the
machine-readable part of the error message sent by the D-Bus implementation
was that error code, which means: a message was sent to a D-Bus service
that doesn't exist.

": org.freedesktop.DBus.Error.ServiceUnknown" means that the
human-readable part of the error message was set equal to the
machine-readable part. This is unusual. Normally, a ServiceUnknown
error message would come from either dbus-daemon or dbus-broker, but
when dbus-daemon produces those errors, it sets the human-readable part
to something more human-readable, normally this:

    The name %s was not provided by any .service files

... and you say you don't have dbus-broker installed, so it can't be that
either. So there must be something different going on here.

Is there anything unusual about the way you installed Firefox or
file-roller? (For instance if they are installed as Flatpak, Snap or
AppImage apps, or running in some sort of sandbox, or running remotely?)

What desktop environment are you using? Or if the answer is "a desktop
environment that I made myself out of individual components", which
components?

Are you using dbus-daemon or dbus-broker or something else to provide
the D-Bus session bus?

Is there anything else unusual going on, for example involving containers
or distributed systems?

    smcv

This machine is old (2015) and will have to be replaced in a few weeks,
in particular because the Nvidia driver (390.xx) is no longer supported
and has been removed from Debian. So I don't want to risk a breakage
(either with some Debian packages or with my own scripts and settings)
for just a few weeks.

Well, for the remote test, I now remember the following bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018880

("under ssh X11 forwarding, apps like nautilus that use
xdg-desktop-portal start with 25s delay"). It is probably the
same issue.

I can see messages with org.freedesktop.portal.Desktop and
/org/freedesktop/portal/desktop in the dbus-monitor output.

Well, Firefox is running in a sandbox (firejail), though that's
quite usual for me, since I've been doing that for more than
5 years, without issues with external applications except that
I needed to unblacklist /usr/libexec (according to upstream, this
directory must not be used by applications, thus disagreeing with
Debian) and whitelist some application-specific paths.

This may be the issue with the firefox profile, but there is no
documentation and the error message is not helpful. So, if there
is something to add to the firefox profile, one doesn't know.

Note that running file-roller just in a firejail private directory
works (despite some error messages), and without any timeout.

No desktop environment, just FVWM as my window manager.

There are dbus-daemon processes running, but that's outside the
sandbox.

Control: retitle -1 file-roller: in some sandbox, fails with no error messages except on stderr (org.freedesktop.DBus.Error.ServiceUnknown)

For the timeout issue, there is this bug (I've just added
an "affects" for file-roller).

Locally and without a sandbox, file-roller appears to work,
without a timeout (the only issue I could find is that it wanted
to open a window higher than the screen).

So I've clarified the bug title. There are 2 issues:

1. The fact that it does not work in this case. This might be either
an issue in file-roller itself (couldn't it just ignore the error
and assume that it is the only instance?) or in the firejail firefox
profile (but one still needs to make sure that data doesn't escape
the sandbox), but there is a lack of documentation.

The fact that file-roller is based on dbus to work and has the
single-instance design is not just a detail of implementation.
BTW, this will not work either in Mutt when viewing an attachment,
because the file is unlinked as soon as the application quits,
which will happen if file-roller has already been started. This
could also be an issue with web browsers, even without a sandbox.

2. The absence of graphical error report in case of failure, at least
in this case, so that there is absolutely no feedback about the error
in Firefox: it could just mean that the file is still being downloaded
or that the application takes time to start. To quote Paolo Amadini at

https://bugzilla.mozilla.org/show_bug.cgi?id=1318331#c1

"In fact, the target application should be a GUI application, and
normally it's the application's responsibility to show a message box
if there is an issue when opening the file, regardless of the return
code, that may still indicate success."