1754275 - The first time trying to open a download's folder causes huge freeze (waiting on DBUS call from nsGIOService::OrgFreedesktopFileManager1ShowItems)

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[noszalyaron4]

Attachment: Screenshot from 2022-02-08 20-53-20.png

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

Steps to reproduce:

Using the latest nightly on Ubuntu 21.10.

1. Download or open an arbitrary file
2. In the downloads menu click on the little folder icon to open its containing directory

Actual results:

The first time downloading a file and opening the containing directory with the little folder icon causes the whole UI of firefox to freeze for approximately 10 seconds.

Expected results:

No freeze.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Can you go to https://profiler.firefox.com, enable it, and take a profile, click the upload button at the top right, and share it here?

Those 10 seconds smells like a timeout (DBUS-related)?

Comment 3

[noszalyaron4]

Here you go: https://share.firefox.dev/3B7DQ69
It seems there's a 25s jank in there, probably that's the cause.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Yeah, so if you look at the stack of the main thread hang is all under nsLocalFile::Reveal, which does some DBUS stuff, so my hunch was right:

__poll
socket_do_iteration
_dbus_connection_do_iteration_unlocked
dbus_pending_call_block
dbus_g_proxy_end_call_internal
dbus_g_proxy_call
nsGIOService::OrgFreedesktopFileManager1ShowItems(nsTSubstring<char> const&)
nsLocalFile::Reveal()
NS_InvokeByIndex
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)
nsIFile.reveal
XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)
Interpret(JSContext*, js::RunState&)
js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)
showDownloadedFile
downloadsCmd_show
doCommand
onButton
onDownloadButton
[...]

That code is... not new, it comes from bug 417952. It seems if the dbus call fails we notice and avoid doing it again...

In any case: it's a shame to block the main thread on that, but it seems something is botched with your dbus setup that causes the call to time out, somehow?

Comment 5

[noszalyaron4]

You're right. It looks like this freedesktop stuff tries to start thunar whichs is no longer installed (if I just checked logs in the first place :D)

febr 09 11:58:16 pangross dbus-daemon[2639]: [session uid=1000 pid=2639] Activating via systemd: service name='org.freedesktop.FileManager1' unit='thunar.service' requested by ':1.116' (uid=1000 pid=5970 comm="/home/aron/ssd/firefox/fire>
febr 09 11:58:16 pangross systemd[2625]: Starting Thunar file manager...
febr 09 11:58:16 pangross systemd[9512]: thunar.service: Failed to locate executable /usr/bin/Thunar: No such file or directory
febr 09 11:58:16 pangross systemd[9512]: thunar.service: Failed at step EXEC spawning /usr/bin/Thunar: No such file or directory
febr 09 11:58:16 pangross systemd[2625]: thunar.service: Main process exited, code=exited, status=203/EXEC
febr 09 11:58:16 pangross systemd[2625]: thunar.service: Failed with result 'exit-code'.
febr 09 11:58:16 pangross systemd[2625]: Failed to start Thunar file manager.
febr 09 11:58:40 pangross systemd[1]: systemd-hostnamed.service: Deactivated successfully.
febr 09 11:58:41 pangross dbus-daemon[2639]: [session uid=1000 pid=2639] Activating service name='org.gnome.Nautilus' requested by ':1.115' (uid=1000 pid=5970 comm="/home/aron/ssd/firefox/firefox-bin " label="unconfined")
febr 09 11:58:41 pangross dbus-daemon[2639]: [session uid=1000 pid=2639] Successfully activated service 'org.gnome.Nautilus'
febr 09 11:58:41 pangross dbus-daemon[2639]: [session uid=1000 pid=2639] Successfully activated service 'org.freedesktop.FileManager1'

It turns out thunar-data was still installed albeit uninstalling thunar a long time ago. After deleting that and restarting the machine now the issue is gone!

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1754275 - Port nsGIOService::OrgFreedesktopFileManager1ShowItems to use GDBusProxy. r=stransky

GDBusProxy is not deprecated, and allows having time outs.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1754275 - Add a 1s timeout to DBUS call to reveal files. r=stransky

This should be much more acceptable than e.g. 25 seconds to open the
file manager.

Depends on D138287

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/26b8562ebba3
Port nsGIOService::OrgFreedesktopFileManager1ShowItems to use GDBusProxy. r=stransky
https://hg.mozilla.org/integration/autoland/rev/ab76921a0846
Add a 1s timeout to DBUS call to reveal files. r=stransky

Comment 9

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/26b8562ebba3
https://hg.mozilla.org/mozilla-central/rev/ab76921a0846

Comment 10

[Monica Chiorean]

I tried to reproduce the issue on Ubuntu using build 99.0a1 (20220207215603) without the fix, but the issue is not reproducing, so I can not confirm the fix.
Can you please confirm issue is not reproducing on your side using latest Beta 99.0b8 (https://archive.mozilla.org/pub/firefox/candidates/99.0b8-candidates/) ? Thank you.