Control: retitle -1 file-roller: in some sandbox, fails with no error messages except on stderr (org.freedesktop.DBus.Error.ServiceUnknown)
On 2023-03-15 04:01:48 +0100, Vincent Lefevre wrote: > 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. 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). > > 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?) > > 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. 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." -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
