User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0

Steps to reproduce:

My environment: Ubuntu 22.04, Firefox included with Ubuntu by default as snap package.

Actual results:

When you downloaded a file, you click "Show in Folder" it is not focus to file. I think it is the problem of snap package of Firefox, not bug in Firefox.

Expected results:

Show in Folder should focus to downloaded file as Firefox use apt install firefox or DEB package.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Olivier, do you know whether it is a limitation on the way showing folders is intended to work on Snap, or is it something we could fix ? And if we can fix, where should I have a look at outside of Firefox ?

(I do repro)

That's essentially the same issue as https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1887195 (which was affecting the chromium snap).

This is caused by the strict confinement denying access to the org.freedesktop.FileManager1.ShowItems D-Bus API.
Firefox then falls back to calling RevealDirectory(…) which is implemented using g_app_info_launch_default_for_uri() and opens the containing folder in the default file manager.

The way this was fixed in chromium is by using the desktop portal when the FileManager1 interface isn't available: https://chromium.googlesource.com/chromium/src/+/cdc98cbb2a95d4a7d430b7ccece0d5433d94963a.

(In reply to Olivier Tilloy from comment #4)

That's essentially the same issue as https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1887195 (which was affecting the chromium snap).

This is caused by the strict confinement denying access to the org.freedesktop.FileManager1.ShowItems D-Bus API.
Firefox then falls back to calling RevealDirectory(…) which is implemented using g_app_info_launch_default_for_uri() and opens the containing folder in the default file manager.

The way this was fixed in chromium is by using the desktop portal when the FileManager1 interface isn't available: https://chromium.googlesource.com/chromium/src/+/cdc98cbb2a95d4a7d430b7ccece0d5433d94963a.

I guess this is here: https://searchfox.org/mozilla-central/rev/ace2c59e6c56b2dcba25af1aa8903a5e7f9a5857/toolkit/system/gnome/nsGIOService.cpp#631

Looks like it is at this precise place: https://searchfox.org/mozilla-central/rev/ace2c59e6c56b2dcba25af1aa8903a5e7f9a5857/toolkit/system/gnome/nsGIOService.cpp#610

So, I'm unable to get the DBus call working with https://phabricator.services.mozilla.com/D148782?vs=on&id=588695#toc which seems (to me) on-par with https://chromium-review.googlesource.com/c/chromium/src/+/3009959/9/chrome/browser/platform_util_linux.cc#230

I'm failing so far to properly understand whether we really need those handle_token and others, Chromium source code has just an empty dict it seems.

Behavior is that the call hits timeout.

There's also libportal from Flatpak that does it using a different DBus call which passes the list of FDs directly: https://github.com/flatpak/libportal/blob/13a540084bb642f6046754b07532f90266cfc383/libportal/openuri.c#L232-L248 but it's unclear to me whether we need that?

https://hg.mozilla.org/mozilla-central/rev/051b6a8701bc

I was able to reproduce this issue on Firefox 102.0 Snap build(build ID: 20220627111723) on Ubuntu 22.04. Verified as fixed on Firefox 103.0b4 Snap build(build ID: 20220704000425) and 104.0a1 Snap build(build ID: 20220704034604) on Ubuntu 22.04.